11.3 SMB share permissions not behaving as expected

RiBeneke

Dabbler
Joined
Nov 18, 2013
Messages
37
We had an unsuccessful upgrade from 11.2-U6 to U7 last month. Most users lost access to their shares.
We were unable to establish if it was caused by FreeNAS or the many Windows updates. Maybe also SMB2/3 and NTLM2 did something.
We suspected that our ACLs were confused, and found user and group database corruptions too.

A few days ago we were pleased to discover the release of FreeNAS 11.3 stable, so did a fresh install from the ISO, chose not to keep old configs.
Did the basic configuration of FreeNAS. Imported our old datasets into the pool, set up new users and groups.

We have Win7Pro and Win10 pc's and Win7SE notebooks. Peer to peer network through a managed switch.
DHCP and local DNS and firewall and routing provided by a Routerboard OS.

We set up new users and groups and Windows shares at the root of the ZFS pool.
The FreeNAS GUI ACL manager was used to give full permissions to the builtin root and wheel on each share.
The 'Apply Permissions Recursively' 'Apply to Child Datasets' and 'Strip ACLs' options were set this time for each.
The ACL manager needed to reorder some old ACLs, and we gave consent.
Then we added ACLs to give our All-Users group 'Traverse' access to each share and only 'Apply Permissions Recursively'.
We aslo added ACLs to give certain groups 'Full Control' access to specific shares, again 'Apply Permissions Recursively'.

Unexpected behaviour 1 : the permissions for 'Traverse' and 'Full Control' do not seem to be effective for our users.
Users can see the shares as icons in Windows explorer, but are denied permission to open them.
We have tried with and without 'Access based Enumeration' on the share, behaviour seems similar.

Unexpected behaviour 2 : if a user is placed into the wheel group, and FreeNAS is rebooted or given time to think (a few hours)
and their pc is logged off/on or rebooted then that user on that pc has immediate full access to the permitted share.
If the user is then removed from the wheel group on FreeNAS (save the setting),
that user can still continue to have full access to the share, even for days, until a logoff or reboot.
So a user may continue to have full access to a share on one pc, and at the same time have no access from another pc.
Rebooting FreeNAS server will also kick the user off when they are no longer in wheel group.

Any suggestions about where to look for the cause will be welcome. I dont understand tokens and handshakes and permissions.
I feel like a driver who has never looked under the tappet cover of their car's engine and doesnt know crankshaft from camshaft.
 
Last edited:

RiBeneke

Dabbler
Joined
Nov 18, 2013
Messages
37
We seem to have fixed our problem. Yay !

The cause was the lack of an ACL using the everyone@ group.
We did create our own allusers group with recursive traverse permissions, but it was not sufficient.
So after creating an ACL for everyone@ with recursive read permissions in each shared folder, the problem was fixed.
The strange timing issues probably arose from differences in the way Unix and Windows permissions are transferred over the network.

This solution is probably very obvious to people who understand the way Unix/FreeBSD, Samba, FreeNAS and Windows work together,
but to someone like myself it took a very long time to get there.

@anodos and @writer of the user manual, please make clear the following points in the FreeNAS User Manual under Windows Shares
(correct my terminology as necessary) :

Permission and access is based on the most restrictive of either Unix permissions and Windows ACL permissions.
Unix permissions can be set using Unix commands before shares are set up, but Samba will overwrite these when using the FreeNAS ACL tool.
Set permissions on the Windows Shares (SMB) using the FreeNAS Edit ACL tool.
Under File Information, the User will normally be <root> and the Group will normally be <wheel>.
Then create an ACL (if not automatically created) where owner@ (which maps to Unix <root>) has recursive Full Control permission.
Create an ACL where group@ (which maps to Unix <wheel>) has recursive Full Control permission.
Create an ACL where everyone@ (which maps to Unix <everyone>) has recursive Read permission.
This will allow Samba to create the necessary Unix permissions (775 or rwxrwxr-x), as well as the matching Windows ACL permissions on the Share.

After some Windows Users and Groups have been created in FreeNAS, (normally placing Users into Groups),
create further ACLs as required for fine control of which Groups have access to Windows Shares (SMB).

Hope this helps.
 

anodos

