can't access smb share

[pet1022]

Hello,

I really need help with my smb shares because it doesn't work.
First of all it's my first experience with ACLs which I don't understand much. I'm in a test period for the moment.
Objective : to create a dataset for my son, dataset on which his mother and me have also the rights.

User profile
user : willy
home directory : /mnt/Data_1/Willy
primary group : willy
secondary groups: Medias, builtin_users

SMB share configuration with ACL :
File information
Path: /mnt/Data_1/Willy
User: willy
Group : parents



Access control list

Who: owner@
Type ACLs : Authorize
Authorization Type: Basic
Authorization: Full control
Flag type: Basic
Flags: Inherit

Who: group@
ACLs type: Authorize
Authorization type: Basic
Authorization: Full control
Flags type: Basic
Flags: Inherit

Who: everyone@
ACLs type: Deny
Authorization type: Basic
Authorization: Full control
Flags type: Basic
Flags: Inherit


I specify that I connect with my user "jean" and that his mother and I are part of the "parents" group

=> when I connect (with my login), I see the share on my pc, but impossible to access it.

So I did an ls -l on the dataset "willy" :

d---------+ willy parents

Then, I go in the profile of the user "Willy", I discover that the authorizations I had put on the personal directory have all disappeared.
So I checked the permissions
User : rwx
Group : rwx
others : ---


Then I go back to Storage > dataset "Willy" > modify permissions :
I realize that I am in "permissions editor" mode and not in "ACL editor" mode


The Windows message is that I may not have the necessary permissions to use this network resource.

Basically I'm going in circles.
Can you help me please ?

 

[pet1022]

Hello,
I have made some progress.
First of all I managed to solve the rights problem, but I don't know how. Now I can access to Willy share.

To achieve this, I think I deleted Willy's home directory (/nonexistent) in his profile and deleted all the acls of the share. Then I reconfigured.

I think there is a distinction to make between the "home" directory of a user and the datasets where Willy is "owner".
I always thought that a user should have a home directory, but is it really necessary?
(except for the user who connects with ssh keys)

My new problem comes now from the ACL settings. Despite many attempts, I can't get the behavior I want.

TEST 1
ACLs configuration : dataset "willy"
owner: willy
group: parents

Who: owner@
Type ACLs : Authorize
Authorization Type: Basic
Authorization: Full control
Flag type: Basic
Flags: Inherit

Who: group@
ACLs type: Authorize
Authorization type: Basic
Authorization: Full control
Flags type: Basic
Flags: Inherit


Creation of files :

• login to the smb share as user "willy" => create a text file "trad.txt"
• login to the smb share as user "jean" (parents group) => create a text file "form.txt"
• login to the smb share as user "annie" (parents group) => creation of a text file "manip.txt"

Results:

• user "willy" cannot save a modification on the files "form.txt" and "manip.txt"
• the user "jean" (member of the group "parents") cannot save a modification on the files "trad.txt" and "manip.txt"
• the user "annie" (member of the group "parents") cannot save a modification on the files "trad.txt" and "form.txt"

TEST 2

• all the files "trad.txt" and "form.txt" and "manip.txt" previously created have been deleted in order to start again on a blank dataset.
• changes from test 1 have been highlighted

ACLs configuration : dataset "willy"
owner: willy
group: willy

Who: owner@
Type ACLs : Authorize
Authorization Type: Basic
Authorization: Full control
Flag type: Basic
Flags: Inherit

Who: group@
ACLs type: Authorize
Authorization type: Basic
Authorization: Full control
Flags type: Basic
Flags: Inherit

Add ACL:
Who: group
group: parents
ACLs type: Authorize
Authorization type: Basic
Authorization: Full control
Flags type: Basic
Flags: Inherit


Creation of files :

• login to the share as user "willy" => creation of a text file "trad.txt"
• login to the share as user "jean" (parents group) => create a text file "form.txt
• login to the share as user "annie" (parents group) => creation of a text file "manip.txt

Results:

