# NFSv4 ACL question



## carstenw (May 12, 2014)

Hello!

As you can guess from my post count, I am quite a noob to this. However I have to complain... or maybe ask?!

I despair of NFSv4 ACLs. The following is for an application workflow for Lightroom and the file types in question are .raw, .jpg and .xmp (you see: I have a Windows history )

Say you would like users to be able to add directories and files (jpg and raw). Later ownership and permissions should be changed and the added directories and files should be read only for all users, including the one who added them. This is because there is no need and there should be no possibility to accidentally change or delete the original pictures. However all users should further be able to add and change xmp files in the directory and Lightroom will save these xmp "sidecar" files in the same directory as the originals.

I can't get this to work. To add and change files I need "write" permission on the directory, but this will let me delete any object (file or sub-directory) in the directory, regardless of the object's ACL. Omitting "write" permission on the directory will prevent the users from creating xmp files. Only subdirectories can be created by giving the "p" permission.

IMHO this is a serious flaw (if it is like this) in the design and working of ACLs, for there seems no way to implement, what I want. In other words: ACLs which are closer to the object in question should be honored, except when there is an explicit override defined at a higher level. Anything else is quite not understandable.

This is an environment with FreeBSD, ZFS and NFSv4 ACLs (ZFS passthrough).

But maybe, there is a constellation, which I haven't tried yet. Please help (or second me)!

Kind regards!


----------



## trasz@ (Nov 24, 2014)

You can use delete_child::deny on the directory.  This is a bit of a special case: if there is a "deny" rule for delete_child, the user is prevented from removing files in that directory, even though they have write permission.


----------

