Does NFS support ACLs?

On the Linux NFS server, ACLs are designated by a '+' sign after the permissions:

ls -l /redirectedFolders/Users/mark
total 24
drwxrwx---+  7 mark domusers 4096 2015-10-15 19:29 Desktop/
drwxrwx---+ 10 mark domusers 4096 2015-08-18 02:38 Favorites/
drwxrwx---+ 10 mark domusers 4096 2015-08-19 12:57 My\ Documents/
-rwxrwx---+ 1 mark domusers 214 2013-02-08 15:20 /redirectedFolders/Users/mark/Desktop/speedtest.txt*

and can be viewed e.g.

getfacl /redirectedFolders/Users/mark/Desktop/speedtest.txt
getfacl: Removing leading '/' from absolute path names
# file: redirectedFolders/Users/mark/Desktop/speedtest.txt
# owner: mark
# group: domusers
user::rwx
user:3000002:rwx
user:3000003:rwx
user:3000008:rwx
group::---
group:users:---
group:3000002:rwx
group:3000003:rwx
group:3000008:rwx
group:3000026:rwx
mask::rwx
other::---

Select all Open in new window

When Is this same files from the NFS client host:

$ ls -l Desktop/speedtest.txt
-rwxrwx--- 1 mark domain users 214 Feb  8  2013 Desktop/speedtest.txt

No '+' sign. getfacl:

$ getfacl Desktop/speedtest.txt
# file: Desktop/speedtest.txt
# owner: mark
# group: domain\040users
user::rwx
group::rwx
other::---

David Johnson, MVP:

To set permissions you need the client for nfs to set nfs permissions directly

Trying to set acl in files on this mount fail:

$ setfacl --modify group:3000036:rwx Desktop/speedtest.txt
setfacl: Desktop/speedtest.txt: Operation not supported

But I can setfacl on other files on this host outside the nfs mount:

mark@uCommon:/tmp$ touch joe
mark@uCommon:/tmp$ ls -l joe
-rw-r--r-- 1 mark domain users 0 Oct 15 23:01 joe
mark@uCommon:/tmp$ setfacl --modify group:3000036:rwx joe
mark@uCommon:/tmp$ getfacl joe
# file: joe
# owner: mark
# group: domain\040users
user::rw-
group::r--
group:3000036:rwx
mask::rwx
other::r--

Select all Open in new window

This is telling me that NFS is not dealing with ACLs

As the user you only get your own settings.
When you added using setfacl wwhat is the reflected change on the server side?

Nothing. I couldn't do the setfacl. I got the "Operation not supported" message.

Your client setfacl example did not error out. Where do you get the errors using setfacl?

Difficulty with ACL it at times has robe reapplied

arnold:

Your client setfacl example did not error out. Where do you get the errors using setfacl?

I think I am getting an error ...

Here ls the `ls -l` of the several files in a folder on the NFS host:

$ ls -l
-rw-r--r--+ 1 mark    domusers         78 2015-10-16 17:38 phoneMessages
-rw-r--r--+ 1 mark    domusers       9216 2015-10-16 17:10 SURnoMember.xls
-rwxrwx---+ 1 3000026 domusers         27 2015-10-11 22:49 whatGIDUID.txt*

Select all Open in new window

Notice the '+' sign.

Here is the `ls -l` of that same folder mounted on the client workstation. Notice no '+' signs:

$ ls -l
-rw-r--r-- 1 mark    domain users         78 Oct 16 17:38 phoneMessages
-rw-r--r-- 1 mark    domain users       9216 Oct 16 17:10 SURnoMember.xls
-rwxrwx--- 1 3000026 domain users         27 Oct 11 22:49 whatGIDUID.txt

Select all Open in new window

Here is a `getfacl` for the file phoneMessages on the NFS host (where the file actually lives):

$ getfacl phoneMessages
# file: phoneMessages
# owner: mark
# group: domusers
user::rw-
user:3000002:rwx                #effective:r--
user:3000003:rwx                #effective:r--
user:3000008:rwx                #effective:r--
user:3000026:rwx                #effective:r--
group::---
group:users:---
group:3000002:rwx               #effective:r--
group:3000003:rwx               #effective:r--
group:3000008:rwx               #effective:r--
mask::r--
other::r--

