| Summary: | When specifying 'fsid=0' in /etc/exports, idmapd does not map unresolvable users to 'nobody' | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Jose Castillo <jcastillo> |
| Component: | nfs-utils | Assignee: | Steve Dickson <steved> |
| Status: | CLOSED NOTABUG | QA Contact: | Filesystem QE <fs-qe> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 6.4 | CC: | mschuppe, steved |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2013-12-16 14:38:55 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Bug Depends On: | |||
| Bug Blocks: | 994246 | ||
|
Description
Jose Castillo
2013-12-06 15:32:59 UTC
(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 |