Register for the iXsystems Community to get an ad-free experience and exclusive discounts in our eBay Store.

Windows clients can't alter data on SMB share

01dkrk10

Neophyte
Joined
Mar 21, 2019
Messages
4
Hi,
I'm currently migrating a non-Freenas system to FreeNAS-11.2-RELEASE-U1.
After i set up the SMB shares (+ ACL permissions) and moved the data, Windows clients can't alter these files.
But they are able to remove/paste the files. On linux everything works fine.
After some tracing I found out that files owned only by root are causing troubles for Windows systems.

My setup:
I set up the user and groups according to my permission plan.
I initialized a ZFS pool with a couple datasets, where the share type is set to Windows. The owner of the dataset is root, the group is the main group using the dataset.
As an example, the dataset "Kernteam" is owned by root und as group "Kernteam" is used.
To deny access for everybody and preventing "Kernteam" members doing messy things, i set these permissions:
setfacl -m group@:rwxpDdaRcs:fd:allow,everyone@:::allow /mnt/MAINSTOREHDD/Kernteam

getfacl gives me following output:

Code:
getfacl /mnt/MAINSTOREHDD/Kernteam
# file: /mnt/MAINSTOREHDD/Kernteam
# owner: root
# group: Kernteam
            owner@:rwxpDdaARWcCos:fd-----:allow
            group@:rwxpDda-R-c--s:fd-----:allow
         everyone@:--------------:-------:allow


Following output is returned for this share by testparm:

Code:
[Kernteam]
    path = "/mnt/MAINSTOREHDD/Kernteam"
    read only = No
    veto files = /.snapshot/.windows/.mac/.zfs/
    vfs objects = zfs_space zfsacl streams_xattr
    zfsacl:acesort = dontcare
    nfs4:chown = true
    nfs4:acedup = merge
    nfs4:mode = special


Following output is returned by smbcacls:
Code:
REVISION:1
CONTROL:SR|DP
OWNER:ALTIS\root
GROUP:ALTIS\Kernteam
ACL:ALTIS\root:ALLOWED/OI|CI/FULL
ACL:ALTIS\Kernteam:ALLOWED/OI|CI/0x001300ef
ACL:Everyone:ALLOWED/0x0/0x00100000


The data itself was copied by the root of the Freenas machine using smbmount from the old NAS system.
Have someone any ideas, why this is happening?
 

Basil Hendroff

Neophyte Sage
Joined
Jan 4, 2014
Messages
1,079

01dkrk10

Neophyte
Joined
Mar 21, 2019
Messages
4
Thanks for the reply.
I used the first link to create the basic share, before i started modifing the ACL permissions. The only difference is that used root instead of "nobody".
I also read the second link while setting the permission, but not as much, as i should. I can try adding a privileged account and setting the SMB permissions via Windows Explorer. This may take a while. I will let you know, when i have something new.
 

01dkrk10

Neophyte
Joined
Mar 21, 2019
Messages
4
Its a while now, but i managed to solve the initial problem. I missunderstood the meaning of the "write Attrib" and "Write xattr" permission. Windows clients can now edit the files. In the process i realized, that the permission "change owner" have no effect on my files.
The details:
I upgraded my NAS to 11.2 U4.1 and altered also the permissions.
As an example here is the output of the share "Auftrag":

Code:
# file: /mnt/MAINSTOREHDD/Auftrag
# owner: root
# group: Kernteam
            group@:rwxpDdaARWc--s:fd-----:allow

Users in group Kernteam should be able to upload and edit data. However they should not be able to change the ownership and permissions of the specific files.
An example: UserA creates a File, UserB should not be able to change the ownership. The case, if UserA is able to modify the owner is out of context.
In my personal opinion the ACL is correctly set up.

I created the file "testfile.txt":
Code:
# file: /mnt/MAINSTOREHDD/Auftrag/testfile.txt
# owner: UserA
# group: Kernteam
            group@:rwxpDdaARWc--s:------I:allow

Then i accessed the file from UserB, which is also in the group Kernteam and change the Owner on settings -> security -> extends ->owner.
I dont get an error and the change was successful.
Code:
# file: /mnt/MAINSTOREHDD/Auftrag/testfile.txt
# owner: UserB
# group: Kernteam
            group@:rwxpDdaARWc--s:------I:allow

I tested this behaviour on a virtual machine and the permission works in this context.

I compared the config files from the NAS and the virtual machine and they appears to be same
 

anodos

Sambassador
iXsystems
Joined
Mar 6, 2014
Messages
6,422
Its a while now, but i managed to solve the initial problem. I missunderstood the meaning of the "write Attrib" and "Write xattr" permission. Windows clients can now edit the files. In the process i realized, that the permission "change owner" have no effect on my files.
The details:
I upgraded my NAS to 11.2 U4.1 and altered also the permissions.
As an example here is the output of the share "Auftrag":

Code:
# file: /mnt/MAINSTOREHDD/Auftrag
# owner: root
# group: Kernteam
            group@:rwxpDdaARWc--s:fd-----:allow

Users in group Kernteam should be able to upload and edit data. However they should not be able to change the ownership and permissions of the specific files.
An example: UserA creates a File, UserB should not be able to change the ownership. The case, if UserA is able to modify the owner is out of context.
In my personal opinion the ACL is correctly set up.

I created the file "testfile.txt":
Code:
# file: /mnt/MAINSTOREHDD/Auftrag/testfile.txt
# owner: UserA
# group: Kernteam
            group@:rwxpDdaARWc--s:------I:allow

Then i accessed the file from UserB, which is also in the group Kernteam and change the Owner on settings -> security -> extends ->owner.
I don't get an error and the change was successful.
Code:
# file: /mnt/MAINSTOREHDD/Auftrag/testfile.txt
# owner: UserB
# group: Kernteam
            group@:rwxpDdaARWc--s:------I:allow

I tested this behaviour on a virtual machine and the permission works in this context.

I compared the config files from the NAS and the virtual machine and they appears to be same
The owner of a file is super-user as to that file. This is the behavior in Windows and Unix. If you want to restrict that behavior in samba, you _must_ set an additional OWNER_RIGHTS (S-1-3-4) ACE that defines the maximum access allowed for the owner of a file. See this for more information: https://support.microsoft.com/en-us...rity-identifiers-in-windows-operating-systems

<edit>I misread the quoted text. I am reviewing now.</edit>
 
Last edited:

anodos

Sambassador
iXsystems
Joined
Mar 6, 2014
Messages
6,422
@01dkrk10
I have attached a patched generate_smb4_conf.py script to this post. On your test system, service samba_server stop replace /usr/local/libexec/nas/generate_smb4_conf.py, rm /var/db/samba4/account_policy.tdb, rm /var/db/samba4/.usersimported, python /usr/local/libexec/nas/generate_smb4_conf.py, then service samba_server start, and repeat the test.
 

Attachments

01dkrk10

Neophyte
Joined
Mar 21, 2019
Messages
4
@01dkrk10
I have attached a patched generate_smb4_conf.py script to this post. On your test system, service samba_server stop replace /usr/local/libexec/nas/generate_smb4_conf.py, rm /var/db/samba4/account_policy.tdb, rm /var/db/samba4/.usersimported, python /usr/local/libexec/nas/generate_smb4_conf.py, then service samba_server start, and repeat the test.
Thank you for your help. I applied the patch and it seems that the ownership permission is working now, i would test this til im sure.
 
Top