Score:4

Users unable to create files/directories on NFSv3 mount, but can modify

pr flag

I've got two RHEL 6 servers, one is an NFS server (we'll call it nfs-server, say its IP is 10.1.1.1), and the other is a generic client for all intents and purposes (we'll call it nfs-client, say its IP is 10.0.0.1).

Both nfs-server and nfs-client are connected to the same centralised authentication system, so UIDs/GIDs are the same for a given user.

nfs-client is mounting an NFSv3 share from nfs-server:/shared_folder/cache to /shared_folder/cache.

The /shared_folder directory on nfs-server is in mode 755, owned by root:root, and the /shared_folder/cache directory is in mode 2775, owned by cache:cache (UID=20014, GID=20004).

I have a set of users who are all members of the cache group in LDAP, but they cannot create or delete anything in the /shared_folder/cache directory itself on nfs-client. However:

  • If a file already exists in /shared_folder/cache that has the correct permissions (writable by group cache), the users can modify the file, but not delete it (e.g. if /shared_folder/cache/testfile exists, and is writable by the cache group, the users can modify the contents of the file, but they cannot delete it)
  • If a subdirectory already exists in /shared_folder/cache that has the correct permissions (mode 2775, owned by cache:cache), the users can modify the directory as normal (e.g. if /shared_folder/cache/testdir/ exists in mode 2775 and owned by the cache group, the users can add/modify/delete files and directories in testdir, but cannot delete testdir itself)
  • If I log in as one of the users on nfs-server, all of a sudden I am able to create/modify/delete files and directories as normal within /shared_folder/cache

How can I fix this NFS mount? Diagnostic info is below the horizontal rule.


The output of id user1 on both nfs-server and nfs-client shows:

uid=8173(<username>) gid=8173(<username>) groups=20004(cache)

nfs-server has the following export configured in /etc/exports:

"/shared_folder/cache"        <nfs-client-IP>(rw)

The output of exportfs -v on nfs-server shows:

/shared_folder/cache
                   <nfs-client-IP>(rw,wdelay,root_squash,no_subtree_check,sec=sys,rw,root_squash,no_all_squash)
PatrickTaylor avatar
it flag
Out of curiosity, can the cache USER (uid 20014) create and delete files under /shared-folder/cache from the nfs client ?
rst-2cv avatar
pr flag
Yes it can @PatrickTaylor
Score:1
my flag

Deleting a file requires write privileges on the directory.

You have correctly set rw in the mount options, but something seems to be wrong on the NFS side (since you can delete files by logging in the server).

Some things I would do:

  • Check the default umask.

  • Check permissions on the files using lsattrand getfacl.

  • Ensure no one else is accessing that file while you're trying to delete it (lsof).

  • If SELinux is in enforcing mode, check the audit logs (preferably using audit2why).

  • Try adding the sync mount option.

As a last resort workaround, delete and create again users and groups on the server and restart the NFS server.

rst-2cv avatar
pr flag
Thanks for the reply. Umask is fine (`0002` and `0022` for all pertinent users), no FACLs are set anywhere in the directory structure, lsattr doesn't reveal anything wrong, SELinux is disabled (not my choice, but at least we know that's not the source of the issue), and adding the sync mount option doesn't work. I can't delete and re-create the users since they are all LDAP users/groups, which are used by users across the environment.
A. Darwin avatar
my flag
@rst-2cv how about lsof? Is the file you're trying to delete being locked by something else?
rst-2cv avatar
pr flag
My bad, I missed that one. (Un)fortunately not.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.