I am having an issue with getting the proper group settings on NFS-shared directories.
NFS server, NFServe, nfs-shares hundreds of project directories...running Solaris 10 latest patches/updates.
SAS server, SAServe, statistical analysis server running on RedHat 7 with latest kernel/patches/etc.
NFServe uses ancient Sun Directory Server for LDAP.
SAServe uses Active Directory on win2008r2. UIDs and GIDs set up matching on LDAP/Unix/AD (so if you are group ibex GID 5005 on LDAP, you are group 5005 on AD).
NFServe also nfs-shares project directories to an old SAS server also running Solaris 10 and all groups are correct.
On SAServe, all but six of the nfs-shared directories show the proper groups. However, on six of them, the group is nobody.
Does anyone have any suggestions where to look? I can't find the problem, and I can't find anything that makes these groups/directories unique.
If I do an ls -l listing of the nfs-shared directories on the sas server they should show owner:group something like this
drwxrwx--- jbrown dev patches
drwxrws--- ssmith prod real_work
etc.
However, on six of several hundred directories (which have the correct group), it shows:
drwxrwx--- jbrown nobody document_files
when it should be:
drwxrwx--- jbrown hrdept document_files
So the problem is that the document_files directory, which should be jbrown:hrdept (and that's the way it is on the nfsserver) is showing up as jbrown:nobody and the only one who can access it is jbrown.
When I google this, I find instances where ALL directories are set to the group nobody, but I can't find anyone else who has just a couple set to nobody and all the others set properly.
Go to each the directories and run df .
It gives you the export path on the NFS server.
A quick comparison is done with the inode number: ls -lid .
If they *are* identical then there is a problem with different GID-group mapping.
I may be running afoul of the fact that unix can have the same name for a user and a group whereas that is not permitted in Active Directory. But that doesn't explain all of the cases.
Related to the nsswitch.conf question, obviously, on the nfsserver groups is files ldap and on the RH7 machine it's files sss.
Neither system runs nscd (solaris or rh). I inherited the S10 system, so I don't know why it was set up that way. I believe there are some reported issues running NSCD in conjunction with AD on RH, but I'd have to go back and re-research that.
You see the "oops" in your suggestion, correct? The group on one system is listed as "nobody" so ls -nd is going to show the gid (99) for nobody. On the other system, it's going to show the gid for the correct group. So they will never match until I get this fixed.
Not one post in this thread has shown the actual numeric IDs.
Until you know what the numeric IDs actually are, you can't tell where your problem is. Are the IDs getting changed from the server? Or the client? Or just in the ID lookup?
When an nfs-receiving system cannot resolve a groupname/gid, by default and design, it assigns that file/directory to the "nobody" group. Nobody is a real group. On RH7, it is gid 99.
What is happening is that the nfs-sharing server is providing the groupname/gid acrn/10001, and the nfs-receiving system can't understand something about that. So, it bails out and gives it to nobody.
I think you were expecting that the receiving system would list the group for the directory as 10001 but somehow think the groupname for 10001 was nobody. It doesn't work that way. The directory is nobody (gid 99).
#ls -l /data/acrn
drwxrwx--x 51 jsmithi nobody 66 Oct 24 07:24 acrn
# ls -ln /data/acrn
drwxrwx--x 51 119 99 66 Oct 24 07:24 acrn
# id -a 99
uid=99(nobody) gid=99(nobody) groups=99(nobody)
It's doing exactly what's expected because it doesn't understand or know the group acrn/10001...it gives the directory to nobody. But it does know acrn.
Here is a follow-up for someone who may someday come down this path. RedHat 7 does not used idmapd so there is no idmap.conf. It uses sssd, which has a parameter ldap_id_mapping which controls how it gets uid/gid from the AD server. When ldap_id_mapping = true in sssd.conf, the RH machine will use the SID concocted by Windows. When ldap_id_mapping=false, the linux box will use the uid/gid that is contained in each user's individual AD configuration panel under the Unix Attributes tab. If you had, for example, existing local users and wanted to move them to AD, you would create their accounts in AD and use the same uid/gids in the Unix Attributes tab. So local user Joe with UID 10001 on a linux box would be set up as AD UID 10001 in AD. RedHat 7 documentation says it doesn't matter what the name is...one could be JoeDoe and the other could be Joe...all that matters is that the uid/gid match. This doesn't seem to be completely true, however, since I have group acorn (gid225) on Unix and acornx (gid225) on AD, and the directory ends up with the group "nobody." Unfortunately, Linux doesn't have a way of finding out what the two machines said to each other when they talked about gid 225 and how they determined that they weren't a match so the Linux side would substitute "nobody" for acorn. As Neil Young says, "You pay for this and they give you that."
---------- Post updated Mar 11th, 2015 at 10:24 AM ---------- Previous update was Mar 10th, 2015 at 04:21 PM ----------
Final resolution. NFS client must specify nfsvers=3 as mount option either on command line for mount command (e.g. mount -t nfs -o nfsvers=3 nfsserver:/share /data)
or in fstab.