Hide Forgot
Description of problem: When specifying 'fsid=0' in one of the nfs exported filesystems in /etc/exports , Version-Release number of selected component (if applicable): nfs-utils-1.2.3-36.el6.x86_64 How reproducible: Always Steps to Reproduce: 1. On the server, specify 'fsid=0' in the test filesystem being exported, like this: /scratch *(rw,fsid=0,async,insecure,no_root_squash) 2. On the client, mount the filesystem with default options, i.e.: # mount -t nfs nfs.example.org:/scratch /mnt/rhel6/ 3. On the client again, proceed to change the owner of a file to one that does not exist in the server: # ls -l rhel6/josetest -rw-r--r-- 1 test2 test2 0 Nov 4 09:15 josetest # chown test3:test3 rhel6/josetest 4. Check the owner of the file in the client: # ls -l rhel6/josetest -rw-r--r-- 1 test3 test3 0 Nov 4 09:15 rhel6/josetest 5. And in the server: # ls -l /scratch/josetest -rw-r--r-- 1 502 502 0 Nov 4 09:15 /scratch/josetest Actual results: The uid and gid is translated properly in the client, but in the server it only references a non-existent uid/gid. Expected results: The uid/gid should be moved to nobody:nobody in both the server and the client, when it cannot map to an existing user in the server.
(In reply to Jose Castillo from comment #0) > > Actual results: > The uid and gid is translated properly in the client, but in the server it > only references a non-existent uid/gid. The reason this is happing is do the mount falling back to a v3 mount due to the fsid=0. Here is what's happening the mount nfs.example.org:/scratch /mnt/rhel6/ fails with ENOENT (No such file or directory) due to the fact fsid=0 setting /scratch as the root. Meaning there is no /scratch/scratch on the server. The ENOENT error code cause the mount to try a NFSv3 mount, that success. With V3 all uids/gids are integers. So when the client code the chmod the 502 integer is sent to the server and its used as the uid/gid. > > Expected results: > The uid/gid should be moved to nobody:nobody in both the server and the > client, when it cannot map to an existing user in the server. To make this happen simple mount the V4 "root" mount nfs.example.org:/ /mnt/rhel6/ This will be a successful V4 mount and the nobody:nobody will then come into play as expect.
Hi Steve, makes sense, but why do we see this behavior: /etc/exports: /scratch *(rw,fsid=0,async,insecure,no_root_squash) NFSv4 mount: # cat /proc/mounts ... sunrpc /var/lib/nfs/rpc_pipefs rpc_pipefs rw,relatime 0 0 nfs.example.org:/ /mnt/rhel6 nfs4 rw,relatime,vers=4,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.33.20.36,minorversion=0,local_lock=none,addr=10.33.20.128 0 0 [root@client rhel6]# touch /mnt/rhel6/testfile [root@client rhel6]# ll /mnt/rhel6/testfile -rw-r--r-- 1 root root 0 Dec 16 2013 /mnt/rhel6/testfile [root@client rhel6]# chown root:root /mnt/rhel6/testfile [root@client rhel6]# ll /mnt/rhel6/testfile -rw-r--r-- 1 nobody nobody 0 Dec 16 2013 /mnt/rhel6/testfile creating the file initial as root gives the perms root:root do a chown will switch it to nobody:nobody. Shouldn't this be consistent behavior? Creating file as root and chown to root should result in same file perms? Thanks, Martin
(In reply to Martin Schuppert from comment #4) > Hi Steve, > > makes sense, but why do we see this behavior: > > /etc/exports: > /scratch *(rw,fsid=0,async,insecure,no_root_squash) > > NFSv4 mount: > # cat /proc/mounts > ... > sunrpc /var/lib/nfs/rpc_pipefs rpc_pipefs rw,relatime 0 0 > nfs.example.org:/ /mnt/rhel6 nfs4 > rw,relatime,vers=4,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp, > timeo=600,retrans=2,sec=sys,clientaddr=10.33.20.36,minorversion=0, > local_lock=none,addr=10.33.20.128 0 0 > > [root@client rhel6]# touch /mnt/rhel6/testfile > [root@client rhel6]# ll /mnt/rhel6/testfile > -rw-r--r-- 1 root root 0 Dec 16 2013 /mnt/rhel6/testfile > > [root@client rhel6]# chown root:root /mnt/rhel6/testfile > [root@client rhel6]# ll /mnt/rhel6/testfile > -rw-r--r-- 1 nobody nobody 0 Dec 16 2013 /mnt/rhel6/testfile > > creating the file initial as root gives the perms root:root do a chown will > switch it to nobody:nobody. > > Shouldn't this be consistent behavior? Creating file as root and chown to > root should result in same file perms? Yes... Taking quick look it appears this could be server problems since the nobody is being returned in the SETATTR reply. This is definitely a different problem since it happens with or without fsid=0 set. Could you please open up another bugzilla report on this problem? Plese supply a binary wireshark network trace by doing the following tshark -w /tmp/data.pcap host <server> bzip2 /tmp/data.pcap
sure will open a new one