View Full Version : [SOLVED] NFS4 nobody nobody

2nd April 2011, 05:02 PM
I don't get it - yesterday all was well. This morning my NFS shares mount but permissions are all NOBODY NOBODY. If I ssh to the server to check the drive(s) permissions are all as they should be! Exports there are fine as is my local fstab. I hope I am just suffering and update glitch because they usually go-away in a subsequent update.

I just spent an hour and a half trying to track it down with no success - time to give up before I do real damage (to which I am prone :D).

fc14 on both

2nd April 2011, 05:11 PM
Not sure I can help, but did you update the server, or the client, or both?

2nd April 2011, 05:44 PM
ssh'd yum update thru the house! Heh.

Whatever went wrong is on the server - all the other clients have the same issue with the NFS shares from that machine. Perhaps tomorrow I'll delete and rewrite the exports file. If that doesn't work, maybe I'll reinstall all the NFS stuff.

2nd April 2011, 05:59 PM
Are the support services running ?

On the server & client, at a minimum ....
service rpcidmapd status

2nd April 2011, 06:09 PM
It just got uglier (and more likely a bug) - I now cannot access Web pages on the machine internally either - 403 You don't have permission. Not actually an NFS problem.

Net chance I get to reboot the machine, I'll pick an older kernel and see what gives.

3rd April 2011, 07:42 PM
Found Web page issue - unrelated. DID find this in my /var/log/messages just now: rpc.idmapd[1537]: nss_getpwnam: name 'root@mydom' does not map into domain 'localdomain'

I see (without an understandable solution) on another forum that NFS4 has changed UID/GID mapping and that is why I am having this problem. They mention changing /etc/passwd to UID/GID mapping. HUH????

---------- Post added at 02:42 PM ---------- Previous post was at 02:31 PM ----------

ALSO - checked /etc/passwd on the machines: all my user/group ids match (I was careful about that!)

8th April 2011, 12:47 PM

The owners nfsnobody or nobody are correct, that's what they should be.

9th April 2011, 04:40 PM
It's never been that way until a week or so ago. It also appears that anyone can do anything to any file on those shared drives now.

9th April 2011, 07:06 PM
Have you check rpcidmapd service?

IF the files are owned by nobody on the server then this is what to expect.
If you don't have the rpcidmapd service running then all UIDs will be translated to nobody.

9th April 2011, 07:11 PM
Yes. I am able to access, change, move files, etc. The ownership is a mess from remote machines, though. All machines in the house are OK except for this ONE PC that has this problem. And all machines that access this one get the same nobody/nobody ownership issues. When these other machine access each other have all the correct ownership info. All run Fedora 14.

9th April 2011, 07:23 PM
And the one with the problem is your server?

9th April 2011, 07:30 PM
Correct - but he is not the only one sharing files via NFS. This was all noticed almost immediately after a reboot following YUM UPDATE to all of the machines. He's the only one that did this. All updates ran without problems/error.

9th April 2011, 07:33 PM
Is the rpcidmapd service running?

9th April 2011, 07:40 PM
Additional notes - it appears to be some sort on NFS "facade" as files get saved with the correct owners/groups (verified by ssh into that PC). But owner/group/permission info cann't be chnged from a remote - cause nobody is the owner, not "root", for instance. rsync (used for backup) errors with hundreds of 'chmod' errors. It is not about to 'retain permissions' for theses NFS cross-machine copies.

---------- Post added at 02:39 PM ---------- Previous post was at 02:38 PM ----------

Yes, it is running.

---------- Post added at 02:40 PM ---------- Previous post was at 02:39 PM ----------

service rpcidmapd status
rpc.idmapd (pid 1537) is running...

10th April 2011, 05:24 PM
I almost hate to ask this, but in the interest of honesty: I wonder if the 'nested' exports have something to do with this; I stumbled across only a mention of this last week. I Shared several directories for my users. Then I shared the drive (/) itself for myself. I wonder if I just removed those user shares from my exports.

