SMB Access problems

[AMiGAmann]

Hi there,

I have a TrueNAS Scale 22.02.3 installation on a brand new system and want to migrate all data from my running FreeNAS 11.2-U8 server.

But I am having problems creating the SMB shares in a correct way. I have a local user "myUser". I have a dataset with ACL Type NFSv4. I viewed the permissions of the dataset, edited them, changed them to ACL and set the user "myUser" to the owner (and checked "apply User"). I added an ACL of type "Allow" and the basic permission "Full Control".

I created a SMB share wit default share parameters, started SMB service and tried to access the share from a Windows 10 system.

But I cannot access the share. When I change the ACL on the dataset and add additionally the group "@Everyone" with full permission I am able to access the share. Windows explorer shows me the permissions for "myUser" and "Everyone", both with full access. When removing "Everyone" in Windows explorer, the access is gone again.

I then tried to enable some logging. But even with log level "Debug" of SMB service, I cannot find anything in /var/log/messages. The file /var/log/samba4/log.smbd (as seen in the tooltip of the option "Use Syslog Only") is not existing.

Does anybody know what I might do wrong or how I can enable some debug logging?

Thanks in advance!

Best regards,
AMiGAmann

 

[AMiGAmann]

Some additional information: I have a local user "myUser" and a local group "myGroup", which is the primary group of that user. On both the user and the group "Samba authentication" is enabled.

When changing the ACL to the group "myGroup" instead of the user "myUser" the access is working, even if "Samba authentication" is disabled for that group.

Very strange to me.

In the past (FreeNAS 11.2) I configured a user and a group in the permissions of a dataset and then finetuned the permissions by accessing the SMB share with Windows Explorer.

I tried to do a similar process in TrueNAS SCALE by configuring the owner and the owner group and then setting an ACL for both. I know that using NFSv4 ACL type is probably very different to FreeNAS 11.2. But I would have expected it at least to work.

Why aren't the ACL rights configured for a user not working, but the ACL rights configured for the group are working? Is that a normal behaviour or am I doing/understanding something wrong?

 

[AMiGAmann]

I still have no idea what I am doing wrong.

TL;DR:
(1) User "myUser" belonging to group "myGroup" cannot access SMB share, although ACL grants full access to user "myUser". When changing that grant to group "myGroup", user is able to access.

(2) How can I enable and see debug logging to get some information why an access to the SMB share is denied?

 

[homer27081990]

I have a dataset with ACL Type NFSv4. I viewed the permissions of the dataset, edited them, changed them to ACL and set the user "myUser" to the owner (and checked "apply User").

When you say NFSv4 you mean the standard, *nix type ACL?

I added an ACL of type "Allow" and the basic permission "Full Control".

Read the muse pointer help balloon on this: ACL type allow means it denies everything except what you explicitly allow, and type denied vice-versa, eg allows everything until you deny.

Ok. There are multiple types of "ACL". Witch are actually different things.

1. SMB - Windows ACL (image1):
Do not tinker with that, only defaults. Unless you have Windows Server ADDCs in charge... For simple client connectivity, leave it alone.

2. Local filesystem Directory Ownership and Permissions (image2)
Those with Linux experience are familiar with this. This is a fancy GUI for the *nix x xxx xxx xxx filesystem security model, eg, the left column on image3. So... it is not NFS specific, NFS is *nix specific.

This needs to be done in a specific order to work.

