[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