Can't edit file because UNIX and Windows permissions are different

[chris.shelton]

When I create a new file to a public share, others can read it, but cannot write to it through Windows Explorer.

The file has rw permissions for both owner and group, and other people are part of the group.

However, when I do a right-click on the file in Windows and check the permissions, it says that the owner has rw access, but group has just r access, not write.

How can I make it inherit the UNIX permissions?

Thanks

 

[anodos]

See permissions guide here: https://forums.freenas.org/index.ph...-of-how-to-configure-share-permissions.35276/

 

[chris.shelton]

See permissions guide here: https://forums.freenas.org/index.ph...-of-how-to-configure-share-permissions.35276/

Thanks, but, what if I want my dataset to be UNIX and not windows because I have a mixture of client types?

 

[anodos]

Thanks, but, what if I want my dataset to be UNIX and not windows because I have a mixture of client types?

Mixture of client types should be irrelevant. ZFS acls make the samba server's permissions behave (for all practical purposes) like a Windows server. If a samba client can interact properly with a Windows server, it can interact properly with a freenas server with "Windows permissions".

Some edge cases where someone might want Unix permissions:

1) no available Windows clients go configure ACLs

2) using other file sharing protocols to access share.

3) using fancy-pants scripts that don't understand ACLs on your datasets.

 

[anodos]

If you insist on using Unix permissions, you should
(1) use getfacl to verify that you haven't inadvertently set ACLs on the share.
(2) recursively set permissions on dataset from GUI
(3) "chmod g+s" the dataset you're sharing.

 

[chris.shelton]

Mixture of client types should be irrelevant. ZFS acls make the samba server's permissions behave (for all practical purposes) like a Windows server. If a samba client can interact properly with a Windows server, it can interact properly with a freenas server with "Windows permissions".

Some edge cases where someone might want Unix permissions:

1) no available Windows clients go configure ACLs

2) using other file sharing protocols to access share.

3) using fancy-pants scripts that don't understand ACLs on your datasets.

Thanks for your help with this. If I went for Windows permissions, how do I go about running any chown commands on files etc? It currently says that I can't do it as root, but I could when I used UNIX permissions. It's a requirement to be able to change owner/group of a file.

Thank you

 

[anodos]

Thanks for your help with this. If I went for Windows permissions, how do I go about running any chown commands on files etc? It currently says that I can't do it as root, but I could when I used UNIX permissions. It's a requirement to be able to change owner/group of a file.

Thank you

Chown should work on Windows datasets. Chmod doesn't because the ZFS aclmode property is set to restricted. That being said, running chown on a samba share manually from the CLI sounds like a work-flow / config problem.

 

[rogerh]

Chown should work on Windows datasets. Chmod doesn't because the ZFS aclmode property is set to restricted. That being said, running chown on a samba share manually from the CLI sounds like a work-flow / config problem.

(The Windows equivalent of) both could presumably be done from a Windows client with suitable privileges.

 

[chris.shelton]

Chown should work on Windows datasets. Chmod doesn't because the ZFS aclmode property is set to restricted. That being said, running chown on a samba share manually from the CLI sounds like a work-flow / config problem.

Sorry yes, it's chmod that wasn't working. I understand now. I am looking at making the transition to Windows ACLs, but one scenario is worrying me.

I have a share 'scanner' pointing to a 'scanner' directory. The owner of the share is scanner and the group is staff. I don't like the fact that it is the scanner who is responsible for managing permissions and could potentislly lock themselves out by editing permissions they shouldn't. Ideally I would like on admin people to be able to this kind of stuff.

 

[SweetAndLow]

I don't think the owner of a file can ever lock themselves out of a file. Owners can always modify permissions and get rwx back if they need.

 

[anodos]

Sorry yes, it's chmod that wasn't working. I understand now. I am looking at making the transition to Windows ACLs, but one scenario is worrying me.

I have a share 'scanner' pointing to a 'scanner' directory. The owner of the share is scanner and the group is staff. I don't like the fact that it is the scanner who is responsible for managing permissions and could potentislly lock themselves out by editing permissions they shouldn't. Ideally I would like on admin people to be able to this kind of stuff.

Change owner of dataset to your admin user and add an ACE for "scanner" granting write / modify privileges to the dataset.

 

[chris.shelton]

If you insist on using Unix permissions, you should
(1) use getfacl to verify that you haven't inadvertently set ACLs on the share.
(2) recursively set permissions on dataset from GUI
(3) "chmod g+s" the dataset you're sharing.

This is what I get from getfacl on the dataset.

[root@freenas] /mnt/pool# getfacl dataset/
# file: dataset/
# owner: super
# group: staff
owner@:rwxp--aARWcCos:------:allow
group@:rwxp--a-R-c--s:------:allow
everyone@:------a-R-c--s:------:allow

 

[anodos]

See bug report here: https://bugs.freenas.org/issues/11390

 

[chris.shelton]

See bug report here: https://bugs.freenas.org/issues/11390

Thanks for this. Although it's not what I was hoping for, at least it's an answer to my questions.

 

[SweetAndLow]

Thanks for this. Although it's not what I was hoping for, at least it's an answer to my questions.

I agrees, this wasn't the behavior I was expecting either. All other enterprise nas solutions allow for permission mapping both ways.