• user "willy" cannot save a modification on the files "form.txt" and "manip.txt", thus the files created by the members of the group "parents". User "willy" has to save the modified files under another name.
• users "jean" and "annie" can modify and save all the files of everybody.

Although "test 2" is more in line with what I want, I don't understand why the user "willy" who owns the dataset can't modify files created by users who are members of the "parent" group.

Exception:
if I don't delete the files, and I go back to volume > dataset "TOTO" > 3 dots > modify permissions > check the box "apply permissions recursively" > save.
In this case, the user "willy" can save a modification on any file already created. On the other hand, if a new file is created by one of the members of the "parents" group, then the user "willy" will not be able to save a modification on this new file.

I specify that reading, opening, and deleting files does not seem to be impacted
Do you have any idea what's wrong because I don't know what to do anymore ?

Regards

 

[KrisBee]

@pet1022

You're right to make that distinction about a user's "home" directory etc. For simplicity I'd stick to adding individual datasets for specific users or groups.

Windows doesn't have the concept of creating a new primary group with the same name as the user for every new local account added. So if the NAS is accessed mostly via Windows to best to think in groups first and then add users to various groups in TrueNAS, leaving their home directory as nonexistant.

Your "test2" ACL list looks correct to me, but one gothca is when you created the dataset "willy" you needed to set it's share type as SMB. Use the dataset "edit options" to check if the dataset is set to ACL mode "restricted" and "insensitive" case sensitivity. When actually creating the windows share choosing "default share parameters" should be OK. Another gothca can be that Windows has hung on to old connections while you are making changes on the NAS and swapping between Windows users.

Be systematic, make a change on your NAS, log out of Windows and on your NAS check that there are no old connections. SMB connections are not reported via the webui. So select the "shell "option and just type this command "smbstatus". It might take a few moments, so just repeat the command until you see something like this:

You might find this video useful: https://youtu.be/QIdy6sR0HrI

 

[pet1022]

Hello and thank you for your feedback.

Be systematic, make a change on your NAS, log out of Windows and on your NAS check that there are no old connections. SMB connections are not reported via the webui. So select the "shell "option and just type this command "smbstatus". It might take a few moments, so just repeat the command until you see something like this:

Thanks, I didn't know this command.
I only log out by restarting the "Workstation" service. With your "smbstatus" command, I confirm that there are no old connections by doing this.

You might find this video useful: https://youtu.be/QIdy6sR0HrI

Yes, I had already watched this video, and others too.

Your "test2" ACL list looks correct to me, but one gothca is when you created the dataset "willy" you needed to set it's share type as SMB. Use the dataset "edit options" to check if the dataset is set to ACL mode "restricted" and "insensitive" case sensitivity.

I have a pc that runs windows 10, a pc that runs linux mint, and android smartphone and a lineage OS smartphone that will connect to the shares.
When creating the dataset, I chose "Generic" for the share type.
I wasn't sure which one to choose, and the doc isn't very chatty about it. When you click on the "?" when choosing, it says "Choose the type that matches the type of client accessing the volume/dataset."
Since I have several client types, I decided to choose "Generic."
On the other hand, I am well in "insensitive" mode.
on the other hand, LCD mode is on "passthrough".

regatrds

 

[KrisBee]

I haven't looked at the TrueNAS documentation lately about what is says. The Linux Mint file manager should connect to SMB shares out of the box, prompting you to enter credentials. You'd have to check your smartphones to see if they both support SMB shares. Plain andriod should with the appropriate app. So you really want to use shared type "SMB" and not generic for your datasets, then all your devices should be able to conect to your shares. The TrueNAS ACL editor is for datasets you intend to share via SMB. Re-create your "willy" dataset with share type "SMB" and re-test.

 

[pet1022]

You'd have to check your smartphones to see if they both support SMB shares

Yes there is the "android samba client" application that now allows you to mount smb shares on android. i tested it and have access to my share. I have not yet tested the permissions.

So you really want to use shared type "SMB" and not generic for your datasets, then all your devices should be able to conect to your shares

