[nfs-discuss] snv_111 credential problems with Linux NFSv3
> On Thu, 23 Apr 2009 07:46:06 +0200, Frank Batschulat > 3) on the solaris client side, comment out the 'none' > entry from the list of supported security flavours in > /etc/nfssec.conf I just discovered this problem at work. Since we're running a lot of NFS/NIS and autofs, my only reasonable solution for dealing with the Linux NFS server is this option above. It works, but can someone tell me the ramifications of commenting this option? We don't use any extended security features (did you see "NIS" above!!), but I'd like to understand what I may be breaking or losing by commenting this line. Thanks for any help. -- This message posted from opensolaris.org
[nfs-discuss] snv_111 credential problems with Linux NFSv3
> > > > Running pfexec mount -F nfs -o vers=3,sec=sys butler:/data /mnt/ > still gives nfs mount: security mode does not match the server > exporting butler:/data and the following snoop > > 192.168.0.10 -> butler DNS C butler. Internet Addr ? > butler -> 192.168.0.10 DNS R butler. Internet Addr 192.168.0.1 > 192.168.0.10 -> butler PORTMAP C GETPORT prog=15 (MOUNT) > vers=3 proto=UDP > butler -> 192.168.0.10 PORTMAP R GETPORT port=44106 > 192.168.0.10 -> butler MOUNT3 C Null > butler -> 192.168.0.10 MOUNT3 R Null > 192.168.0.10 -> butler MOUNT3 C Mount /data > butler -> 192.168.0.10 MOUNT3 R Mount OK FH=D734 Auth= Hi Andreas, NFS server is supposed to be returning client with a list of auth flavors allowed to access the filesystem. From MOUNT protocol RFC, If mountres3.fhs_status is MNT3_OK, then mountres3.mountinfo contains the file handle for the directory and a list of acceptable authentication flavors. This file handle may only be used in the NFS version 3 protocol. Unfortunately, Gentoo NFS server is returning only file handle and no auth flavors in the list. butler -> 192.168.0.10 MOUNT3 R Mount OK FH=D734 Auth= ^^ Solaris NFS clients check for this at: http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/fs.d/nfs/mount/mount.c#2316 I am not too sure about Gentoo Linux. But I believe Gentoo's mountd is not returning the list of acceptable authentication flavors to client. Have you modified anything on server? What are the default values on server for exportfs (/etc/default/nfs equivalent)? Gentoo's mountd should have atleast returned the default auth flavor, this looks like a bug to me. After you explicitly export filesystem with "sec=sys" on server, mountd sends SYS auth flavor along with the filehandle. This is the reason why client mounts succeed. With this explicit setting on server, you don't have to use "-o vers=sys" mount option on client. What is interesting is, how did you start seeing this behavior from snv_111 onwards? This piece of code has been there in solaris mount_nfs from a long time. Thanks. -Vallish
[nfs-discuss] snv_111 credential problems with Linux NFSv3
On Mon, Apr 27, 2009 at 2:24 PM, Vallish Vaidyeshwara < Vallish.Vaidyeshwara at sun.com> wrote: > > >> >> >> Running pfexec mount -F nfs -o vers=3,sec=sys butler:/data /mnt/ still >> gives nfs mount: security mode does not match the server exporting >> butler:/data and the following snoop >> >> 192.168.0.10 -> butler DNS C butler. Internet Addr ? >> butler -> 192.168.0.10 DNS R butler. Internet Addr 192.168.0.1 >> 192.168.0.10 -> butler PORTMAP C GETPORT prog=15 (MOUNT) vers=3 >> proto=UDP >> butler -> 192.168.0.10 PORTMAP R GETPORT port=44106 >> 192.168.0.10 -> butler MOUNT3 C Null >> butler -> 192.168.0.10 MOUNT3 R Null >> 192.168.0.10 -> butler MOUNT3 C Mount /data >> butler -> 192.168.0.10 MOUNT3 R Mount OK FH=D734 Auth= >> > Hi Andreas, > Hi Vallish, > > NFS server is supposed to be returning client with a list of auth flavors > allowed to access the filesystem. From MOUNT protocol RFC, > > > If mountres3.fhs_status is MNT3_OK, then > mountres3.mountinfo contains the file handle for the > directory and a list of acceptable authentication > flavors. This file handle may only be used in the NFS > version 3 protocol. > > > Unfortunately, Gentoo NFS server is returning only file handle and no auth > flavors in the list. > > butler -> 192.168.0.10 MOUNT3 R Mount OK FH=D734 Auth= > > ^^ > > Solaris NFS clients check for this at: > > http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/fs.d/nfs/mount/mount.c#2316 > > I am not too sure about Gentoo Linux. But I believe Gentoo's mountd is not > returning the list of acceptable authentication flavors to client. Have you > modified anything on server? What are the default values on server for > exportfs (/etc/default/nfs equivalent)? Gentoo's mountd should have atleast > returned the default auth flavor, this looks like a bug to me. The man page says that sec=sys is the default. But man pages is not always accurate. I haven't changed any options, and per default most of them are left blank. But I agree that this might be a bug in either Gentoo or the nfs implementation on Linux. I filed a bug with Gentoo, http://bugs.gentoo.org/show_bug.cgi?id=267648 Interesting to see where that takes this. > > > After you explicitly export filesystem with "sec=sys" on server, mountd > sends SYS auth flavor along with the filehandle. This is the reason why > client mounts succeed. With this explicit setting on server, you don't have > to use "-o vers=sys" mount option on client. > Thanks, less to type is nice. > > What is interesting is, how did you start seeing this behavior from snv_111 > onwards? This piece of code has been there in solaris mount_nfs from a long > time. > I used OSOL up till snv_105 and then I went back to Gentoo GNU/Linux and FreeBSD for a while. When I came back ( snv_110 ) nfs was broken. I don't know when it broke, it might have been before I left, but i didn't notice it then. > > Thanks. > -Vallish > Thanks for help so far. Best regards Andreas Nilsson
[nfs-discuss] snv_111 credential problems with Linux NFSv3
Andreas Nilsson wrote: > I have a share exported on GNU/Linux-box (Gentoo) and as described mounting > that share on my OSOL snv_111a fails. > > It fails even if I specify -o vers=3,sec=sys. If i however specify -o vers=2 > it works. > > If i edit the export to include sec=sys on the server it works perfectly. > > Hi Andreas, What you are seeing is the correct behavior. Looks like your earlier share on Linux box was exporting filesystem with only ANON mode. Hence OSOL client was not able to mount even with explicit "-o vers=3,sec=sys" mount command. I am not really sure as to how this worked with "-o vers=2"? Can you please send across a snoop output and "nfsstat -m" output on the client for both v3 and v2 mounts? > For my setup i can live with this, but if i bring the OSOL computer to > another network where i do not control the nfs server it will be very > annoying not being able to mount the shares. > Please see work arounds posted on this thread by FrankB, you don't have to have control the server: 3) on the solaris client side, comment out the 'none' entry from the list of supported security flavours in /etc/nfssec.conf or 4) on the solaris client side, explicitely perform the mount with a security flavour specified other then sec=none OSOL client was earlier broken and was quietly sending SYS authentication flavor even for ANON flavors. It is now fixed and what you are seeing is the correct behavior. However, there is a discussion to change OSOL client now and to make it more intelligent than just picking the first mode from the list of security modes returned by Server. Regards, -Vallish
[nfs-discuss] snv_111 credential problems with Linux NFSv3
On Mon, Apr 27, 2009 at 9:06 AM, Vallish Vaidyeshwara < Vallish.Vaidyeshwara at sun.com> wrote: > Andreas Nilsson wrote: > >> I have a share exported on GNU/Linux-box (Gentoo) and as described >> mounting that share on my OSOL snv_111a fails. >> >> It fails even if I specify -o vers=3,sec=sys. If i however specify -o >> vers=2 it works. >> >> If i edit the export to include sec=sys on the server it works perfectly. >> >> >> > > Hi Andreas, > > What you are seeing is the correct behavior. Looks like your earlier share > on Linux box was exporting filesystem with only ANON mode. Hence OSOL client > was not able to mount even with explicit "-o vers=3,sec=sys" mount command. > I am not really sure as to how this worked with "-o vers=2"? Can you please > send across a snoop output and "nfsstat -m" output on the client for both v3 > and v2 mounts? > > > For my setup i can live with this, but if i bring the OSOL computer to >> another network where i do not control the nfs server it will be very >> annoying not being able to mount the shares. >> >> > > Please see work arounds posted on this thread by FrankB, you don't have to > have control the server: > > > 3) on the solaris client side, comment out the 'none' entry from the list > of supported security flavours in /etc/nfssec.conf > or > 4) on the solaris client side, explicitely perform the mount with a > security flavour > specified other then sec=none > > > OSOL client was earlier broken and was quietly sending SYS authentication > flavor even for ANON flavors. It is now fixed and what you are seeing is the > correct behavior. However, there is a discussion to change OSOL client now > and to make it more intelligent than just picking the first mode from the > list of security modes returned by Server. > > Regards, > -Vallish > > Hello, I'm no expert with snoop ( never having used it ) but I'll give it a shot. If something is missing please let me know. I reset the export on the linux box to what i used to have: /data 192.168.0.*(rw,sync,no_subtree_check,no_root_squash) Snoop output is a bit length... As far as i can see it seems that the server answers with AUTH= whatever i tell the client to use, unless specified in /etc/exports on the server. When the v3 mount succeeds it seems that it returns an AUTH=unix Running pfexec mount -F nfs -o vers=3 butler:/data /mnt/ gives 192.168.0.10 -> butler DNS C butler. Internet Addr ? butler -> 192.168.0.10 DNS R butler. Internet Addr 192.168.0.1 192.168.0.10 -> butler PORTMAP C GETPORT prog=15 (MOUNT) vers=3 proto=UDP butler -> 192.168.0.10 PORTMAP R GETPORT port=44106 192.168.0.10 -> butler MOUNT3 C Null butler -> 192.168.0.10 MOUNT3 R Null 192.168.0.10 -> butler MOUNT3 C Mount /data butler -> 192.168.0.10 MOUNT3 R Mount OK FH=D734 Auth= 192.168.0.10 -> butler DNS C 10.0.168.192.in-addr.arpa. Internet PTR ? butler -> 192.168.0.10 DNS R Error: 3(Name Error) 192.168.0.10 -> butler DNS C 10.0.168.192.in-addr.arpa. Internet PTR ? butler -> 192.168.0.10 DNS R Error: 3(Name Error) with no output from nfstat -m Running pfexec mount -F nfs -o vers=3,sec=sys butler:/data /mnt/ still gives nfs mount: security mode does not match the server exporting butler:/data and the following snoop 192.168.0.10 -> butler DNS C butler. Internet Addr ? butler -> 192.168.0.10 DNS R butler. Internet Addr 192.168.0.1 192.168.0.10 -> butler PORTMAP C GETPORT prog=15 (MOUNT) vers=3 proto=UDP butler -> 192.168.0.10 PORTMAP R GETPORT port=44106 192.168.0.10 -> butler MOUNT3 C Null butler -> 192.168.0.10 MOUNT3 R Null 192.168.0.10 -> butler MOUNT3 C Mount /data butler -> 192.168.0.10 MOUNT3 R Mount OK FH=D734 Auth= with no output from nfsstat -m Running pfexec mount -F nfs -o vers=2 butler:/data /mnt/ succeeds with mounting and gives the following snoop 192.168.0.10 -> butler DNS C butler. Internet Addr ? butler -> 192.168.0.10 DNS R butler. Internet Addr 192.168.0.1 192.168.0.10 -> butler PORTMAP C GETPORT prog=15 (MOUNT) vers=2 proto=UDP butler -> 192.168.0.10 PORTMAP R GETPORT port=44106 192.168.0.10 -> butler MOUNT2 C Null butler -> 192.168.0.10 MOUNT2 R Null 192.168.0.10 -> butler MOUNT2 C Mount /data butler -> 192.168.0.10 MOUNT2 R Mount OK FH=D434 192.168.0.10 -> butler PORTMAP C GETPORT prog=100021 (NLM) vers=1 proto=UDP butler -> 192.168.0.10 PORTMAP R GETPORT port=46817 192.168.0.10 -> butler NLM C GRANTED1 OH= FH=D434 PID=0 Region=0:0 butler -> 192.168.0.10 NLM R GRANTED1 OH= denied 192.168.0.10 -> butler PORTMAP C GETPORT prog=13 (NFS) vers=2 proto=TCP butler -> 192.168.0.10 PORTMAP R GETPORT port=2049 192.168.0.10 -> butler TCP D=2049 S=52417 Syn Seq=1041190478 Len=0 Win=49640 Options= butler -> 192.168.0.10 TCP D=52417 S=2049 Syn Ack=1041190479 Seq=1009563338 Len=0 Win=5840 Options
[nfs-discuss] snv_111 credential problems with Linux NFSv3
I have a share exported on GNU/Linux-box (Gentoo) and as described mounting that share on my OSOL snv_111a fails. It fails even if I specify -o vers=3,sec=sys. If i however specify -o vers=2 it works. If i edit the export to include sec=sys on the server it works perfectly. For my setup i can live with this, but if i bring the OSOL computer to another network where i do not control the nfs server it will be very annoying not being able to mount the shares. -- This message posted from opensolaris.org
[nfs-discuss] snv_111 credential problems with Linux NFSv3
On Thu, 23 Apr 2009 15:50:48 +0200, Andrew Gallatin
wrote:
>> though I'd be really interested to know more about how it comes that a share
>> by
>> default is done with AUTH_NONE included, any backround infos somewhere
>> available ?
>>
>> the Solaris server, by default, shares with sec=AUTH_SYS
>
> ENOCLUE. My Linux server's exports list looks like:
>
> /home
> 172.31.193.0/255.255.255.0(rw,async,no_subtree_check,insecure,no_root_squash)
>
> This is Ubuntu 8.04 ("hardy") update 2:
>
> % cat /etc/issue
> Ubuntu 8.04.2 \n \l
>
> % uname -a
> Linux thunder 2.6.24-23-generic #1 SMP Mon Jan 26 01:04:16 UTC 2009
> x86_64 GNU/Linux
>
> I certainly never intended to export anything with sec=none.
ENOCLUE as well, can't find anything talking about this in:
http://manpages.ubuntu.com/manpages/hardy/en/man8/exportfs.8.html
http://manpages.ubuntu.com/manpages/jaunty/en/man8/exportfs.8.html
http://manpages.ubuntu.com/manpages/hardy/en/man5/exports.5.html
http://manpages.ubuntu.com/manpages/jaunty/en/man8/exportfs.8.html
yet the snoop is pretty clear from 6828396
5 0.00156 solaris-client -> linux-server MOUNT3 C Mount /v3-server-test
6 0.00859 linux-server -> solaris-client MOUNT3 R Mount OK FH=5F67
Auth=none,unix,390003,390004,390005
---
frankB
[nfs-discuss] snv_111 credential problems with Linux NFSv3
On Thu, 23 Apr 2009 14:52:51 +0200, Andrew Gallatin wrote: > Frank Batschulat (Home) wrote: > >> yes, in build 108 we integrated real kernel RPC support for AUTH_NONE, >> previously it was silently matched and handled as AUTH_SYS >> >> 6790413 AUTH_NONE implementation in kernel RPC >> http://bugs.opensolaris.org/view_bug.do?bug_id=6790413 >> >> it appears that the linux server as default has sec=none before sec=sys in >> the share so >> we'd start using real AUTH_NONE support for the mount and future access >> causing following problems >> >> 6828396 snv_111 sends wrong uid/gid to Linux NFSv3 server >> http://bugs.opensolaris.org/view_bug.do?bug_id=6828396 >> >> since AUTH_NONE is the first security flavour our client gets from the Linux >> server >> during mount, our client will then use AUTH_NONE for future access of course >> and will fail as described in 6828396 > > There was a comment somewhere (which I can no longer find) that the > Solaris policy of choosing the *first* common security flavor may be > incorrect, and that Solaris should be choosing the *strongest* > common security flavor. If Solaris did this, it would certainly thats exactly what we've already started to discuss now ;-) > reduce interoperability problems with Linux NFS servers, since > sec=sys would be chosen in this case. Eg, things would continue > to work, rather than break, when people upgrade to more recent > versions of OpenSolaris. though I'd be really interested to know more about how it comes that a share by default is done with AUTH_NONE included, any backround infos somewhere available ? the Solaris server, by default, shares with sec=AUTH_SYS --- frankB
[nfs-discuss] snv_111 credential problems with Linux NFSv3
Frank Batschulat (Home) wrote:
> On Thu, 23 Apr 2009 14:52:51 +0200, Andrew Gallatin
> wrote:
>
>> Frank Batschulat (Home) wrote:
>>
>>> yes, in build 108 we integrated real kernel RPC support for AUTH_NONE,
>>> previously it was silently matched and handled as AUTH_SYS
>>>
>>> 6790413 AUTH_NONE implementation in kernel RPC
>>> http://bugs.opensolaris.org/view_bug.do?bug_id=6790413
>>>
>>> it appears that the linux server as default has sec=none before sec=sys in
>>> the share so
>>> we'd start using real AUTH_NONE support for the mount and future access
>>> causing following problems
>>>
>>> 6828396 snv_111 sends wrong uid/gid to Linux NFSv3 server
>>> http://bugs.opensolaris.org/view_bug.do?bug_id=6828396
>>>
>>> since AUTH_NONE is the first security flavour our client gets from the
>>> Linux server
>>> during mount, our client will then use AUTH_NONE for future access of course
>>> and will fail as described in 6828396
>> There was a comment somewhere (which I can no longer find) that the
>> Solaris policy of choosing the *first* common security flavor may be
>> incorrect, and that Solaris should be choosing the *strongest*
>> common security flavor. If Solaris did this, it would certainly
>
> thats exactly what we've already started to discuss now ;-)
>
>> reduce interoperability problems with Linux NFS servers, since
>> sec=sys would be chosen in this case. Eg, things would continue
>> to work, rather than break, when people upgrade to more recent
>> versions of OpenSolaris.
>
> though I'd be really interested to know more about how it comes that a share
> by
> default is done with AUTH_NONE included, any backround infos somewhere
> available ?
>
> the Solaris server, by default, shares with sec=AUTH_SYS
ENOCLUE. My Linux server's exports list looks like:
/home
172.31.193.0/255.255.255.0(rw,async,no_subtree_check,insecure,no_root_squash)
This is Ubuntu 8.04 ("hardy") update 2:
% cat /etc/issue
Ubuntu 8.04.2 \n \l
% uname -a
Linux thunder 2.6.24-23-generic #1 SMP Mon Jan 26 01:04:16 UTC 2009
x86_64 GNU/Linux
I certainly never intended to export anything with sec=none.
Drew
[nfs-discuss] snv_111 credential problems with Linux NFSv3
On Thu, 23 Apr 2009 07:46:06 +0200, Frank Batschulat (Home) wrote: > On Thu, 23 Apr 2009 07:34:45 +0200, Tom Haynes > wrote: > >> The credentials problem is a known bug. >> >> I just can't find the bug number right now. >> >> I *think* if you say: >> >> mount -o sec=sys .. >> >> it will start working as expected. >> >> There was a recent change to add server support for sec=none and the Linux >> client hands it out first if no security flavor is supplied. >> >> So, if you supply your flavor, you should not see the issue. > > yes, in build 108 we integrated real kernel RPC support for AUTH_NONE, > previously it was silently matched and handled as AUTH_SYS > > 6790413 AUTH_NONE implementation in kernel RPC > http://bugs.opensolaris.org/view_bug.do?bug_id=6790413 > > it appears that the linux server as default has sec=none before sec=sys in > the share so > we'd start using real AUTH_NONE support for the mount and future access > causing following problems > > 6828396 snv_111 sends wrong uid/gid to Linux NFSv3 server > http://bugs.opensolaris.org/view_bug.do?bug_id=6828396 > > since AUTH_NONE is the first security flavour our client gets from the Linux > server > during mount, our client will then use AUTH_NONE for future access of course > and will fail as described in 6828396 > > using sec=sys as either the first flavour or leave out sec=none completely > brings us back to AUTH_SYS. > > sample snoop to illustrate the problem: > > 5 0.00156 solaris-client -> linux-server MOUNT3 C Mount /v3-server-test > 6 0.00859 linux-server -> solaris-client MOUNT3 R Mount OK FH=5F67 > Auth=none,unix,390003,390004,390005 has also been discussed here: http://www.opensolaris.org/jive/thread.jspa?threadID=99671&tstart=60 current workarounds: 1) on the linux server side, remove the sec=none from the share or 2) on the linux server side, explicitely share with sec=sys or 3) on the solaris client side, comment out the 'none' entry from the list of supported security flavours in /etc/nfssec.conf or 4) on the solaris client side, explicitely perform the mount with a security flavour specified other then sec=none --- frankB
[nfs-discuss] snv_111 credential problems with Linux NFSv3
Andrew Gallatin wrote: > > ENOCLUE. My Linux server's exports list looks like: > > /home > 172.31.193.0/255.255.255.0(rw,async,no_subtree_check,insecure,no_root_squash) > > Frank's point is that by default, you will get this with sec=none. I *think* if you instead have: /home 172.31.193.0/255.255.255.0(sec=sys,rw,async,no_subtree_check,insecure,no_root_squash) then things should work.
[nfs-discuss] snv_111 credential problems with Linux NFSv3
Frank Batschulat (Home) wrote: > yes, in build 108 we integrated real kernel RPC support for AUTH_NONE, > previously it was silently matched and handled as AUTH_SYS > > 6790413 AUTH_NONE implementation in kernel RPC > http://bugs.opensolaris.org/view_bug.do?bug_id=6790413 > > it appears that the linux server as default has sec=none before sec=sys in > the share so > we'd start using real AUTH_NONE support for the mount and future access > causing following problems > > 6828396 snv_111 sends wrong uid/gid to Linux NFSv3 server > http://bugs.opensolaris.org/view_bug.do?bug_id=6828396 > > since AUTH_NONE is the first security flavour our client gets from the Linux > server > during mount, our client will then use AUTH_NONE for future access of course > and will fail as described in 6828396 There was a comment somewhere (which I can no longer find) that the Solaris policy of choosing the *first* common security flavor may be incorrect, and that Solaris should be choosing the *strongest* common security flavor. If Solaris did this, it would certainly reduce interoperability problems with Linux NFS servers, since sec=sys would be chosen in this case. Eg, things would continue to work, rather than break, when people upgrade to more recent versions of OpenSolaris. Drew
[nfs-discuss] snv_111 credential problems with Linux NFSv3
On Thu, 23 Apr 2009 07:34:45 +0200, Tom Haynes wrote: > The credentials problem is a known bug. > > I just can't find the bug number right now. > > I *think* if you say: > > mount -o sec=sys .. > > it will start working as expected. > > There was a recent change to add server support for sec=none and the Linux > client hands it out first if no security flavor is supplied. > > So, if you supply your flavor, you should not see the issue. yes, in build 108 we integrated real kernel RPC support for AUTH_NONE, previously it was silently matched and handled as AUTH_SYS 6790413 AUTH_NONE implementation in kernel RPC http://bugs.opensolaris.org/view_bug.do?bug_id=6790413 it appears that the linux server as default has sec=none before sec=sys in the share so we'd start using real AUTH_NONE support for the mount and future access causing following problems 6828396 snv_111 sends wrong uid/gid to Linux NFSv3 server http://bugs.opensolaris.org/view_bug.do?bug_id=6828396 since AUTH_NONE is the first security flavour our client gets from the Linux server during mount, our client will then use AUTH_NONE for future access of course and will fail as described in 6828396 using sec=sys as either the first flavour or leave out sec=none completely brings us back to AUTH_SYS. sample snoop to illustrate the problem: 5 0.00156 solaris-client -> linux-server MOUNT3 C Mount /v3-server-test 6 0.00859 linux-server -> solaris-client MOUNT3 R Mount OK FH=5F67 Auth=none,unix,390003,390004,390005 --- frankB
[nfs-discuss] snv_111 credential problems with Linux NFSv3
Some administrivia: So there appears to be a bug in the mailing list software where not everything is being sent out. The jive archives are working, but I'm not getting any email on this thread. Also, I don't see anything cached in the mailman archives. I'm working this issue with the admins... --- So, we aren't ignoring you, on purpose that is... :-> The credentials problem is a known bug. I just can't find the bug number right now. I *think* if you say: mount -o sec=sys .. it will start working as expected. There was a recent change to add server support for sec=none and the Linux client hands it out first if no security flavor is supplied. So, if you supply your flavor, you should not see the issue. -- This message posted from opensolaris.org
[nfs-discuss] snv_111 credential problems with Linux NFSv3
Hi, I recently BFU'd a system in my home lab from snv_106 to snv_111, and now I cannot access things as a user from my Linux NFS server using NFSv3 because Solaris NFS is sending my uid as 65534. The only workaround I've been able to find is to use an NFSv2 mount. The same machine worked fine for many Solaris versions (starting at snv_64) and still works fine when booting into other partitions (S10U1, FreeBSD 6.3, FreeBSD 7.0). Nor do I have problems from other clients including MacOSX 10.4, MacOSX 10.5, NetBSD, etc. The Linux server runs Ubuntu 8.04 (Linux thunder 2.6.24-23-generic #1 SMP Mon Jan 26 01:04:16 UTC 2009 x86_64 GNU/Linux) and exports the filesystem like this: /home 172.31.193.0/255.255.255.0(rw,async,no_subtree_check,insecure,no_root_squash) The problem seems to be that the NFS client is sending my credentials as "nobody4". In a world-writable directory, a file created by me shows up as owned by "nobody4". Eg: > ls -ld /home/gallatin /home/gallatin/tmp /tmp drwxr-xr-x 157 gallatin root 12288 Apr 8 2009 /home/gallatin drwxrwxrwt 23 gallatin root4096 Apr 8 2009 /home/gallatin/tmp drwxrwxrwt 4 root sys 452 Apr 8 03:34 /tmp > df /home/gallatin /home/gallatin/tmp /tmp /home (172.31.193.10:/home):47825704 blocks 95652420 files /home (172.31.193.10:/home):47825704 blocks 95652420 files /tmp (swap ): 1687056 blocks69983 files > touch /home/gallatin/zot /home/gallatin/tmp/zot /tmp/zot touch: cannot create /home/gallatin/zot: Permission denied > ls -l /home/gallatin/zot /home/gallatin/tmp/zot /tmp/zot /home/gallatin/zot: No such file or directory -rw-r--r-- 1 nobody4 nogroup0 Apr 8 2009 /home/gallatin/tmp/zot -rw-r--r-- 1 gallatin root 0 Apr 8 03:35 /tmp/zot If I snoop the creation of /home/gallatin/tmp/zot, I can see that the client is not setting my uid, etc, correctly: NFS: - Sun NFS - NFS: NFS: Proc = 8 (Create file) NFS: Status = 0 (OK) NFS: File handle = [A35C] NFS: 010006024AD046CC532E45E38E5FAAA304E35EDB484795040500960C8E04 NFS: NFS: Post-operation attributes: NFS:File type = 1 (Regular File) NFS:Mode = 0100644 NFS: Setuid = 0, Setgid = 0, Sticky = 0 NFS: Owner's permissions = rw- NFS: Group's permissions = r-- NFS: Other's permissions = r-- NFS:Link count = 1, User ID = 65534, Group ID = 65534 NFS:File size = 0, Used = 0 NFS:Special: Major = 0, Minor = 0 NFS:File system id = 4043050865918775236, File id = 76891976 NFS:Last access time = 08-Apr-09 12:31:02.142519229 GMT NFS:Modification time = 08-Apr-09 12:31:02.142519229 GMT NFS:Attribute change time = 08-Apr-09 12:31:02.142519229 GMT NFS: NFS: Pre-operation attributes: NFS:Size = 4096 bytes NFS:Modification time = 08-Apr-09 12:30:16.342515644 GMT NFS:Attribute change time = 08-Apr-09 12:30:16.342515644 GMT NFS: NFS: Post-operation attributes: NFS:File type = 2 (Directory) NFS:Mode = 041777 NFS: Setuid = 0, Setgid = 0, Sticky = 1 NFS: Owner's permissions = rwx NFS: Group's permissions = rwx NFS: Other's permissions = rwx NFS:Link count = 23, User ID = 8107, Group ID = 0 NFS:File size = 4096, Used = 8192 NFS:Special: Major = 0, Minor = 0 NFS:File system id = 4043050865918775236, File id = 76418198 NFS:Last access time = 08-Apr-09 12:26:45.964579229 GMT NFS:Modification time = 08-Apr-09 12:31:02.142519229 GMT NFS:Attribute change time = 08-Apr-09 12:31:02.142519229 GMT NFS: NFS: I can make a full snoop (from mount on) available on request. Thanks for any help, Drew
