[9fans] nfsserver

[9fans] nfsserver

[arisawa]

I am now trying to export Plan9 file system to my unix workstation.
However I have not succeed in mounting.
My unix host named `ar' answers:

ar> /etc/mount -o soft,intr plan9:9fs /n/9fs
mount: plan9:9fs on /n/9fs: Stale NFS file handle
mount: giving up on:
   /n/9fs

I this command line, plan9 is my CPU server name, 9fs is my Plan9 file server,
and /n/9fs is a directory in the host `ar'.

Nfsserver and portmapper are already running on the CPU server;

bootes     1028    0:00   0:02   196K Read     nfsserver
bootes     1032    0:00   0:00   196K Read     nfsserver
bootes     1037    0:00   0:00    60K Read     portmapper
bootes     1038    0:00   0:00    60K Read     portmapper

The logs in /sys/log/nfs are:

plan9 Apr  8 23:30 nfs file server init
plan9 Apr  8 23:30 aux/nfsserver: listening to port 2049
plan9 Apr  8 23:54 portmapper init
plan9 Apr  8 23:54 aux/portmapper: listening to port 111
plan9 Apr  8 23:54 host=202.250.160.40, port=846, root="9fs"...
plan9 Apr  8 23:54 auth: 892029199 ar u=0 g=1

I don't know why I am told `Stale NFS file handle',
and I don't know what to do.
Please some one help me.

Thanks,

Kenji Arisawa
E-mail: arisawa@aichi-u.ac.jp

[9fans] nfsserver

[Russ]

> The fixes to exportfs (which is what srvfs is calling)
> are available at {ftp,http}://plan9.bell-labs.com/plan9/update/cmd/exportfs.rc