sorry, I didn't quite understand what you meant.
I'm not limited to using SMB, but smb shares seems to be the best for this kind of sharing.
What do you mean by "generic"? If you mean using unix rights (rwx), I would prefer. ACLs are really complicated for my taste. But when I switched from freenas 9.3 to truenas 13, I tested the unix permissions as I knew them, but there was the same kind of permissions problem. I was advised to use ACLs.

Do you know how "smb" or "generic" differ (except for the choice of case for the generic mode)

Re-create your "willy" dataset with share type "SMB" and re-test.

ok I test.

thank you

 

[pet1022]

Hello,

Good news, I managed to make my shares with the behavior I am looking for. In any case it seems to work correctly.
On the other hand I have some uncertainties:

For example: I have a dataset "Medias" accessible for all users.
I set it up like this:
owner
user : nobody (acl set to read)
group : medias (a group I created, no "media") (acl set to read)
=> I added an ACL to the "builtin_users" group with the "modify" permissions

Question:
1] I put the user "nobody" because I didn't know who to put. Is this a good practice? If not, who to put?


Other questions:

2] What is the difference between the "everyone@" group and the "builtin_users" group since all new users are by default in the "builtin_users" group.
Maybe the difference is if you remove a user from the "builtin_users" group?

3] Is not setting an ACL entry to a group or a user equivalent to making an ACL entry with the following parameters
_ACL type: "deny
_authorization type: "full control

4] I want to make a share without password (guest). For the moment I have set as owner :
user : nobody (ACL set to read)
group : nogroup (ACL set to read)
Is it a good practice to put this user and this group?

While searching, I found this post: https://www.truenas.com/community/threads/file-rights-acl-please-kill-me-now.91439/post-633456

For more predictable behavior with ACLs on an SMB share, I recommend using the "restricted" aclmode and explicit group entries (not group@) to manage permissions.

I didn't quite get it, but @anodos mentions avoiding using group@ entries.
Better not to put an ACL entry for user@, group@, everyone@ and add an entry of a group "X" in which the owner is a member?

Regards

 

[KrisBee]

1. Best practice depends on use case and which user accounts actually create data in the associated dataset. There also a less obvious point about groups here, see below.

2. everyone@ is not a group on TrueNAS. It's a Windows concept. In TrueNAS(FreeBSD) and Linux you have the concept of user, group, other when referring to standard permissions. Where "other" equates to "everyone else" that is "everyone minus the user or group members". In Windows, "everyone" means what is says.

3. I think of explicit deny ACLs being used as exceptions, e.g. all user in a group are allowed access except one or more specific users are denied access.

4. I don't use password less guest access.

That quote is in the context of TrueNAS SCALE where both NFSv4 and POSIX.1e ACL types exist. It's complicated and I cant say I follow every step of the logic. I think this quote is more relevant to you:

Are you setting permissions for group@ in the NFSv4 ACL or are you assigning permissions explicitly to the groups. The group designated by group@ will change as different users create files / dirs based on user's primary group (which will change how access is evaluated).

While this all applies to SMB shares accessed from Windows, the question is what happens when the same shares are accessed from Linux or your Andriod smart phones. Are these ACLs honoured?

 

[pet1022]

Hello,

Sorry for my late reply.

While this all applies to SMB shares accessed from Windows, the question is what happens when the same shares are accessed from Linux or your Andriod smart phones. Are these ACLs honoured?

I have not had the opportunity to test it. I'm already trying to understand how ACLs work on windows

2] What is the difference between the "everyone@" group and the "builtin_users" group since all new users are by default in the "builtin_users" group. Maybe the difference is if you remove a user from the "builtin_users" group?

2. everyone@ is not a group on TrueNAS. It's a Windows concept. In TrueNAS(FreeBSD) and Linux you have the concept of user, group, other when referring to standard permissions. Where "other" equates to "everyone else" that is "everyone minus the user or group members". In Windows, "everyone" means what is says.

In my research, I came across this page, where anodos explains that owner@, group@ and everyone@ should be considered equivalent to User - Group - Other on the POSIX system. You say that owner@, group@ and everyone@ are windows concepts. Can we consider user (POSIX) = owner@ ? ...