Sambassador
iXsystems
Joined
Mar 6, 2014
Messages
9,543
We seem to have fixed our problem. Yay !

The cause was the lack of an ACL using the everyone@ group.
We did create our own allusers group with recursive traverse permissions, but it was not sufficient.
So after creating an ACL for everyone@ with recursive read permissions in each shared folder, the problem was fixed.
The strange timing issues probably arose from differences in the way Unix and Windows permissions are transferred over the network.

This solution is probably very obvious to people who understand the way Unix/FreeBSD, Samba, FreeNAS and Windows work together,
but to someone like myself it took a very long time to get there.

@anodos and @writer of the user manual, please make clear the following points in the FreeNAS User Manual under Windows Shares
(correct my terminology as necessary) :

Permission and access is based on the most restrictive of either Unix permissions and Windows ACL permissions.
Unix permissions can be set using Unix commands before shares are set up, but Samba will overwrite these when using the FreeNAS ACL tool.
Set permissions on the Windows Shares (SMB) using the FreeNAS Edit ACL tool.
Under File Information, the User will normally be <root> and the Group will normally be <wheel>.
Then create an ACL (if not automatically created) where owner@ (which maps to Unix <root>) has recursive Full Control permission.
Create an ACL where group@ (which maps to Unix <wheel>) has recursive Full Control permission.
Create an ACL where everyone@ (which maps to Unix <everyone>) has recursive Read permission.
This will allow Samba to create the necessary Unix permissions (775 or rwxrwxr-x), as well as the matching Windows ACL permissions on the Share.

After some Windows Users and Groups have been created in FreeNAS, (normally placing Users into Groups),
create further ACLs as required for fine control of which Groups have access to Windows Shares (SMB).

Hope this helps.
The POSIX mode is always computed from the underlying ZFS ACL. The FreeBSD subroutine `acl_is_trivial_np()` is used to determine whether the ZFS ACL can be expressed as a POSIX mode without loss of information. If it can't, then "ls -l" output in the shell puts a `+` sign next to the entry with a "complex" ACL. There is a corresponding FreeNAS middleware call 'filesystem.acl_is_trivial' that calls the same subroutine. The output of this subroutine is used to determine whether the path has "complex ACLs" and locks the user out of the POSIX mode editor and redirects to the ACL editor in the FreeNAS GUI. You are no longer allowed to manipulate and view the POSIX mode because the calculated POSIX mode is no longer a correct guide to the actual permissions on the file.

Samba does not "overwrite" your POSIX mode in a dirty pejorative sense. The SMB clients request changes to filesystem permissions and the server honors these requests (assuming that they have permissions to do this). The requested Windows Security Descriptor is mapped to a corresponding ZFS ACL and applied to the file in question. It is not mapped to an explicit POSIX mode because once again this is a sort of shorthand for a specific (and in this case wrong) ACL.
 

RiBeneke

Dabbler
Joined
Nov 18, 2013
Messages
37
Thank you anodos for the response. I sort of understand.
The complexities here where different systems meet are clearly significant, and I think they are beyond the ability of the average user to comprehend.
It would help if the user manual had some sort of dummies guide here.
I could not find little information on the forum or elsewhere that helped me. Unless I studied hundreds of pages to be an expert like you guys.
Thats why I have now tried to make a simplified step by step list, but I realise my terminology is not right.
 

RiBeneke

Dabbler
Joined
Nov 18, 2013
Messages
37
It seems that things were not behaving as expected because our system was confused.
Trying to fix what was happening was a waste of effort and time.
The basic reinstall of FreeNAS was not good enough, and too much thinking and tinkering did not help.
The virus shutdown in South Africa has given me time (in our home-based office) to approach the problem without
having to get FreeNAS running by next day for our staff to work.

So I backed up all files to another device, reformatted system flash USB drive,
did a complete reinstall of FreeNAS to the flash drive, wiped the syslog and data pools,
and did all settings from basics, to get rid of legacy configurations hiding in the system.

The default ACL's on the shares now look slightly different to what we had.
And the system now behaves as expected.
 

AltecBX

Patron
Joined
Nov 3, 2014
Messages
285
I'm having the same issues. I have everyone, Owner, Group, User full permission and I still can't access files.
 
Top