Select all Open in new window

Here is the `getfacl` on the same file on the NFS client workstation:

$ getfacl phoneMessages
# file: phoneMessages
# owner: mark
# group: domain\040users
user::rw-
group::r--
other::r--

Select all Open in new window

Notice they are not the same. I do believe I have nfs4 enabled on both my server and client.

Now, here is the error I get on the client when I try to setfacl:

$ setfacl -m user:10001:rwx phoneMessages
setfacl: phoneMessages: Operation not supported

Select all Open in new window

So, as it stands, I am not getting the acl's from the server, nor can I set them on the client workstation.

When you ave the + reflecting the ACL is on the server?
On the workstation you use auto. To mount the location specifically for the user?

arnold:

When you ave the + reflecting the ACL is on the server?

Yes, the '+' is the `ls -l` on the server.

On the workstation you use auto. To mount the location specifically for the user?

Yes, I use autofs to mount the location on the client, but I have tried the same thing using a "permanent" mount in fstab too.

did you try to force nfs_version=4 in the mount options ?

skullnobrains:

did you try to force nfs_version=4 in the mount options ?

Yes. This is an autofs mount and the auto.misc entry looks like:

mark -fstype=nfs,nfsvers=4,acl,rw mail:/redirectedFolders/Users/mark

running `mount` as root gives:

mail:/redirectedFolders/Users/mark on /home/HPRS/mark type nfs4 (rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=192.168.0.99,local_lock=none,addr=192.168.0.2)

Select all Open in new window

The "vers=4.0" indicates to me that it is mounting as NFS version 4. However, still no '+' signs on files indicating extended attributes:

client ls:

mark@labrat:~$ ls -l
total 80
drwxrwx--- 10 mark domain users 4096 Dec 16 12:24 Desktop
drwxr-x---  2 mark domain users 4096 Oct 16 15:46 Documents
drwxr-x---  2 mark domain users 4096 Oct 16 15:46 Downloads
drwxrwx--- 10 mark domain users 4096 Dec 16 12:24 Favorites
drwxr-x---  2 mark domain users 4096 Oct 16 15:46 Music
drwxrwx--- 10 mark domain users 4096 Dec 16 12:24 My Documents
drwxr-x---  2 mark domain users 4096 Nov  9 14:38 Pictures
drwxr-x---  2 mark domain users 4096 Oct 16 15:46 Public
drwxr-x---  2 mark domain users 4096 Oct 16 15:46 Templates
drwxr-x---  2 mark domain users 4096 Oct 16 15:46 Videos

Select all Open in new window

server ls:

root@mail:/redirectedFolders/Users/mark
> ls -l
total 80
drwxrwx---+ 10 mark domusers 4096 2015-12-16 12:24 Desktop/
drwxr-x---+  2 mark domusers 4096 2015-10-16 15:46 Documents/
drwxr-x---+  2 mark domusers 4096 2015-10-16 15:46 Downloads/
drwxrwx---+ 10 mark domusers 4096 2015-12-16 12:24 Favorites/
drwxr-x---+  2 mark domusers 4096 2015-10-16 15:46 Music/
drwxrwx---+ 10 mark domusers 4096 2015-12-16 12:24 My\ Documents/
drwxr-x---+  2 mark domusers 4096 2015-11-09 14:38 Pictures/
drwxr-x---+  2 mark domusers 4096 2015-10-16 15:46 Public/
drwxr-x---+  2 mark domusers 4096 2015-10-16 15:46 Templates/
drwxr-x---+  2 mark domusers 4096 2015-10-16 15:46 Videos/

Select all Open in new window

Seems odd. Supposedly, NFSv4 supports ACLs: "The NFSv4 protocol includes integrated support for ACLs which are similar to those used by Windows." http://wiki.linux-nfs.org/wiki/index.php/ACLs

What could be the problem here?

I am uncertain why you are pursuing this, the autofs mount is solely for the individual user, this particular file/path is unavailable to a second user who logs in
i.e. arnold logs in autofs mount /redirectedFolders/Users/arnold
you log in
you autofs mounts your /redirectedFolders/Users/Mark
you can not see my redirectedFolders nor can I see yours.  The permissions extended on the server is what enforces what type of access each user has along with the autofs which defines which permissions the user has to avoid sending requests that are known to fail.