1. First, create (or edit) a user. Do not check MS Account. Only check connect on SMB, if it is not checked.
2. If it does not exist, create a new dataset from the 3 dots next to the pool (or dataset) you want to put the share dataset in.(image4). Set the name you want and only change type from generic to SMB.
3. Edit the Local FS Directory Ownership and Permissions (image5) of the dataset you want to share. Make sure the group (with the name of the user you want to be able to connect) can read, write, execute (tick the boxes under Group).
4. Set the user you want to connect as Owner. Set Group the same name as the user. Tick the boxes apply user and apply group (image6). Select ACL preset 'RESTRICTIVE'.
5. If you have more users, make them members of the group with the name of the first user (image7), the one owning the dataset. They do not need separate ACLs (and they can't have them anyway).
6. Create a new share and select the dataset you want. It should have a small ACL tag on the right. Do not change anything else. (image8)
7. Go to Services->find SMB and select 'edit' (little pencil on the right)->Tick NTLMv1 auth and allow SMBv1. There is a bug for now, when that is address (either by MS or TrueNAS) we turn those off. image9.

 

[homer27081990]

It goes without saying, delete the problematic share, if you have data in the share dataset move it to a new dataset, delete the old (empty now) dataset, recreate it, move data back. Follow the whole procedure, do not reuse the tinkered-with datasets and shares. (if you can, even users).

 

[homer27081990]

Also: when you try to access the share, do not go from windows explorer. Go to My Computer, right click the void, (if on win11 select more options) select map network drive (location? depends on the version), and, in share path, enter: \\<TrueNAS NetBIOS Name>\<Share Name>.
NetBIOS name is in services->SMB(edit)

Almost always, workgroup should be WORKGROUP. NetBIOS name must not have spaces or characters.

 

[AMiGAmann]

Thanks for all the information. Sadly I cannot enlarge the screenshots.

When you say NFSv4 you mean the standard, *nix type ACL?

No. I mean I changed "ACL Type" in the advanced options of the dataset from "POSIX" to "NFSv4".

I am in general able to access all the shares as I need to. But the behaviour is strange:

- I can access SMB shares if the dataset permissions (NFSv4 ACL) contain corresponding permissions for the group of the accessing (Windows) user. When the same permissions are configured directly for the user, I cannot access the share.

- Strangely I can access Unix-NFS shares only when the permissions are configured for the user. When the same permissions are configured for the group only, I cannot mount the share.

Very strange, but I can live with it...

 

[homer27081990]

Thanks for all the information. Sadly I cannot enlarge the screenshots.

Just click on them

 

[homer27081990]

No. I mean I changed "ACL Type" in the advanced options of the dataset from "POSIX" to "NFSv4".

Don't change the ACL type. Just create the NFS share and configure *nix from there.

 

[homer27081990]

- I can access SMB shares if the dataset permissions (NFSv4 ACL) contain corresponding permissions for the group of the accessing (Windows) user. When the same permissions are configured directly for the user, I cannot access the share.

Windows sees users via SID. Not by username. The internal representation of someone@something.duh is \\<SID of domain>\<SID of user>

 

[homer27081990]

Strangely I can access Unix-NFS shares only when the permissions are configured for the user. When the same permissions are configured for the group only, I cannot mount the share

The problem with NFS and Linux shares in general is that if you are not logged on at the server, your clients groups are local only, even if they have the same name. The difference from windows is you don't have to deal with SIDs, but can specify groups like this.

 

[AMiGAmann]

The problem with NFS and Linux shares in general is that if you are not logged on at the server, your clients groups are local only, even if they have the same name.

But I am using mapall-parameter in the NFS share to map all access to myUser/myGroup. So it should also work with permissions on the share only for myGroup, shouldn't it?

 

[homer27081990]

But I am using mapall-parameter in the NFS share to map all access to myUser/myGroup. So it should also work with permissions on the share only for myGroup, shouldn't it?

In order for the mapping to work, the client must be connected to the server, linux network style.

 

[homer27081990]

Give me a minute.

 

[ewhac]

It goes without saying, delete the problematic share, if you have data in the share dataset move it to a new dataset, delete the old (empty now) dataset, recreate it, move data back. Follow the whole procedure, do not reuse the tinkered-with datasets and shares. (if you can, even users).

Could you expand on this "obvious" step, please? Why is it necessary? How should the temporary dataset be set up to avoid loss of metadata?

 

[homer27081990]

Could you expand on this "obvious" step, please? Why is it necessary? How should the temporary dataset be set up to avoid loss of metadata?

No, I could not.