Issue with CIFS permissions after Upgrade to FreeNAS 11

[Gilley7997]

I first noticed this immediately after upgrade.

I had an rsync task configured to back up the shares to an old synology system that had been working fine, all of a sudden the rsync account no longer has read permissions to 2 of the 4 shares.

Also, I am now unable to save any permissions changes to any of my shares from a Windows 10 client. Although it does seem that I am able to access all of my previous shares from windows.

This is the error I receive on every attempt to change permissions from windows on any of the shares:

I also noticed that all my shares seem to have this setting now as well on all the previous accounts: They all say special permissions.

Any thoughts on how to correct this, would like to be able to get this back to normal.

Thanks

 

[Gilley7997]

Okay folks, I think I found a solution, but it seems a little strange to me, that this just occurred because of the upgrade.

First, I started with the Data Set itself and basically reapplied the same permissions recursively. This appeared to resolve my rsync issue and my rsync linux account could now properly access the other 2 shares that had limited access by group. The rsync task also then registered a permission change on every directory in the root in that data set and supposedly synced that permission change to the synology, although as far as I could tell nothing was really changed.

After this I was still experiencing the windows issue where I couldn't change the permissions. I then deleted the SMB share and recreated it. I now have the ability to add and delete users/groups whichever and also alter the permissions, and it's not highlighting the special permissions button anymore. It is the normal read and write options.

After recreating the SMB Share, it had added the default Everyone group to the rules. This particular share is limited to just me, so I removed the everyone group. This then promptly brought back the rsync error. I then specifically went back and added the Rsync user to the windows share from Windows with Read and List folder contents. This then allowed rsync to sync again, and it registered a permissions change on every directory during the rsync. The confusing part of this to me is that the rsync user is part a part of my group so this shouldn't have been needed to be done.

As of right now I have this specific share in the state it needs to be in...but...

So my question is why did this occur during the upgrade, and before I do this to the rest of my shares, does this sound like a sound process to recover the ability to alter permissions and such on the shares, and although I'm not currently having permission issues on the other 2 shares as far as the Rsync goes would it be wise to reset all the permissions in those data sets as well?

Also why is my rsync user enabled when I add it to the windows folder directly, but if I assign the Unix group to that user and give the same permissions to that group it does not function.

Any thoughts, or has anyone run into this before.

Thanks

 

[Gilley7997]

Okay so further details upon digging more after some sleep. This does not make any sense to me:
With this configuration in both Windows and FreeNAS the rsync task functions:

The group in windows has the group and owner with Full Access, and the Everyone Group configured as such:

With this configuration the rsync task will complete with no problem, also adding the specific rsync user instead of the Everyone group, will also allow the rsync task to complete with no problem.

But....If we remove the Everyone group leaving this:

And from the FreeNAS Side:

Also verifying that the rsync user is definitively part of the group Gilley7997:

Running the rsync task results in this:

Does anyone see a flaw in this permission set-up as to why this would be occuring?

Thanks.

 

[Gilley7997]

Was the VFS objects zfsacl available prior to Version 11? Could the change from whatever it was prior to this be the problem?

 

[Gilley7997]

Anyone help me confirm that this is the proper way to restore the permissions to all the existing shares to make them modifiable in Windows again, even though that doesn't appear to help with the rsync issue not getting the correct permissions from the group assignement.

 

[anodos]

Anyone help me confirm that this is the proper way to restore the permissions to all the existing shares to make them modifiable in Windows again, even though that doesn't appear to help with the rsync issue not getting the correct permissions from the group assignement.

The easiest way to reset permissions is to toggle the "apply default permissions" checkbox in your SMB share config. Uncheck, hit OK and close, open share config again, check the checkbox, then hit OK again.

The "special permissions" indicates to me that perhaps you've configured the share with "unix" permissions type. Make sure that the datasets underlying your SMB shares have "windows" permissions type.

Once you have done that and reset permissions, add an explicit entry through File Explorer for the group that your rsync user is a member of (i.e. don't rely on owner-group of the share). Once you have done this, on future rsync tasks, specify --no-p (i.e. don't rsync permissions). This will prevent your rsync task from nuking the permissions on your share (or throwing errors because it can't chmod).