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 <sqweek@gmail.com> wrote:

> On Feb 9, 2008 4:25 AM, Russ Cox <rsc@swtch.com> 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