The autofs restricts the permissions, change your autofs to ro from rw and you'll only be able to read from the redirectedFolders.

See if you change to nfsver4
and use nfs4_getfacl/nfs4-setfacl
create an all user share and then mount it accessible by all there you should be able to see the enhanced ACL as some users will have rights to this all user share on the system and some will not ......

arnold:

I am uncertain why you are pursuing this, the autofs mount is solely for the individual user, this particular file/path is unavailable to a second user who logs in

In fact, I could care less about acls. But what I have is a dual-boot workstations WIN7 and Ubuntu. Booting either way, the workstation is part of a AD domain. Under Windows, the folders in question are part of the user's redirected folders and either the WIN7 workstation, or the AD/DC is setting these attributes. When booted Ubuntu, the same server folders are autofs-mounted and are also the Ubuntu user's desktop. My concern was to not lose the ACL settings when booted Ubuntu and the user modifies or creates files on this desktop ... but it's not a huge concern. At this point, my main motivation is academic - if nfs4 supports ACLs, why can I not see or set ACLs on these folders? I think I should be able to, so why not?

use nfs4_getfacl/nfs4-setfacl

Are these commands? I don't have them if so. Settings?

NFS supports NFS ACL's on NFS volumes. Since these files are on a Windows Share it will use Windows File Permissions

David Johnson:

NFS supports NFS ACL's on NFS volumes. Since these files are on a Windows Share it will use Windows File Permissions

Not sure I follow your reasoning. We're not talking a Windows Share per se. The volume having the ACL's is hosted on a Samba4 AD/DC and is the redirected folders directory for domain users. The Windows domain workstations set the ACLs. They are visible as such on the Samba4 AD/DC host, but not visible on the remote NFS client workstation. Seems to me that if NFS4 supports ACLs they should show regardless of which OS creates them.

On Samba4 server (local files)

> getfacl Desktop/putty.exe
# file: Desktop/putty.exe
# owner: mark
# group: domusers
user::rwx
user:mark:rwx
user:3000002:rwx
user:3000003:rwx
user:3000008:rwx
group::---
group:domusers:---
group:3000002:rwx
group:3000003:rwx
group:3000008:rwx
mask::rwx
other::---

Select all Open in new window

On NFS client using skullnobrains' utility:

root@labrat:~# nfs4_getfacl /home/HPRS/mark/Desktop/putty.exe
A::OWNER@:rwaxtTcCy
A::10001:rwaxtcy
A::3000002:rwaxtcy
A::3000003:rwaxtcy
A::3000008:rwaxtcy
A::GROUP@:tcy
A:g:10000:tcy
A:g:3000002:rwaxtcy
A:g:3000003:rwaxtcy
A:g:3000008:rwaxtcy
A::EVERYONE@:tcy

Select all Open in new window

On NFS client using standard getfacl:

root@labrat:~# getfacl /home/HPRS/mark/Desktop/putty.exe
getfacl: Removing leading '/' from absolute path names
# file: home/HPRS/mark/Desktop/putty.exe
# owner: mark
# group: domain\040users
user::rwx
group::rwx
other::---

Select all Open in new window

Should I just conclude that this doesn't work? Have any of you mounted a remote NFS volume, with ACL settings, and seen them on the NFS client?

Let me try and frame the question in he following manner, having set the ACL on the NFS server, does the access to the NFS share when mounted/accessed by user/users correspond to configured ACL on the server or not?

I.e. You define an NFS share with an ACL to allow groups A,b,c with read write ..
User1,user2 are members of their respective groups a,b.

The point being the NFS server will enforce the access rights in the final ....

arnold:

does the access to the NFS share when mounted/accessed by user/users correspond to configured ACL on the server or not?

Good question. These ACLs are set by the Win7 domain client which, as you can see, pretty much permit any user access. To test your comment I'd have to set up a file with my own custom ACLs -- which I'll confess I'm disinclined to do at the point.

skullnobrains' nfs4_getfacl utility showed basically the same user/group/permission as the getfacl run on the server, albeit with UIDs/GIDs instead of user/group names, and some additional permissions. I guess this means the ACLs are there. I suppose what I was hoping to see is the '+' indicator on the permissions block when doing an `ls -l`. Perhaps this is just a shortcoming in ls with respect to NFS mounted directories.