3] Is not setting an ACL entry to a group or a user equivalent to making an ACL entry with the following parameters
_ACL type: "deny
_authorization type: "full control

3. I think of explicit deny ACLs being used as exceptions, e.g. all user in a group are allowed access except one or more specific users are denied access.

Sorry, I must have phrased my question wrong.
I understood that the "Deny" ACL type is rarely used. I guess it allows to refine the permissions (for example it allows to give access to a dataset to a user, but to deny him the permission to "read the attributes").

I'll use an example to illustrate:
let's take a dataset "Toto" (smb share)
_ user owner : "tata"
_ group owner: "tata"

ACL:
--------------------------------------------------------
owner@ :
type ACL: allow
authorization type : full control

group@ :
ACL type: authorize
authorization type: full control

everyone@ : no ACL input set

group : media
ACL type: allow
authorization type: read
--------------------------------------------------------

In this case, when I set the reading to the "Media" group if I do a getfacl command on the dataset "Toto", I get :

[...]
group : media : r-x---a-R-c---:fd-----: allow

If now I configure the group "Media" like this:
group: media
ACL type: deny
authorization type: read

A getfacl command on the datatset "Toto" gives me:

[...]
group: media: r-x---a-R-c--s:fd-----: deny

How does the system interpret the ACL type "deny" ? Can we consider that the refusal of a permissions is equivalent to not determining any permissions for it. Obviously there is a difference between for example :

group : media : rwxpDdaARWcCos:fd-----: deny

and

group : media : -------------s:fd-----: allow

However, in practice, it is the same thing
Hence my initial question: is "deny" rights the same as not setting rights?


-----------------------------------------------------------------------------------------------------------------------------------------------


Others questions :
_ I don't quite understand the notion ACL Mode "Passthrough". When to use this mode ? Do you have an example?
_ I understand the notion "inherit", but I don't quite understand the notion "no inherit", or rather in which case to use it?

Regards

 

[pet1022]

Hello,

3] Is not setting an ACL entry to a group or a user equivalent to making an ACL entry with the following parameters
_ACL type: "deny
_authorization type: "full control

3. I think of explicit deny ACLs being used as exceptions, e.g. all user in a group are allowed access except one or more specific users are denied access.

I made a test, which result surprised me.
Here is my setting :
_dataset "Titi" (smb share)
user owner : Jean
group owner : Jean

owner@ : authorized - full control
group@ : authorized - full control
group "Media" : authorized - modification
everyone@ : refuse - full control

I thought that the dataset "Titi" would be accessible by Jean and the members of the group "Media".

Result : not at all
Everybody, including Jean and the members of the "Media" group have been denied access to the "Titi" dataset.

The "everyone@" parameter has taken precedence over all the others.

 

[WN1X]

That is how SMB ACLs work...deny takes precedence.

Remove the everyone refuse entry.

 

[pet1022]

That is how SMB ACLs work...deny takes precedence.

Hello,

This is the kind of information I would like to find about ACLs.
I'm progressing little by little by doing tests, but at some point there is a need for an explanation of the results we get.
It's not easy when you're a beginner with ACLs.
Where can I find some reading (tutorials, explanations, best practices) on the subject that is simple and accessible for a novice?
There are many tutorials that show how to do an smb share with ACLs, but there is not much information that explains why to do it, or the concrete consequences of the chosen options. (For example, generic/smb , passthrough /restricted, inherit / no inherit)

For exemples (see #9):

Others questions :
_ I don't quite understand the notion ACL Mode "Passthrough". When to use this mode ? Do you have an example?
_ I understand the notion "inherit", but I don't quite understand the notion "no inherit", or rather in which case to use it?

or

Hence my initial question: is "deny" permissions the same as not setting permissions?

Regards

 

[WN1X]

Deny permissions are not the same as not setting permissions. By default, if a user is not matched in an ACL, they are blocked from accessing the share. So why have deny as a legal ACE? I give a group access to a share, but need to exclude a single user, so I put a deny ACE in for said user.