[OmniOS-discuss] nfsv4 acls wtf moment

Natxo Asenjo natxo.asenjo at gmail.com
Fri May 10 08:22:38 EDT 2013


hi,

maybe (probably) not really on topic for the omnios list.

I have a zfs dataset shared both for cifs as for nfs. On the data set I use
this:

# zfs get aclinherit tank/testshare
NAME            PROPERTY    VALUE          SOURCE
tank/testshare  aclinherit  passthrough    local

Next I applied this acl to the /tank/testshare filesystem:

# /bin/ls -vd /tank/testshare/
drwxrwxrwx+ 12 root     root          13 May 10 13:16 /tank/testshare/
     0:everyone@:list_directory/read_data/add_file/write_data
         /add_subdirectory/append_data/read_xattr/write_xattr/execute
         /delete_child/read_attributes/write_attributes/delete/read_acl
         /write_acl/write_owner/synchronize:file_inherit/dir_inherit:allow

So basically anyone may do whatever they want to the content of the dataset.

Windows clients respect the acl, I can copy files and dirs from other
disks/shares and the acl on the dataset is respected.

Now, linux nfs4 clients respect the acl when creating files or dirs but
when copying files/dirs they ignore the acl inheritance and use the umask
setting, so I wind up with unusable files for the windows clients.

This issue was discussed in some length in the zfs-discuss list (
http://www.mentby.com/Group/zfs-discuss/who-is-using-zfs-acls-in-production.html).
Unfortunately, no solution appears on the thread.

Is this a linux client problem that should be fixed on the linux client
side? Are there any settings per dataset to make the server ignore the
umask request of the client to enforce the dataset acl like the cifs
implemention does?

TIA,
--
Groeten,
natxo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://omniosce.org/ml-archive/attachments/20130510/5b6de056/attachment.html>


More information about the OmniOS-discuss mailing list