smb shares from 2 different angles

[sremick]

Ok I've hit the limit of my limited understanding about how share permissions work in FreeNAS and need some guidance/insight.

I have a pool, called Media. I then have an SMB share for this pool, in which I have "Allow Guest Access" enabled.

From my Linux workstation (Xubuntu), if I use the file manager (Thunar) to browse to the smb:// path, I get the dialog "Password required for share media on..." and for "Connect as" there's an option for "Anonymous". If I choose that, I can mount it fine with no password.

Files created through Thunar on this mounted path are created as nobody:wheel which is just fine, and everything works great (there are services running on the system that access these files, so that's why the permissions are broad. Also, I'm the only one accessing this).

So far so good.

Now, I have a service on my Linux workstation that can't use network paths like that. I need to create a proper mount. Very well. I create an fstab entry with type "cifs" and options "guest,rw". When I mount it, I'm not asked for a password, just as before. Perfect. However, here I am unable to edit and only have read access.

I'm missing something elementary here, but it's a combination of nuances that results in the answer totally escaping me. Show me what I'm doing wrong, and help me understand?

FreeNAS-11.3-U3.2

 

[anodos]

Ok I've hit the limit of my limited understanding about how share permissions work in FreeNAS and need some guidance/insight.

I have a pool, called Media. I then have an SMB share for this pool, in which I have "Allow Guest Access" enabled.

From my Linux workstation (Xubuntu), if I use the file manager (Thunar) to browse to the smb:// path, I get the dialog "Password required for share media on..." and for "Connect as" there's an option for "Anonymous". If I choose that, I can mount it fine with no password.

Files created through Thunar on this mounted path are created as nobody:wheel which is just fine, and everything works great (there are services running on the system that access these files, so that's why the permissions are broad. Also, I'm the only one accessing this).

So far so good.

Now, I have a service on my Linux workstation that can't use network paths like that. I need to create a proper mount. Very well. I create an fstab entry with type "cifs" and options "guest,rw". When I mount it, I'm not asked for a password, just as before. Perfect. However, here I am unable to edit and only have read access.

I'm missing something elementary here, but it's a combination of nuances that results in the answer totally escaping me. Show me what I'm doing wrong, and help me understand?

FreeNAS-11.3-U3.2

A linux "guest" mount actually performs anonymous authentication rather than using guest access. This is the security token for a typical guest session:

Code:

[2020/05/11 06:36:15.674890,  0] ../../libcli/security/security_token.c:63(security_token_debug)
  Security token SIDs (7):
    SID[  0]: S-1-5-21-1240874744-1889517628-4023922356-501
    SID[  1]: S-1-5-21-1240874744-1889517628-4023922356-514
    SID[  2]: S-1-22-2-1000
    SID[  3]: S-1-1-0
    SID[  4]: S-1-5-2
    SID[  5]: S-1-5-32-546
    SID[  6]: S-1-22-1-1000
   Privileges (0x               0):
   Rights (0x               0):

Note S-1-5-32-546 (GUEST)

This is the token for anonymous access from an ubuntu client:

Code:

[2020/05/11 09:24:21.417188,  0] ../../libcli/security/security_token.c:63(security_token_debug)
  Security token SIDs (8):
    SID[  0]: S-1-5-7
    SID[  1]: S-1-1-0
    SID[  2]: S-1-5-2
    SID[  3]: S-1-22-1-65534
    SID[  4]: S-1-22-2-65534
    SID[  5]: S-1-22-2-3003
    SID[  6]: S-1-22-2-3005
    SID[  7]: S-1-22-2-3004
   Privileges (0x               0):
   Rights (0x               0):

Note that it lacks S-1-5-32-546. The practical result is that you must use the "everyone@" ACL entry to control permissions for Linux guest access rather than the ACL for the guest account selected in the GUI. I haven't looked at Thunar's code, but it may be performing a "guest" mount rather than "anonymous" when "anonymous" is selected (a pcap will tell the full story). The point is that the two auth methods get different results and are different things.

I opened a ticket to improve our documentation in this regard.

 

[sremick]

Ok well it definitely appears Thunar is connecting as everyone@ (ACL) as making changes there immediately causes changes in what one can and can't do in Thunar. But for some reason, not only can I not get it to behave the way I want it to, but somehow I've broken it and it's not even behaving the way it was before I started. Grr.

Directory media is as such:

Code:

drwxrwxrwx+ 17 root  wheel  21 Jun  4 00:40 media/

so then in media/ we have a number of directories. Let's take "Music" as an example:

Code:

drwxrwxrwx  282 nobody  wheel  282 Jun  8 20:31 Music

So far so good. In Thunar, I connect as "anonymous" which seems to correspond with everyone@ ACL permissions. Then, within Thunar, I create a directory called "test":

Code:

drwxr-xr-x  2 nobody  wheel  2 Jun  8 20:45 test

Ownership has been inherited (or perhaps is just stamped as nobody:wheel for everything?), but note the different permissions. Subsequently, I cannot create a subdirectory under test\ or a file within test\.

In the FreeNAS ACL permissions for Media, for everyone@, I have:
ACL Type: Allow
Permissions type: Advanced
Permissions: everything checked except "Synchronize"
Flags type: Advanced
Flags: directory inherit

So I'm not sure what I've done wrong, but for some reason it seems that since the permissions are not being properly inherited on directories created by Thunar, I'm unable to make files in these directories even though I have full permissions otherwise.

 

[anodos]

What is the aclmode on the dataset?

 

[sremick]

What is the aclmode on the dataset?

Passthrough

 

[anodos]

Passthrough

Set it to restricted. This is the recommended default for SMB shares precisely to avoid issues NFSv4 special ACEs.

 

[sremick]

Set it to restricted. This is the recommended default for SMB shares precisely to avoid issues NFSv4 special ACEs.

Ok tried that. Getting all the exact same behavior/symptoms as earlier mentioned. :(

 

[anodos]

Ok tried that. Getting all the exact same behavior/symptoms as earlier mentioned. :(

Two other possibilities that can cause Linux clients to set unexpected permissions:
1) SMB1 being enabled (SMB1 POSIX extensions allow clients to directly manipulate the mode bits)
2) Client is explicitly setting those permissions.

 

[sremick]

Two other possibilities that can cause Linux clients to set unexpected permissions:
1) SMB1 being enabled (SMB1 POSIX extensions allow clients to directly manipulate the mode bits)

I checked the config under the SMB service, and "Enable SMB1 support" is not checked.

2) Client is explicitly setting those permissions.

Hmm, well I don't know where to begin on that one.

As it turned out, #1 lead me to fix the problem. In the other SMB service settings there were fields for the default file and directory masks. I know I didn't fiddle with this (they were still blank) and the defaults should've worked. But I changed them both to 0777 and it's fine now.