|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0012950||CentOS-7||nfs-utils||public||2017-03-13 00:18||2017-03-21 00:46|
|Target Version||Fixed in Version|
|Summary||0012950: problem with the management of the ID map cache|
|Description||CentOS 7.3 NFS server, CentOS 7.3 NFS client. NFS V4. NFS mount works fine. ID mapping works fine. However, if file system is unmounted and then mounted again after 10 minutes, UID and GID shows as 4294967294. Repeating the process, the ID mapping is correct. Repeating the process again, the ID mapping is wrong -- it alternates between correct and wrong.|
This happens with kernel 3.10.0-514.6.2.el7.x86_64 and
Replacing /usr/sbin/nfsidmap with the version from
solves the problem.
|Steps To Reproduce||server name: server|
file system on server: /export/foo
/export/foo on server includes directory /export/foo/bar
/export/foo/bar uid and gid map to the same normal user/group on both client and server
As root, run the "nfsprob" script attached. Output will have correct user/group in first iteration, then 4294967294, then correct again, etc.
|Tags||No tags attached.|
I've succeeded in reproducing this.
- On NFS server, "echo Y > /sys/module/nfsd/parameters/nfs4_disable_idmapping" #enable non-default id-mapping
- Edit /etc/idmapd.conf, set Domain=<domain> to same string in NFS server and client
- nfs client: mount -o nfsvers=4 server:/export/foo /mnt
- nfs client: wait until kernel keys shown in
grep id_ /proc/keys
go to "expd" (expired) state
(default 600secs, tunable in /etc/request-key.d/id_resolver.conf: nfsidmap -t 600)
- nfs client: umount /mnt; mount -o nfsvers=4 server:/export/foo /mnt
- nfs client: ls -l /mnt
ls -l /mnt
-rw-r--r--. 1 4294967294 4294967294 4 3? 14 16:34 bar-1001
-rw-r--r--. 1 4294967294 4294967294 4 3? 14 16:35 baz-501
"id_resolver" kernel keys, by default, is
created with 600 seconds lifetime, and after that, becomes
"expd" state, then deleted after 300 seconds.
If you umount/re-mount the NFS share during this 300 second window,
symptom (uid=(uid_t)-2) appears.
This is regression, or proper bugfix of,
nfsidmap not setting key timeouts
Using old nfs-utils-1.3.0-0.21, nfsidmap creates
nonexpiring "permanent" (perm) kernel keys, which masks the problem.
(You won't be able to change the mapping until reboot, though)
For unknown reason, the expired keys aren't refreshed properly.
On nfs client, invoke "systemctl start nfs" (yes, nfs server)
For unknown reason, this makes "id_legacy" keys linger for 600 seconds,
taking over the data of "id_resolver" keys.
- #enable non-default id-mapping
On NFS server, "echo N > /sys/module/nfsd/parameters/nfs4_disable_idmapping"
I've found an kernel.org upstream commit which fixes this.
After applying this patch, the id_resolver kernel key is properly refreshed
and thus NFSv4 id-mapping works as expected, across umount/mount.
Bonus: id-mapping is properly updated after 600seconds timeout
if you changed the mapping.
Note that user still can't write to the file despite uid# seems same;
this is limitation of NFS RPC.
This is the patch revised for CentOS kernel-3.10.0-514:
I am going to file kernel-bug on Red Hat Bugzilla, but don't expect much
since enabling id-mapping seems a non-standard usage.
(RH docs implicity says to use LDAP to sync uid#)
thanks for your work, really appreciated :)
RH has ack'ed and we can expect a fix from them.
|RHBZ says it will be fixed in kernel-3.10.0-616.el7 .|
|2017-03-13 00:18||centu478||New Issue|
|2017-03-13 00:18||centu478||File Added: nfsprob|
|2017-03-15 01:41||kabe||Note Added: 0028856|
|2017-03-15 03:28||kabe||Note Added: 0028857|
|2017-03-15 04:31||kabe||File Added: 0001-KEYS-request_key-should-reget-expired-keys-rather-th.patch|
|2017-03-15 04:46||kabe||Note Added: 0028858|
|2017-03-15 05:26||kabe||Note Added: 0028859|
|2017-03-15 09:01||tru||Note Added: 0028860|
|2017-03-21 00:46||kabe||Note Added: 0028891|