[OmniOS-discuss] nfsv4 acls wtf moment

[Sigbjorn Lie]

Hi,

Did you set aclmode to passthrough too?



Regards,
Siggi


On 05/10/2013 02:22 PM, Natxo Asenjo wrote:
> 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
>
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://omniosce.org/ml-archive/attachments/20130510/2d304665/attachment.html>