Hi! well, i have been having this error for quite a while with 9pfuse. on amd64 linux (archlinux), i couldn't even ls a mounted directory, now that i have a 32 bit system, ls works, but cp doesn't (i have no idea if it hasanything to do with the arch, though). this is how i mount sources with p9p: $ 9fs sources $ 9 mount `namespace`/sources /tmp/sources then ls in a directory in /tmp/sources works, but when i try to copy, attached is the output. I'm open to testing whatever fixes you might suggest. regs John
On Wed, 13 Feb 2008 04:40:27 +0900 sqweek <[EMAIL PROTECTED]> wrote: > On Feb 9, 2008 4:25 AM, Russ Cox <[EMAIL PROTECTED]> wrote: > > > provide any facility to attach as a different user. So, I modified the > > > attach strategy to look for a USER environment variable before falling > > > back on getuser(). I've attached the diff, hopefully I got everything. > > > > The name in the attach is almost just a comment. > > What matters is the name used inside the authentication > > protocol. (The name in the attach is really only there for > > non-authenticated connections.) So these changes > > shouldn't be necessary. > > Hm, I guess u9fs is misbehaving then? > > > This is the problem: you should never be prompted for a > > role=speakfor key. You should be prompted for a role=client key. > > If that happened correctly then I think things would have just > > worked. Try pre-loading a role=client key into factotum and > > see if that works better. > > I'm pretty sure I did have a role=client key in factotum in my > previous attempts, added by drawterm (I have a cpu/authserver on my > home network aswell, with the same user/pass/dom as my u9fs.key). I > reran the tests to be sure, the log is below. It turns out I only get > asked for a speakfor key when using my modified USER code, but it's > still the only way I've got a usable connection. > I had a quick look at u9fs and it does appear to be checking against > the Tattach uname in p9anyattach(), but if that check was failing I > should be getting "authentication failed" not "unknown user". > Um, but that was a pretty silly place to look anyway. There's only > one place "unknown user" is actually returned, and that is after > uname2user fails in rattach() (which was probably the original reason > for my USER hack). > I suspect there is no good solution here since if you called > uname2user() on the auth username, every user would connect with the > same permissions (I assume everyone connecting needs an auth key > matching /etc/u9fs.key?). Maybe it would work with tighter coupling > with the auth server? I never fully grasped the reason behind > /etc/u9fs.key... Otherwise, u9fs needs to be told remotely what uid to > use. > > $ 9p read factotum/ctl > key dom=sqweek.dnsdojo.org proto=p9sk1 role=client user=sqweek !password? > > $ rm `namespace`/wren > $ srv -a sqweek.dnsdojo.org wren > $ 9p ls wren/ > 9p: mount: unknown user > $ USER=sqweek /opt/plan9/src/cmd/o.9p ls wren/ > /opt/plan9/src/cmd/o.9p: mount: unknown user > > $ rm `namespace`/wren > $ srv sqweek.dnsdojo.org wren > $ 9p ls wren/ > 9p: mount: unknown user > $ USER=sqweek /opt/plan9/src/cmd/o.9p ls wren/ > !adding key: role=speakfor proto=p9sk1 dom=sqweek.dnsdojo.org > > -sqweek, thinking he should probably have set inferno up a long time ago
cp.output
Description: Binary data