Oops.  I went to use NFS with srvfs again (it'd been a while) and
found that I had missed some of my own bug fixes in preparing the boddle.
The boddle fixed some bugs, but left others.

There is a newer boddle at the same location which fixes the previous
bugs and a couple more.

You'll still need #define nil ((void*)0) if you don't have it already.

Russ

[9fans] nfsserver

[forsyth]

> #define nil	((void*)0)

geoff collyer reasonably observed that i might have added
a little explanation to my previous message.
(sorry, it was early in the morning for me.)
you'll need to add that definition somewhere to compile exportfs.c
having applied rsc's update, because the change depended on the
definition being (as in brazil and Inferno) in /$objtype/include/u.h.
of course, you could also change nil to 0 throughout.

[9fans] nfsserver

[forsyth]

#define nil	((void*)0)

[9fans] nfsserver

[Russ]

> I would like to export kfs at two places:
> One is at my home in a friendly environment. Please post the fix.

The fixes to exportfs (which is what srvfs is calling)
are available at {ftp,http}://plan9.bell-labs.com/plan9/update/cmd/exportfs.rc
Enjoy.

Russ

[9fans] nfsserver

[Kenji]

Thank you Russ Cox. You saied:
>There are two problems with using srvfs.  One is that it's slightly
>buggy and nfsserver exercises those bugs.  I'll post an appropriate
>fix soon if you're interested.

I would like to export kfs at two places:
One is at my home in a friendly environment. Please post the fix.
Another is at my office in a less friendly environment.

>I think Richard Miller had some boddles that let you have kfs serve
>files via the usual IL port, i.e. act as a file server. If you  
apply
>those, then you could do
>        aux/nfsserver -a il!yourmachine
>and both of the problems I mentioned with srvfs are of no concern,
>since you're not using it.  That might be the best solution, short  
of
>setting up your own file server.

I would like to have the boddles...
I believe Richard Miller will send them to me ...

Kenji Arisawa
E-mail: arisawa@aichi-u.ac.jp

[9fans] nfsserver

[Russ]

I use the following to export a file tree from kfs to
DOS via NFS (it would work for Unix too...).

rm -f /srv/usaco
srvfs usaco /usr/rsc/usaco
aux/nfsserver -f /srv/usaco -c /lib/ndb/nfs >/sys/log/nfschat >[2=1]
aux/portmapper >/sys/log/portmapchat >[2=1]
aux/pcnfsd -c /lib/ndb/nfs >/sys/log/pcnfsdchat >[2=1]

The srvfs stuff gets me the tree /usr/rsc/usaco served by /srv/usaco.
Then the -f option to nfsserver serves this tree via NFS.

You could try
	mount -c /srv/kfs /n/kfs
	srvfs kfsroot /
	aux/nfsserver -f /srv/kfsroot ...

Note that you can't do "aux/nfsserver -f /srv/kfs",
since nfsserver reads and writes messages to the file you give
it, instead of using mount(2).  Since your kernel is already using
/srv/kfs, the fids that nfsserver picks are likely to conflict 
with the fids that the kernel is using.  In fact, I think you might
not even be able to do any file i/o to /srv/kfs, for this very
reason.  Once /srv stuff gets mounted, the kernel prohibits you 
from doing read/write operations yourself, so you don't interfere
with the kernel.

There are two problems with using srvfs.  One is that it's slightly
buggy and nfsserver exercises those bugs.  I'll post an appropriate
fix soon if you're interested. 

The second, more serious problem is that srvfs turns off permission
checking: all access via /srv/kfsroot would be done as if it was 
being done by the user that ran srvfs.  So in my above example, all
access via the NFS client to the files in /usr/rsc/usaco is done acting
as rsc (who ran the srvfs command) no matter who NFS mounts the file
system.  In my case, I don't care since I'm exporting it to one DOS
machine that I control.  In a less friendly environment, you probably
care a lot more.

I think Richard Miller had some boddles that let you have kfs serve
files via the usual IL port, i.e. act as a file server.  If you apply
those, then you could do
	aux/nfsserver -a il!yourmachine 
and both of the problems I mentioned with srvfs are of no concern,
since you're not using it.  That might be the best solution, short of
setting up your own file server.

Russ

[9fans] nfsserver

[Kenji]

Hello 9fans!

Can we export local kfs to UNIX?
It seems to me that the '-f' option of nfsserver is provided for  
this
purpose, but I don't know how to do.

Kenji Arisawa
E-mail: arisawa@aichi-u.ac.jp

[9fans] nfsserver

[Kenji]

Hello 9fans!

Forsysth says:
> i'd also have liked a version of 9auth for windows.
That fine! I would also like to have it.

Kenji Arisawa
E-mail: arisawa@aichi-u.acjp

[9fans] nfsserver

[Russ]

maybe i'm missing something, but i don't see why 9auth for 
windows (dos) is such a hard thing.

get a user name.
open mountpoint/#user for read/write, read a challenge
out, present it to the user, write the response back.
if you felt like getting really brave, you could merge it
with netkey and they could just use their plan9 passwords.

or do most windows nfs clients complain because #user isn't
in the usual directory listings or something like that?

[9fans] nfsserver

[Kenji]

I wrote:
>
> ar> /etc/mount -o soft,intr plan9:9fs /n/9fs
> mount: plan9:9fs on /n/9fs: Stale NFS file handle
> mount: giving up on:
>    /n/9fs
>

Thanks to Forsyth and Lucio.
I added -v option in executing nfsserver and portmapper.
This time, I got more detailed messages on CPU server.
The last message on CPU server on mounting request is:
getattr...xfroot: il!9fs...00@ar...no map for pair (il!9fs,
ar)...error 70

What does this mean? And what should I do?
My unix is NEXTSTEP3.3J. The unix system is based on 4.3BSD.

Thanks,

Kenji Arisawa
E-mail: arisawa@aichi-u.ac.jp

[9fans] nfsserver

[forsyth]

i've used nfsserver (with the changes on my web site)
with IRIX 5.3, IRIX 6.2 and Solaris 2.something
without any trouble beyond things inherent in the use of NFS.

for instance, mv sometimes won't work as-is on IRIX because SGI implemented the NFS specification
precisely, and mapped error codes not in the v2 NFS spec to EIO
(or some such thing).  that's fine, but the official list doesn't include
EXDEV, even though Sun's implementation can and does return it.
that in turn causes some peculiar diagnostics to be printed in some
cases under IRIX.

on the other hand, both Solaris and IRIX 6.2 seem to try v3 then fall back
to v2 automatically.  i'm not certain, but i believe v3 is the default on both
systems.  i didn't see much point in implementing v3 at the time.

the only other problem i recall was a political one: some Unix users objected to
having to authenticate themselves to the server.  i'd also have liked a version
of 9auth for windows.

[9fans] nfsserver

[Lucio]

According to arisawa@plan9.aichi-u.ac.jp :
> 
> ar> /etc/mount -o soft,intr plan9:9fs /n/9fs
> mount: plan9:9fs on /n/9fs: Stale NFS file handle
> mount: giving up on:
>    /n/9fs
> 
OK, time to ask the experts for some additional information.

1. The Stale NFS file handle is produced by nfsserver, based on a 
missing machine name in the client credentials.  Is this a Unix bug?
Three different releases of NetBSD produce the same result, user 0 and 
user 301 both producing 0@ and 301@ as the credentials.  The result is 
an empty client ID which cannot be matched in the configuration file
(should it be matched?).

2. NetBSD 1.2.1 and 1.3 both assume NFS version 3 and do not try a 
version 2 possibility.  Does the portmapper have the ability to trigger 
the demotion, or do I need to report to the NetBSD group that they 
should activate such demotion in their mount_nfs code?  Requesting 
version 2 services produces the desired result, give or take the Stale 
NFS file handle problem.

Forsyth?
-- 
Lucio de Re (lucio@proxima.alt.za)
Disclaimer: I'm working at getting my opinions to agree with me.