File permissions using NFS

I have a server running NFS server, using ext4 on all drives. In the /home directory is a directory called common. I would like all files saved in this directory, including additional directories, to have the group attributes set to RWX upon being saved, not after the fact. I would like this to happen without having to change the umask (which is currently 0022) for each computer (which are all running ext4). According to my understanding of the man page, setting the s attribute on the directory should do this. However, I can’t seem to get it to work. Can someone please explain how to do this?


I’m not sure which man page you are looking at.

The “umask” is a per user (or per-process) property. Normally, NFS file permissions are the same as for a local file system, except that root might be wrapped to “nobody” (depending on the share options).

The “s” group permission on a directory forces all created files and subdirectories to default to the same group. It doesn’t affect the “rwx” permission bits. It affects the group (i.e. which named group to use).

So the s flag is not what I want.

Is there a way to set rwx attributes based on directory?

Or, how can I make any files in a directory have rwx attributes without changing umask on the originating computer?


Is saving a file to a NFS drive a process? If so, how to set the umask for that property? What if I don’t want “Normally”? How to set file permissions for just NFS?


Attributes are copied with the files. No directory flag will change the attributes. The flags only deal with attributes on newly created files in a directory. In any case attribute change can only be done by the owner or root. So I guess it would be a good idea to say exactly how these files are being copied and by who.

A example of what I want to be able to do is to create a LibreOffice document on my machine, save it to the server. and have my wife modify it and replace it. Perhaps I’ll do more modifications, perhaps her even more. In other words, I would like any file saved to the common directory on the server to be able to be modified by anyone who can access the server.


I don’t think it is actually possible.

For what you are wanting to do, your best bet might be to use a Windows file system (FAT or NTFS). In that case, the permissions are set by the mount options. Unless you will be having really large files (4G or larger), I would suggest FAT.

I don’t think I like that answer! lol!

Guess I’m just going to have to teach my wife how to change permissions on files she wants me to help her with! Now, that should be fun!

You know she’s going to remind me how we could do that when we had a Windows server! :frowning:


Have her set her umask to 002 instead of 022. It can be set in “.profile” in her home directory.

If this is a home computer, there isn’t much risk. Even more so, if only files on the NFS mounted file system are shared.

The only problem is that a few programs are very fussy about group-writable. The main ones are “ssh” and “gpg”, which insist that the home directory and their config directories (“.ssh” and “.gnupg”) not be group writable.

I have not seen anybody mention FACLs (filesystem ACLs) yet, which makes
me wonder if maybe those will not work via NFS, but otherwise I think they
are the solution. The setfacl command lets you set permissions on things
that exist now, or “default” permission (ACLs) on things that will exist
in the future within a directory, so that sounds ideal. Assuming
/path/to/directory is the location, and ‘users’ is the group you want to
have rwx rights (why ‘x’?) on files, these commands should both modify
everything currently as well as make it work going forward with new

#sets default ACL on existing files/directories recursively
setfacl -R -d -m g:users:rwx /path/to/directory

#sets ACL on existing files/directories recursively
setfacl -R -m g:users:rwx /path/to/directory

Once done, the ‘users’ group members should have rwx on everything within
/path/to/directory and anything new should get those too.

FACLs are a bit weird, and sometimes thought to be fairly complex, but
once you understand the basics I think they are simple enough, and
infinitely flexible. The simplicity of user-owner, group-owner, and
other-users is extended nicely, though the simplicity of only those three
sources of rights/permissions is lost by adding that additional
flexibility, so maybe that’s part of the reason for the stigma.

Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.

At the OP.

I did not read all that is said above, but my idea is that you have some misconceptions.

Permissions are not influenced at all by NSF, nor v.v. So when you understand them, then that works for all files, regardless if you cross a boundary in the directory tree to a mounted files system and thus also regardless if that mounted file system is of type NFS.

When you want some place to put files where a group of users (in this case two users that are “owned” by you and your wife) must have read and write access, a good solution is to put those users in the same primary group (that may be “users”, which is the default in openSUSE, but it may also be another one to protect them from again more users on the system) and those users must then have the r and w permission set for group (when those users have an umask set to 007 or less restrictive, that will be the case for most, if not all, newly created files).

Of course the path to those files must also be accessable for those users. Thus all directories leading to them must have at least r-x permisions for e.g. the group (when the group is owning group) or for others.


henk@boven:~> ls -l /home
totaal 32
drwxr-xr-x  6 mysql  mysql 4096  7 jun  2015 databases
drwxr-xr-x 85 henk   wij   4096  4 dec 09:54 henk
drwx------  2 root   root  4096 25 okt  2009 lost+found
drwxr-xr-x 35 marian wij   4096 17 jun  2016 marian
drwxr-xr-x 12 mgi    users 4096 28 nov 08:53 mgi
drwxr-xr-x 17 smweb  www   4096 28 nov 08:40 smweb
drwxr-xr-x  8 wappl  www   4096 18 jul  2015 wappl
drwxrwxrwx 22 henk   wij   4096  1 dec 12:29 wij

Two users henk and marian, primary group wij, each have their own home directory henk and marian.
The directory wij (no need to have the same name as the group wij, but that seemed easy to me) is owned by henk (I choose one of the members of group wij) and group wij.
Because this directory wij is rwxrwxrwx (rwxrwx— would be enough in fact) everybody can search, add files, remove files, etc. in wij. Thus henk and marian can do the same things in wij as they can do in their home directories.
When they then have at least rw-rw---- on files there and rwxrwx— on directories the other can do the same as they can do themselves. Setting that can be done as said mainly by choosing a good umask, but of course also manualy, or by a crontab run (every 5 mins seems to be enough).

Now over to NFS.
Main thing here is that you should have the same userid for the same user on both systems (this is not about the usernames, but normaly you would also use the same usernames on both system to make living easy). Thus when you are 1000 on one system, you should also have 1000 on the other one. Same for your wife that e.g. has 1001 on both. The permissions work by userid and not by username.

This is my export on the NFS server:

henk@boven:~> cat /etc/exports
/home/wij       b*,sync,no_subtree_check)

It exports /home/wij to all systems were the hostname start with a character b in the domain (tyou might want to simply use the IP address of the other system, or maybe just * for all systems that can connect).

In the client’s /etc/fstab:    /home/wij nfs    noauto    0 0 

So it is mounted on the same place as on the server (that is not a must).

HTH. And of course ask if more info is wanted.

Thank you much for the thorough reply. I’ll try it and see how it works for me. Going to take a few days though, I’m up way too early and still up way too late. Busy, busy, busy!