11.2 U2 changes how SMB+Unix share permissions work

[KrisBee]

Yes, we changed what was allowed via the UI so that users can change Windows -> Unix permissions type. This performs a chmod (possibly with a -R) on the dataset in question. The resulting permissions are what you would expect with this combination of actions. In general, it's not a great idea to do this, but we allow it. If you need to strip the extended ACL, you can perform a find /mnt/NasPool/winshare | setfacl -b. We can't perform this action by default because it is significantly more destructive than a recursive chmod. Big picture: we need a graphical ACL editor in the GUI.

@anodos Forgetting smb shares for the moment and concentrating just on dataset permissions, this is the comparison between FN11.1-7U and latest FN11.2-U2 for the simple sequence of changing the dataset share type from unix to windows and then back to unix again. There was never a need to use setfactl -b before to remove the extended ACL.

Should this behaviour have changed? It is a separate issue, or is it related to the regression you have mentioned?

FN11.1-7U

Code:

[chris@freenas /mnt/NasPool]$ getfacl winshare

# file: winshare
# owner: chris
# group: chris
            owner@:rwxp--aARWcCos:-------:allow
            group@:r-x---a-R-c--s:-------:allow
         everyone@:r-x---a-R-c--s:-------:allow
[chris@freenas /mnt/NasPool]$
[chris@freenas /mnt/NasPool]$ getfacl
^C
[chris@freenas /mnt/NasPool]$ getfac winshare
-bash: getfac: command not found
[chris@freenas /mnt/NasPool]$ getfacl winshare
# file: winshare
# owner: chris
# group: chris
            owner@:rwxpDdaARWcCos:fd-----:allow
            group@:rwxpDdaARWcCos:fd-----:allow
         everyone@:r-x---a-R-c---:fd-----:allow
[chris@freenas /mnt/NasPool]$ getfacl winshare
# file: winshare
# owner: chris
# group: chris
            owner@:rwxp--aARWcCos:-------:allow
            group@:r-x---a-R-c--s:-------:allow
         everyone@:r-x---a-R-c--s:-------:allow
[chris@freenas /mnt/NasPool]$

FN11.2-U2

Code:

[chris@freenas /mnt/NasPool]$ getfacl winshare

# file: winshare
# owner: chris
# group: chris
            owner@:rwxp--aARWcCos:-------:allow
            group@:r-x---a-R-c--s:-------:allow
         everyone@:r-x---a-R-c--s:-------:allow
[chris@freenas /mnt/NasPool]$ getfacl winshare
# file: winshare
# owner: chris
# group: chris
            owner@:rwxpDdaARWcCos:fd-----:allow
            group@:rwxpDdaARWcCos:fd-----:allow
         everyone@:r-x---a-R-c---:fd-----:allow
[chris@freenas /mnt/NasPool]$ getfacl winshare
# file: winshare
# owner: chris
# group: chris
            owner@:rwxpDdaARWcCos:fd-----:allow
            group@:rwxpDdaARWcCos:fd-----:allow
         everyone@:r-x---a-R-c---:fd-----:allow
[chris@freenas /mnt/NasPool]$

 

[anodos]

@anodos Forgetting smb shares for the moment and concentrating just on dataset permissions, this is the comparison between FN11.1-7U and latest FN11.2-U2 for the simple sequence of changing the dataset share type from unix to windows and then back to unix again. There was never a need to use setfactl -b before to remove the extended ACL.

Should this behaviour have changed? It is a separate issue, or is it related to the regression you have mentioned?

FN11.1-7U

Code:

[chris@freenas /mnt/NasPool]$ getfacl winshare

# file: winshare
# owner: chris
# group: chris
            owner@:rwxp--aARWcCos:-------:allow
            group@:r-x---a-R-c--s:-------:allow
         everyone@:r-x---a-R-c--s:-------:allow
[chris@freenas /mnt/NasPool]$
[chris@freenas /mnt/NasPool]$ getfacl
^C
[chris@freenas /mnt/NasPool]$ getfac winshare
-bash: getfac: command not found
[chris@freenas /mnt/NasPool]$ getfacl winshare
# file: winshare
# owner: chris
# group: chris
            owner@:rwxpDdaARWcCos:fd-----:allow
            group@:rwxpDdaARWcCos:fd-----:allow
         everyone@:r-x---a-R-c---:fd-----:allow
[chris@freenas /mnt/NasPool]$ getfacl winshare
# file: winshare
# owner: chris
# group: chris
            owner@:rwxp--aARWcCos:-------:allow
            group@:r-x---a-R-c--s:-------:allow
         everyone@:r-x---a-R-c--s:-------:allow
[chris@freenas /mnt/NasPool]$

FN11.2-U2

Code:

[chris@freenas /mnt/NasPool]$ getfacl winshare

# file: winshare
# owner: chris
# group: chris
            owner@:rwxp--aARWcCos:-------:allow
            group@:r-x---a-R-c--s:-------:allow
         everyone@:r-x---a-R-c--s:-------:allow
[chris@freenas /mnt/NasPool]$ getfacl winshare
# file: winshare
# owner: chris
# group: chris
            owner@:rwxpDdaARWcCos:fd-----:allow
            group@:rwxpDdaARWcCos:fd-----:allow
         everyone@:r-x---a-R-c---:fd-----:allow
[chris@freenas /mnt/NasPool]$ getfacl winshare
# file: winshare
# owner: chris
# group: chris
            owner@:rwxpDdaARWcCos:fd-----:allow
            group@:rwxpDdaARWcCos:fd-----:allow
         everyone@:r-x---a-R-c---:fd-----:allow
[chris@freenas /mnt/NasPool]$

This indeed looks to be something different than the regression I mentioned. I'll take a look at it once I finish my work on the first one.

 

[indivision]

Have the same problem.

To clarify, is this going to be addressed in an update coming up soon? Or, should I roll back to wait?

 

[anodos]

Have the same problem.

To clarify, is this going to be addressed in an update coming up soon? Or, should I roll back to wait?

I just merged the fix. I think there will be a quick turnaround fix for this and the issue with jail networking. You can use the "ixnas" workaround or roll back.

 

[indivision]

Thank you. Sounds good. I think I will just wait. I am always a little uneasy rolling back after significant updates (maybe I shouldn't be but... old scars.)

 

[Lothian]

I had the same problem. I tested on one of my shares that is not critical and checked the "Default Permissions" checkbox in the advanced settings tab. I am now able to delete and modify files again on that share. One thing though, I am surprised that the checkbox does not seem to stick. When I go back in again, I find that it is unchecked. One other question. I may be missing something obvious but if I want to use the ixnas fix, where would I make the change?

Thanks

 

[anodos]

I had the same problem. I tested on one of my shares that is not critical and checked the "Default Permissions" checkbox in the advanced settings tab. I am now able to delete and modify files again on that share. One thing though, I am surprised that the checkbox does not seem to stick. When I go back in again, I find that it is unchecked. One other question. I may be missing something obvious but if I want to use the ixnas fix, where would I make the change?

Thanks

It's a VFS object in the SMB share configuration.

 

[Koen_Oostende]

Why is
Only Allow Guest Access
shown twice

 

[anodos]

Why is
Only Allow Guest Access
shown twice

Someone must have made made a mistake.

 

[sctracey]

I have the same problem and also noticed the duplicate Guest Access entry.

 

[LarryG]

Why is
Only Allow Guest Access
shown twice

If you log in to FreeNAS using the legacy interface and look at the SMB Windows share options you will notice two (2) related to quest accounts.
They are 'Allow Guest Access" and "Only Allow Guest Access". Apparently, when creating the new interface, they mistakenly use the same text entry to describe these two different options.

 

[Koen_Oostende]

Thanks LarryG for explaining. Anodos' answer wasn't that clear.
Someone must have made a mistake. That someone could've been me. ;-)
I fixed my smb issue following anodos post.

It looks like I may have introduced a regression in zfsacl behavior. @mgittelman if you feel up for experimentation, can you try the following:
1) Check the "enable SMB1" checkbox under services->SMB
2) replace "zfsacl" with the "ixnas" module on one of your shares to verify that permissions are working as expected.

 

[mloiterman]

ixnas workaround does work, but are there any lasting negative impacts?

 

[anodos]

ixnas workaround does work, but are there any lasting negative impacts?

ixnas consolidates most of the samba customizations we do in FreeNAS. It is currently flagged as "experimental" because we're adding new features to it and rewriting some of the existing functionality so that it is more efficient. As I add new major features, I will add auxiliary parameters that allow disabling the functionality if it causes problems.
Key features it currently provides:
- Free space accounting (identical to zfs_space)
- ACL support (mostly identical to zfsacl, but has one unusual behavior in that it adds a hidden empty inheriting everyone@ ACL entry).
- DOS modes through file flags rather than xattrs.
- ZFS user quota support

 

[mloiterman]

ixnas consolidates most of the samba customizations we do in FreeNAS. It is currently flagged as "experimental" because we're adding new features to it and rewriting some of the existing functionality so that it is more efficient. As I add new major features, I will add auxiliary parameters that allow disabling the functionality if it causes problems.
Key features it currently provides:
- Free space accounting (identical to zfs_space)
- ACL support (mostly identical to zfsacl, but has one unusual behavior in that it adds a hidden empty inheriting everyone@ ACL entry).
- DOS modes through file flags rather than xattrs.
- ZFS user quota support

So, it's safe to leave this turned on with no long-term impact while we wait for fix for zfsacl?

 

[Spud]

I have this problem also and just rolled back to 11.2-RELEASE-U1, so is a fix going to happen any time soon do you think or will we have to wait for the next update?

Thanks

 

[Chris Moore]

I have this problem also and just rolled back to 11.2-RELEASE-U1, so is a fix going to happen any time soon do you think or will we have to wait for the next update?

It will be the next update, but there will certainly be a short turnaround on that update. The question is will they release a mid-cycle update like they did with the 11.1-U6.3 release, or will they rush the 11.2-U<next whole number>

 

[Phantum]

Thank you everyone! I ran into this last night and it's been driving me bonkers, zero sleep. I just found this post and greatly appreciate the support from the FN team.

 

[jgreco]

The primary change is that DOS attributes are stored a file flags (readonly -> UF_READONLY, archive-> UF_ARCHIVE, etc.) as opposed to xattrs. This should make directory listing more efficient in directories with large numbers of files. The primary downside is that if an SMB client decides to set the readonly bit, then the file is really readonly. I will put in a fix today and send you a recompiled zfsacl binary for testing.

You're with iXsystems now? When'd that happen? Congrats!