This is one of those simple-been-doing-this-forever things that, for some reason, has me stumped today.
When I try to NFS (v4) mount a directory, the user/group ownership shows up as user "nobody" even though /etc/passwd has values for the correct user names. How do I get it to mount with the correct user IDs?
Hume is the server, running CentOS 6, all updates applied, maybe a week or two ago Bender is the client, running CentOS 6, all updates applied, maybe a week or two ago.
### HUME ###
Hume has a backup saved in /home/spfs.450, the directory that I'm trying to export. [root@hume ~]# ll /home/spfs.450/ drwxr-xr-x 3 apache apache 3 Oct 8 2009 y.spfs drwxr-xr-x 3 apache apache 3 Feb 1 2010 yts.spfs --SNIP--
Hume is exporting with /etc/exports /home/spfs.450 192.168.254.0/255.255.255.0(rw,async,no_subtree_check,mp,no_acl,insecure,no_root_squash)
Hume has appropriate /etc/passwd entries: [root@hume ~]# grep -i apache /etc/passwd apache:x:48:48:Apache:/var/www:/sbin/nologin
To be sure, the files are numerically id'd as 48: [root@hume ~]# ls -ln /home/spfs.450/ drwxr-xr-x 3 48 48 3 Oct 8 2009 y.spfs drwxr-xr-x 3 48 48 3 Feb 1 2010 yts.spfs --SNIP--
Nothing shows in /var/log/messages either when I enable the export or when it's mounted by bender. [root@bender ~]# tail -f /var/log/messages
### BENDER ###
Bender is mounting the backup with the following command: [root@bender ~]# /bin/mount -t nfs 192.168.254.9:/home/spfs.450 /home/spfs.450
Files show up with the wrong user name. [root@bender ~]# ll /home/spfs.450/ drwxr-xr-x 3 nobody nobody 3 Oct 8 2009 y.spfs drwxr-xr-x 3 nobody nobody 3 Feb 1 2010 yts.spfs --SNIP--
Bender as appropriate /etc/passwd entries: [root@bender ~]# grep -i apache /etc/passwd apache:x:48:48:Apache:/var/www:/sbin/nologin
Nothing shows in /var/log/messages when I mount the export on Bender. [root@bender ~]# tail /var/log/messages
On Mon, 17 Mar 2014 15:10:28 -0700 Lists wrote:
When I try to NFS (v4) mount a directory, the user/group ownership shows up as user "nobody" even though /etc/passwd has values for the correct user names. How do I get it to mount with the correct user IDs?
Hello Mr. Lists:
Here are my notes that cover this occurrence.
If all users come up as nobody on a nfs mount:
Add nfs server name to the Domain = line in /etc/idmapd.conf on both the server and the clients, i.e. Domain = example.com
/sbin/service rpcidmapd restart /sbin/service nfslock restart /sbin/service nfs restart
Also, the complete hostname as specified (example.com) must be in /etc/hosts on the nfs clients as well as the server
Alas, this doesn't seem to have resolved the issue. (See results shown below) Your notes closely mirror the results of my google searches. Is there a way to have NFS server/client be very verbose and log where the error is occuring?
-Ben
On 03/17/2014 03:20 PM, Frank Cox wrote:
On Mon, 17 Mar 2014 15:10:28 -0700 Lists wrote:
When I try to NFS (v4) mount a directory, the user/group ownership shows up as user "nobody" even though /etc/passwd has values for the correct user names. How do I get it to mount with the correct user IDs?
Hello Mr. Lists:
My name is Ben :)
Here are my notes that cover this occurrence.
If all users come up as nobody on a nfs mount:
Add nfs server name to the Domain = line in /etc/idmapd.conf on both the server and the clients, i.e. Domain = example.com
On the server: [root@hume ~]# grep Domain /etc/idmapd.conf Domain = hume.mycompany.com
And the client: [root@bender ~]# grep Domain /etc/idmapd.conf #Domain = local.domain.edu Domain = hume.mycompany.com
/sbin/service rpcidmapd restart /sbin/service nfslock restart /sbin/service nfs restart
Server: [root@hume ~]# /sbin/service rpcidmapd restart Shutting down RPC idmapd: [ OK ] Starting RPC idmapd: [ OK ] [root@hume ~]# /sbin/service nfslock restart Stopping NFS locking: [ OK ] Stopping NFS statd: [ OK ] Starting NFS statd: [ OK ] [root@hume ~]# /sbin/service nfs restart Shutting down NFS daemon: [ OK ] Shutting down NFS mountd: [ OK ] Shutting down NFS services: [ OK ] Shutting down RPC idmapd: [ OK ] Starting NFS services: [ OK ] Starting NFS mountd: [ OK ] Starting NFS daemon: [ OK ] Starting RPC idmapd: [ OK ]
And the client: (nfs service wasn't previously running) [root@bender ~]# /sbin/service rpcidmapd restart Shutting down RPC idmapd: [ OK ] Starting RPC idmapd: [ OK ] [root@bender ~]# /sbin/service rpcidmapd restart Shutting down RPC idmapd: [ OK ] Starting RPC idmapd: [ OK ] [root@bender ~]# /sbin/service nfslock restart Stopping NFS statd: [ OK ] Starting NFS statd: [ OK ] [root@bender ~]# /sbin/service nfs restart Shutting down NFS daemon: [FAILED] Shutting down NFS mountd: [FAILED] Shutting down NFS quotas: [FAILED] Shutting down RPC idmapd: [ OK ] Starting NFS services: [ OK ] Starting NFS quotas: [ OK ] Starting NFS mountd: [ OK ] Starting NFS daemon: [ OK ] Starting RPC idmapd: [ OK ]
Also, the complete hostname as specified (example.com) must be in /etc/hosts on the nfs clients as well as the server
[root@hume ~]# grep hume /etc/hosts 192.168.254.9 hume.mycompany.com hume [root@hume ~]# exportfs -ra [root@hume ~]# hostname hume.mycompany.com [root@hume ~]#
[root@bender ~]# grep hume /etc/hosts 192.168.254.9 hume.mycompany.com hume [root@bender ~]# umount /home/spfs.450 [root@bender ~]# /bin/mount -t nfs hume.mycompany.com:/home/spfs.450 /home/spfs.450 [root@bender ~]# ls -ln /home/spfs.450/ drwxr-xr-x 3 99 99 3 Oct 8 2009 y.spfs drwxr-xr-x 3 99 99 3 Feb 1 2010 yts.spfs --SNIP--
On Wed, 19 Mar 2014 12:16:52 -0700 Lists wrote:
Alas, this doesn't seem to have resolved the issue. (See results shown below) Your notes closely mirror the results of my google searches. Is there a way to have NFS server/client be very verbose and log where the error is occuring?
Do your user numeric id's match between the nfs server and client?
On 03/19/2014 12:28 PM, Frank Cox wrote:
Do your user numeric id's match between the nfs server and client?
Yes, and despite restarting all services manually, only a SIMULTANEOUS cold reboot for both client and server "resolved" the issue. (I've already rebooted by the client and server multiple times trying to sort it all out) So now, something ELSE has broken in the process: the client mounted a different directory on a different server via NFS, and now it is mounting as nobody.
Based on setting the "Domain" parameter id idmapd.conf on the client, is this supposed to be the case that a client cannot mount NFS shares from more than one server?
-Ben
On Wed, Mar 19, 2014 at 2:37 PM, Lists lists@benjamindsmith.com wrote:
On 03/19/2014 12:28 PM, Frank Cox wrote:
Do your user numeric id's match between the nfs server and client?
Yes, and despite restarting all services manually, only a SIMULTANEOUS cold reboot for both client and server "resolved" the issue. (I've already rebooted by the client and server multiple times trying to sort it all out) So now, something ELSE has broken in the process: the client mounted a different directory on a different server via NFS, and now it is mounting as nobody.
Based on setting the "Domain" parameter id idmapd.conf on the client, is this supposed to be the case that a client cannot mount NFS shares from more than one server?
I think idmapd is just broken in general unless you have a common network authentication system. I had it working across a set of servers, then added some more users (same uids across the set) and it wouldn't pick them up without a reboot. I think I'll switch to nfsv3 next time around.
On 03/19/2014 08:37 PM, Lists wrote:
On 03/19/2014 12:28 PM, Frank Cox wrote:
Do your user numeric id's match between the nfs server and client?
Yes, and despite restarting all services manually, only a SIMULTANEOUS cold reboot for both client and server "resolved" the issue. (I've already rebooted by the client and server multiple times trying to sort it all out) So now, something ELSE has broken in the process: the client mounted a different directory on a different server via NFS, and now it is mounting as nobody.
Based on setting the "Domain" parameter id idmapd.conf on the client, is this supposed to be the case that a client cannot mount NFS shares from more than one server?
It is very strange that client can mount directory on DIFFERENT SERVER? It looks like you have DNS/IP issues on your network?
I used autofs and IP address to point it to desired server, to avoid possible DNS problems.
On 03/19/2014 02:44 PM, Ljubomir Ljubojevic wrote:
It is very strange that client can mount directory on DIFFERENT SERVER? It looks like you have DNS/IP issues on your network?
I used autofs and IP address to point it to desired server, to avoid possible DNS problems.
I've resolved this issue, in a way that both uses the server names (instead of IP) but avoids DNS problems also and allows you to use shares from multiple servers. Every instruction I read indicated that the hostname value was important. Careful scrutinizing of the config file reveals that there are really two values that are important, so here's my rough instruction:
1) /etc/idmapd.conf # Set domain to the domain name shared by your NFS servers. Domain: mycompany.com Set local-realms to the name of the nfs servers you'll be using. THIS WASN'T MENTIONED ELSEWHERE. Local-Realms: nfs1.mycompany.com,nfs2.mycompany.com # make the above changes on all the servers in question.
2) /etc/hosts: list with all the NFS servers you specified in local-realms above. This way DNS errors don't make your servers get "hung" 1.2.3.4 nfs1.mycompany.com 1.2.3.5 nfs2.mycompany.com
3) Make sure you synchronize your /etc/passwd files so that the account IDs match up or you'll get very strange results.
4) Reboot EVERYTHING. Restarting services (in my case) was not enough. For documentation's sake, I restarted rpcidmapd, nfslock, and nfs, but didn't get the correct permissions until reboot. It doesn't seem important to run the nfs service on the clients.
5) Client mount: # CLI /bin/mount -t nfs hume.schoolpathways.com:/path/to/share /local/mount/point
# /etc/fstab nfs1.mycompany.com:/path/to/share /local/mount/mount nfs ro,nolock 0 0
# mount -a
On 03/19/2014 08:16 PM, Lists wrote:
Alas, this doesn't seem to have resolved the issue. (See results shown below) Your notes closely mirror the results of my google searches. Is there a way to have NFS server/client be very verbose and log where the error is occuring?
-Ben
On 03/17/2014 03:20 PM, Frank Cox wrote:
On Mon, 17 Mar 2014 15:10:28 -0700 Lists wrote:
When I try to NFS (v4) mount a directory, the user/group ownership shows up as user "nobody" even though /etc/passwd has values for the correct user names. How do I get it to mount with the correct user IDs?
Hello Mr. Lists:
My name is Ben :)
Here are my notes that cover this occurrence.
If all users come up as nobody on a nfs mount:
Add nfs server name to the Domain = line in /etc/idmapd.conf on both the server and the clients, i.e. Domain = example.com
On the server: [root@hume ~]# grep Domain /etc/idmapd.conf Domain = hume.mycompany.com
And the client: [root@bender ~]# grep Domain /etc/idmapd.conf #Domain = local.domain.edu Domain = hume.mycompany.com
/sbin/service rpcidmapd restart /sbin/service nfslock restart /sbin/service nfs restart
Server: [root@hume ~]# /sbin/service rpcidmapd restart Shutting down RPC idmapd: [ OK ] Starting RPC idmapd: [ OK ] [root@hume ~]# /sbin/service nfslock restart Stopping NFS locking: [ OK ] Stopping NFS statd: [ OK ] Starting NFS statd: [ OK ] [root@hume ~]# /sbin/service nfs restart Shutting down NFS daemon: [ OK ] Shutting down NFS mountd: [ OK ] Shutting down NFS services: [ OK ] Shutting down RPC idmapd: [ OK ] Starting NFS services: [ OK ] Starting NFS mountd: [ OK ] Starting NFS daemon: [ OK ] Starting RPC idmapd: [ OK ]
And the client: (nfs service wasn't previously running) [root@bender ~]# /sbin/service rpcidmapd restart Shutting down RPC idmapd: [ OK ] Starting RPC idmapd: [ OK ] [root@bender ~]# /sbin/service rpcidmapd restart Shutting down RPC idmapd: [ OK ] Starting RPC idmapd: [ OK ] [root@bender ~]# /sbin/service nfslock restart Stopping NFS statd: [ OK ] Starting NFS statd: [ OK ] [root@bender ~]# /sbin/service nfs restart Shutting down NFS daemon: [FAILED] Shutting down NFS mountd: [FAILED] Shutting down NFS quotas: [FAILED] Shutting down RPC idmapd: [ OK ] Starting NFS services: [ OK ] Starting NFS quotas: [ OK ] Starting NFS mountd: [ OK ] Starting NFS daemon: [ OK ] Starting RPC idmapd: [ OK ]
Also, the complete hostname as specified (example.com) must be in /etc/hosts on the nfs clients as well as the server
[root@hume ~]# grep hume /etc/hosts 192.168.254.9 hume.mycompany.com hume [root@hume ~]# exportfs -ra [root@hume ~]# hostname hume.mycompany.com [root@hume ~]#
[root@bender ~]# grep hume /etc/hosts 192.168.254.9 hume.mycompany.com hume [root@bender ~]# umount /home/spfs.450 [root@bender ~]# /bin/mount -t nfs hume.mycompany.com:/home/spfs.450 /home/spfs.450 [root@bender ~]# ls -ln /home/spfs.450/ drwxr-xr-x 3 99 99 3 Oct 8 2009 y.spfs drwxr-xr-x 3 99 99 3 Feb 1 2010 yts.spfs --SNIP--
try
/usr/sbin/nfsidmap -c
on the client. Since I put this into my /etc/rc.local , I don't have the problem any longer.
HTH, Kay
On Thu, Mar 20, 2014 at 5:29 AM, Kay Diederichs kay.diederichs@uni-konstanz.de wrote:
try
/usr/sbin/nfsidmap -c
on the client. Since I put this into my /etc/rc.local , I don't have the problem any longer.
Thanks - do you know where you found the documentation for that? Not the man page but something that tells you that you need it in the first place.
-
Frank Cox -
Kay Diederichs -
Les Mikesell -
Lists -
Ljubomir Ljubojevic