Centos – NFS default to 777

centosfile-sharingnfsPHP

I have an NFS share. This share is shared between several different applications. Our web server is running PHP and when it creates directories it is not setting the permissions correctly so it cannot write to the directory once created. How can I mount this NFS share to where PHP has full read/write access? Below is the directory that has been created along with the media server export options and the mount options on the web server. Ideally I could set the permissions on /opt/mount and whatever group/user is on that directory when I mount to that point the share assumes those permissions.

dr----x--t. 2 nobody nobody 4096 Jun  5  2014 user_2

Mount output:

media.dc1:/home/fs_share on /opt/mount type nfs (rw,vers=4,addr=10.10.20.127,clientaddr=10.10.20.42)

Exports file from media server:

/home/fs_share     10.10.20.0/255.255.255.0(rw,sync,no_root_squash)

Best Answer

You're using NFSv4. Too bad you did not specify your OS version, as it'll be rather important here.

Older versions of NFS used strictly UID/GID numbers, and so it was possible for the NFS server to be unaware of all the users and groups on the clients and vice versa - as long as the UID/GID numbers did not conflict, all was well.

But NFSv4 has the option of using user/group names instead of UID/GID numbers. If names are used, they are transmitted in form user@domain, where domain usually defaults to the DNS domain of each system, but can be changed to an arbitrary string if necessary. If the domain settings of the NFSv4 server and the NFSv4 client(s) won't match, or the user/group name mapping fails for any other reason, you're likely to see ownerships mapped to nobody and file permissions minimized - just like you're seeing.

In Linux, this user/group name mapping is done by the rpc.idmapd service. If this service is not running, that is also a possible cause for file ownerships getting mapped to nobody. In RHEL/CentOS/OEL 6.5 and older, this daemon should be running on both NFS clients and servers. (Yes, the client side has a /usr/sbin/nfsidmap upcall program that should make rpc.idmapd unnecessary on the NFS client side, starting from version 6.3... but it had a bug that was fixed only in RHEL/CentOS/OEL 6.6 and newer.)

In Linux, the NFS domain setting defaults to DNS domain name of the host, but it can be changed using the Domain = setting in /etc/idmapd.conf file. And in RHEL 6.3 and older, there was a bug that caused this setting to be ignored: if you're using NFSv4, you should upgrade to 6.4 or later. After changing the domain, you should run nfsidmap -c in 6.3 and newer; in older systems, you'll need to both restart the rpc.idmapd daemon and remount all NFS mounts.

If you wish to disable NFSv4's idmapping functionality and instead fall back to NFSv3-style use of UID/GID numbers only (which may be useful if your NFS server is e.g. a NAS box that has no information of user accounts on the client systems), you'll need to ensure that the nfs kernel module option nfsv4_disable_idmapping is enabled:

echo "options nfs nfs4_disable_idmapping=Y" >> /etc/modprobe.d/nfs.conf

This module option exists on RHEL 6.3 and newer, and should be enabled by default, but it's best to make sure.

On the server side, falling back to NFSv3-style UID/GID behavior on NFSv4 will require two things. First, a similar kernel option needs to be verified (or explicitly set) on nfsd kernel module:

echo "options nfsd nfs4_disable_idmapping=Y" >> /etc/modprobe.d/nfs.conf

Second, the security for the NFS export must be sec=sys.

Again, both of these settings should be the defaults on modern systems, but when working on older systems it'll be best to verify them.

On a NetApp NAS, the setting to enable the use of numeric UID/GID values on NFSv4 is either:

options nfs.v4.id.allow_numerics on

or: 

cluster::> set diag
cluster::*> nfs server modify -vserver vs0 -v4-numeric-ids enabled

depending on NetApp version.

Related Topic