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.
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: