11.2 U2 changes how SMB+Unix share permissions work

KrisBee · Feb 19, 2019

anodos said:
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 · Feb 19, 2019

KrisBee said:

@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 · Feb 19, 2019

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 · Feb 19, 2019

indivision said:
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 · Feb 19, 2019

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 · Feb 19, 2019

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 · Feb 20, 2019

Lothian said:
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 · Feb 20, 2019

Why is
Only Allow Guest Access
shown twice

anodos · Feb 20, 2019

Koen_Oostende said:
Why is
Only Allow Guest Access
shown twice

Someone must have made made a mistake.

sctracey · Feb 20, 2019

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

LarryG · Feb 21, 2019

Koen_Oostende said:
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 · Feb 21, 2019

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.

anodos said:
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 · Feb 23, 2019

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

anodos · Feb 23, 2019

mloiterman said:
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 · Feb 23, 2019

anodos said:
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 · Feb 24, 2019

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 · Feb 24, 2019

Spud said:
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 · Feb 24, 2019

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 · Feb 26, 2019

anodos said:
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!

Important Announcement for the TrueNAS Community.

11.2 U2 changes how SMB+Unix share permissions work

Wizard

Sambassador

Guru

Sambassador

Guru

Dabbler

Sambassador

Dabbler

Attachments

Sambassador

Cadet

Dabbler

Dabbler

Dabbler

Sambassador

Dabbler

Contributor

Hall of Famer

Cadet

Resident Grinch

Similar threads