I think I'll consider this a non-issue and forget about it!

Any last comments?

I am unclear what we are discussing.
You have an NFS server on which you set NFS extended ACLs on shares.
You then mount the NFS share on a client system and when looking at the standard extended acl, the NFS extended ACL settings are not reflected unless you use the nfs4_getfacl.

In the case you are discussing, the NFS mount you are dealing with is a user home dir.
If you have two users logged into this system at the same time, each will have their own home dir mounted and I do not believe will have access to the other's.

meaning you have on the nfs server /export/home/users with NFS extended permissions to allow members of the domain\users group read/exec rights on this path with only the user have ownership rights to the $username folder within this path...


what ID does the user mark have? it looks like the extended acl merely reflects that mark with the group domusers having the has read/write/exec on the file.
which user and which group have the UID/GID of 3000002,3000003,3000008?

Any last comments?

actually several

- it might be worth a shot to use samba on the client machines as well

- nfs permissions are based on user ids. using nfs permissions is globally meaningless if you do not have a centralised user management so users have consistent ids across all hosts. the fact that ids are shown by the nfs utilities either indicates otherwise or reveals a bug in the utilities or possibly your nsswitch configuration. you can check with the "id" command.

- permissions are enforced by the server. the permissions you see in ls may be wrong for various reasons, but actually opening a file while not being allowed should not work

- nfs mounts can be performed as one user and apply to all/other users on the machine. it seems reasonable to think that you could be in that case. this would explain why ls/getfacl and the nfs tools disagree since the tools probably directly use the nfs protocol. additionally, nfs has options to transform users into other users.

hope some of the above helps

arnold:

I am unclear what we are discussing.
You have an NFS server on which you set NFS extended ACLs on shares.

Maybe semantics, but ... the server is the Active Directory / Domain Controller and yes, it is also an NFS server. These directories are users' home directories, but are not mounted NFS by the client Windows users. The volume is ext4 and has ACLs enabled. /etc/fstab/fstab:

/dev/md0        /                ext4        defaults,acl         1   1

They are "exported" as AD redirected folders via Samba4. /etc/samba/smb.conf:

[Users]
    path = /redirectedFolders/Users
    comment = user folders for redirection
    read only = No