While this hasn't changed since set up a couple years ago, I wonder if an update (with stricter rules) is the 'cause'.

---------- Post added at 12:24 PM ---------- Previous post was at 12:15 PM ----------

Whew! Just eliminated the nests & rebooted - no change to nobody/nobody problem. Yes - also rebooted 'client' in all this.

12th April 2011, 10:35 AM
I don't know what your trying to achieve but a standard setup for NFS4 uses user nfsnobody on fedora, that's the user you set in idmapd.conf. In /etc/exports you allow access to your lan ( for each share.

On the client side you set idmapd.conf to user nobody or nfsnobody. With NFS4 the same user/group accesses the files and if you want to restrict access to certain shares, you have to define the hosts you want to allow in /etc/exports.

12th April 2011, 01:00 PM
Until a few weeks ago, I could (via the GUI) right-click/properties/permissions on a file or folder on my shares and see or perhaps even adjust the permissions. Now, I must open a terminal and ssh into the PC, etc., to see or change permissions. Also, rsync is now complaining during backup about not being able to adjust permissions on a fantastic number of files - this started at exactly the same time the nobo0dy/nobody issue started.

The idmapd files were just as you said they should be. I've never touched them.

Incidentally, this PC is the ONLY ONE experiencing this nobody/nobody - with drive mappings in either direction (to or from other machines). Those same shares on other machines to other machines show actual owners/groups. If it were all the shares I'd figure this was normal.


12th April 2011, 01:34 PM
last question: Do you have "sec=sys" on the server exports, or is it defaulting?

If it is defaulting try specifying sec=sys on the export options.

12th April 2011, 02:22 PM
Are you sure you're not getting confused with NFS4 setup and NFS3? The setup is completely different, are your shares bind mounted?

Take a look at this: http://www.crazysquirrel.com/computing/debian/servers/setting-up-nfs4.jspx

In /etc/exports don't use 'sync' use 'async'.

16th April 2011, 04:53 PM
New info - just discovered, it seems to be the 64 bit machines that aren't playing nice.

17th April 2011, 02:34 AM
Are you using sssd? I used to have sss cache get messed up when the server gets inadvertently booted, but it hasn't happened for a while. The symptom was always that nfs mounts would show up as nfsnobody owned.

If you are running sssd, one thing to do is stop sssd, clean up sss cache in /var/lib/sss/db/, then start sssd to re-generate the cache as needed.

30th May 2011, 06:07 PM
I have a Fedora 13 NFS server with Fedora 13 and 14 clients that have been running correctly with permissions showing proper user and group names on the client's mount points.

/etc/exports entries on the server are identical for all clients. Clients get their addresses and other information from dhcp served by dnsmasq on the local network. The dnsmasq server also supports a local domain "foo.home" (actual name changed to obscure hopefully needless detail... the point is that "/foo/home" is not in the internet's dns anywhere) that never gets seen outside the local network. The clients all believe that they are in the "foo.home" domain and dnsmasq forwards external dns queries.

I installed a new Fedora 15 on one of the client systems (new install, not upgrade) and found that the mount point on the Fedora 15 client now shows "nobody nobody" for all files.

After reading all the various google search results, I came up with the following:

Edit /etc/idmapd.conf on both client and server.

Near the top in the [General] section I uncommented the line
#Domain = local.domain.edu
and changed it to

Restarted both server and client's rpc.idmapd.

The names on the client mount point now show up properly as they did on the fedora-13/14 clients

This is probably in indication that dnsmasq is not properly giving the clients their domain information in a fully consistent way, but that will wait for another day.

30th May 2011, 09:43 PM
Thank you, SkipE. That simple edit fixed it!!!

24th June 2011, 06:35 PM
This issue has been driving me nuts for a while! Thanks a million SkipE!

9th August 2011, 07:00 PM
This did it for me too - I changed my domain from localhost to something else, and that must have broken it.

Thanks again for the tip!!