Red Hat Bugzilla – Full Text Bug Listing
|Summary:||NFS Mounts to remote server no longer work correctly after upgrade from FC12 to FC13|
|Product:||[Fedora] Fedora||Reporter:||Anthony Name <anothersname>|
|Component:||nfs-utils||Assignee:||Steve Dickson <steved>|
|Status:||CLOSED WONTFIX||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||13||CC:||anothersname, jlayton, m.a.young, steved, tore|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2010-10-14 11:47:58 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Anthony Name 2010-06-06 14:37:45 EDT
Description of problem: An upgrade from Fedora 12 to Fedora 13 does not allow existing NFS connections to re-establish after the upgrade. The error log includes errors such as rpc.idmapd: nss_getpwnam: name 'email@example.com' does not map into domain 'localdomain' any mount is shown as user permissions "nobody:nobody" Version-Release number of selected component (if applicable): nfs-utils-lib-1.2.2-2.fc13.x86_64 kernel 126.96.36.199-112.fc13.x86_64 How reproducible: Upgrade a FC12 machine with working NFS connections to a remote server to FC13 and they'll no longer work. A clean installation of FC13 does work. Steps to Reproduce: 1. Fairly self evident I hope. 2. 3. Actual results: NFS mounts only as permissions "nobody:nobody" and as thus have no write access to remote mount. Expected results: NFS mounts continue to work correctly and allow write access to remote mount. Additional info:
Comment 1 Anthony Name 2010-06-07 12:51:33 EDT
This is now somewhat more confusing. I have a script that does some manipulation on some data and tries to output the file to the server. It's this script that reports the server directory cannot be written to. However using the same user account as is running the script I can copy a file from the local machine to the remote server and the same directory on that server successfully. So.... Script running under user account 'someuser' cannot output to the server directory. manual cp command under user account 'someuser' can copy a file from the local machine to the same target directory. The local machine still reports the remote directories having permissions nfsnobody:nfsnobody. I'm not going to be able to keep this environment live as I will have to rebuild this box as a clean environment as the problem is stopping me using that machine for it's main task.
Comment 2 Jeff Layton 2010-06-07 13:00:37 EDT
You've likely gotten bitten by the change of the default nfs version from 3 to 4. What you may want to do as a workaround is add '-o vers=3' to the mount options. Longer term, you probably need to get your nfsv4 idmap domains synched up so that v4 works correctly for you.
Comment 3 Jeff Layton 2010-06-07 13:01:44 EDT
*** Bug 598345 has been marked as a duplicate of this bug. ***
Comment 4 Anthony Name 2010-06-07 16:47:33 EDT
Thanks for the feedback Jeff but I'd already started the rebuild when you posted. I'm sure you're right about the source of the error but please be aware it ONLY happens when you do an upgrade from FC12 (and possibly earlier versions) to FC13. A clean FC13 build works correctly without requiring any extra parameters and with the existing (FC12) mount parameters from /etc/fstab. The only reason to flag this up at all is because it's only being caused by the upgrade and needs to be flagged for the next Fedora iteration in the support docs.
Comment 5 Steve Dickson 2010-10-14 11:47:58 EDT
> I'm sure you're right about the source of the error but please be aware it ONLY > happens when you do an upgrade from FC12 (and possibly earlier versions) to > FC13. A clean FC13 build works correctly without requiring any extra > parameters and with the existing (FC12) mount parameters from /etc/fstab. I think the problem has to do with /etc/idmapd.conf did not get updated correctly... which is not the problem with clean installs... Also note, in F13 there is now a /etc/nfsmount.conf file were global variables can be set per server and per mount point. That might be a better solution that putting flags into /etc/fstab. I'm going to close this bug.... please feel free to reopen.