I had to set up the initial folder ownership and permissions (http://www.alexwyn.com/computer-tips/folder-redirection-samba4-active-directory-domain-controller), but I assume the Windows 7 clients are the ones setting the ACLs.

You then mount the NFS share on a client system and when looking at the standard extended acl, the NFS extended ACL settings are not reflected unless you use the nfs4_getfacl.

Yes, but with the understanding that the clients mounting the share NFS are NOT the Windows 7 clients. These are Linux/Ubuntu clients, so they are mounting NFS, not Samba.

In the case you are discussing, the NFS mount you are dealing with is a user home dir.
If you have two users logged into this system at the same time, each will have their own home dir mounted and I do not believe will have access to the other's.

True, in that they "each will have their own home dir mounted", but the permissions are such that they could have rw access if they had physical access to the folder -- something I might fix some day.

meaning you have on the nfs server /export/home/users with NFS extended permissions to allow members of the domain\users group read/exec rights on this path with only the user have ownership rights to the $username folder within this path...

Well, with the qualification I stated above that the Windows 7 domain user are not accessing via NFS but rather via Samba. My server-side exports are:

/redirectedFolders/Users/mark   192.168.0.0/24(rw,no_root_squash,acl)
/redirectedFolders/Users/dsmith 192.168.0.0/24(rw,no_root_squash,acl)

skullnobrains:

it might be worth a shot to use samba on the client machines as well

Good thought, but the client Linux machines are aping the way the Windows AD works meaning, any user can log onto any workstations and get his/her desktop there. With Samba, I'd have to mount all shares for all users on the same workstation ... just in case someone logs in there some day. With autofs, it will NFS mount on-demand when the directory is requested, then unmount it after some configurable length of inactivity. That way, I only have the current user's home directory mounted.

nfs permissions are based on user ids. using nfs permissions is globally meaningless if you do not have a centralised user management so users have consistent ids across all hosts. the fact that ids are shown by the nfs utilities either indicates otherwise or reveals a bug in the utilities or possibly your nsswitch configuration. you can check with the "id" command.

The centralised user management is the Active Directory and yes, this gives consistent ids across all host. The domain user's ID is not even kept on the local workstation at all.

permissions are enforced by the server. the permissions you see in ls may be wrong for various reasons, but actually opening a file while not being allowed should not work

I've not really had an issue with opening a file when not allowed as the files all seem to have r/w permission for all users in the domusers group anyway.

nfs mounts can be performed as one user and apply to all/other users on the machine. it seems reasonable to think that you could be in that case. this would explain why ls/getfacl and the nfs tools disagree since the tools probably directly use the nfs protocol. additionally, nfs has options to transform users into other users.

I don't think I'm transforming users. My autofs config on the client is:

dsmith -fstype=nfs,acl,rw mail:/redirectedFolders/Users/dsmith
mark -fstype=nfs,acl,rw mail:/redirectedFolders/Users/mark

what ID does the user mark have? it looks like the extended acl merely reflects that mark with the group domusers having the has read/write/exec on the file.
which user and which group have the UID/GID of 3000002,3000003,3000008?

mark correctly has ID 10001. He originally had 3000002 when Samba4 was first provisioned and mark was first added. This was an error with the default settimg in Samba4. With the help of the samba gurus, I changed mark's UID to 10001, but that didn't really change the already set ACL setting. 300000[3,8] are other domain users -- not sure why they show up in the ACLs for those files.

The issue is that server extended ACL grants all domusers

I think I understand what it is you are trying to do, but your extended ACLS are acting as inended.

On the samba side, samba in "coordination" with windows only mounts the user's home from /redirected/folders/users/username which is the only thing accessible to the user.
Yes, based on your permission settings a user who navigates via UNC \\sambaaddc\redirected\folders\users\anyusername will have rights ..

Using the permissions structure in a share, administrators, domusers will rx rights to the users path with the indiivdual user folders created such that only the user and administrators, system have full rights.
Similarly with NFS
for NFS, the underlying filesystem permissions will be enforced without regard to the NFS ACL if any.
In samba, since the iDs are not mapped, it might also be true.
I.e. your account creation on the Samba4 server AD/DC
I think we were going back and forth trying to get the same point, but while I was discussing the configuration of the permissions on the server side, you were responding with the point of view from the client side.

The autofs using either samba as the reference or NFS (on a linux client, I would use NFS)
each login mounts only their own folder
samba4addc:/redirectedfolders/users/$username NFS or CIFS/SMB

unfortunately, ACl's are not inherited, and would usually not exist on newly created files by users.
i.e. of you while accessing the mark folder, smb or nfs, create a new file, I do not believe getfacl on the server will reflect the extended ACL.
not sure there is a similar mode for extended acls as exists for standard where one can set UID or GID and those are inherited but any newly created folder or file within that path.

With autofs, it will NFS mount on-demand when the directory is requested, then unmount it after some configurable length of inactivity

hmm... autofs does handle smb/cifs mounts
https://www.howtoforge.com/accessing_windows_or_samba_shares_using_autofs
but it probably won't solve anything given the extra information you provided

---

i'm confused regarding what actually is your problem, now : it seems that the acls work fine, are properly enforced, and can be seen with nfs4_getfacl, so the only thing that does not really work as expected is the missing "+" in ls output.

any actual other problem left ?

skullnobrains:

i'm confused regarding what actually is your problem, now : it seems that the acls work fine, are properly enforced, and can be seen with nfs4_getfacl, so the only thing that does not really work as expected is the missing "+" in ls output.

The missing "+" was an indicator to me that ACL's weren't really working as seen from the client Ubuntu workstation.

any actual other problem left ?

I would have to make modifications to the ACL permission on the server to set up a definitive test. As this really doesn't seem all that critical at this point, I am disinclined to make the effort. Therefore, I'm going to consider there are no actual problems.

I'm dropping pursuing this. I don't find ACLs very useful on Linux -- "standard" permissions work well enough. The Windows workstations can successfully set these ACL on the Linux hosted drives, so Windows can use those ad nauseam. If I need to revisit this, I'll check out skullnobrains' suggested package. Thanks for the lively discussion.