TrueNAS user home not working with windows server 2022 domain

[nightcore500]

Hi,
I am currently configuring a Windows Server 2022 domain and would like to use TrueNAS SCALE for all network shares. This works very well so far. The home share for all users, however, unfortunately not. I have already tried different solutions which I could find here in the forum. However without success. As a first starting point I used the docs for SCALE. (https://www.truenas.com/docs/scale/shares/)

First I added another dataset to my pool called "benutzer". As share type I set "SMB". Then ACL Type "NFSv4" and ACL Mode "Restricted" was set automatically. Now I called the permissions and changed owner group to "XXX\domänen-admins". The owner itself I left on default value as described. (root) As ACL preset I used "NFS4_HOME". Next I added another SMB share. I set the path to "/mnt/datapool/benutzer", left the default name, changed "purpose" to "No presets" and activated the setting "Use as Home Share" under "Advanced Options". After that I added a test user named "ad.test" to the Windows server and logged in with another Windows 10 PC to the domain with this user.

The result is that I have neither access to the share "homes" nor to the share "ad.test".
I have checked the permissions of the folders:

Code:

root@srv-truenas[~]# ls /mnt/datapool/benutzer/
XXX
root@srv-truenas[~]# getfacl /mnt/datapool/benutzer
getfacl: Removing leading '/' from absolute path names
# file: mnt/datapool/benutzer
# owner: root
# group: XXX\\domänen-admins
user::rwx
group::rwx
other::--x

root@srv-truenas[~]# ls /mnt/datapool/benutzer/XXX
root@srv-truenas[~]# getfacl /mnt/datapool/benutzer/XXX
getfacl: Removing leading '/' from absolute path names
# file: mnt/datapool/benutzer/XXX
# owner: root
# group: XXX\\domänen-admins
user::rwx
group::---
other::---

The domain folder in the dataset was created, but no folder for the user "ad.test".
In the log.smbd only the following can be found:

Code:

[2022/04/01 17:11:04.799002,  1] ../../lib/param/loadparm.c:1766(lpcfg_do_global_parameter)
  lpcfg_do_global_parameter: WARNING: The "syslog only" option is deprecated
cannot open '/mnt/datapool/benutzer/XXX/ad.test': No such file or directory
[2022/04/01 17:11:05.114854,  0] ../../source3/smbd/service.c:808(make_connection_snum)
  make_connection_snum: canonicalize_connect_path failed for service ad.test, path /mnt/datapool/benutzer/XXX/ad.test
[2022/04/01 17:11:05.129959,  0] ../../source3/smbd/service.c:808(make_connection_snum)
  make_connection_snum: canonicalize_connect_path failed for service ad.test, path /mnt/datapool/benutzer/XXX/ad.test
[2022/04/01 17:11:05.134154,  0] ../../source3/smbd/service.c:808(make_connection_snum)
  make_connection_snum: canonicalize_connect_path failed for service ad.test, path /mnt/datapool/benutzer/XXX/ad.test

What am I doing wrong here? TrueNAS SCALE is on version 22.02.0.1.

 

[nightcore500]

I have now tried a few more things. I used "NFS4_DOMAIN_HOME" for the dataset instead of "NFS4_HOME". Also I changed the group of the dataset to "XXX\domänen-benutzer". If I now remove the domain folder "XXX" in the dataset via shell and restart the smb service, it now also creates the user's folder in the domain folder after logging on to the windows 10 PC. However, the folder has the wrong permission:

Code:

root@srv-truenas[/mnt/datapool/benutzer/XXX]# getfacl ad.test
# file: ad.test
# owner: root
# group: root
user::rwx
group::---
other::---

Logically, the user still has no access to his own home share. I have now set the debugging in the smb settings to "full". Then I removed the domain folder in the "benutzer" dataset and restarted smb. I have attached the resulting log.

Does anyone have an idea what my problem is?

 

[merubic]

Hey nightcore500,
I have the same problem right now. But I use windows server 2016 as domain controller. The AD's folder is created in the dataset. Also with the permissions you described. TrueNAS but only after leaving the domain and re-entering the domain also created the user's folder. But for me only after leaving the domain and re-entering the domain, the user's folder was also created in the AD folder. But also with wrong rights. The folder belongs to root and also to the group root. I have now even tried a new Windows server with new AD installed and a fresh truenas installation. The problem occurs immediately. So it can be reproduced instantly.

I suspect that this is a bug. Have you been able to get any more information?

 

[wildone81]

I can also confirm that I'm running into the same issue, currently using a different Samba4 server for my AD, and after setting the file mask and directory masks to default 0666 and 0777 respectively and wiping the directory structure created, the domain directory is set 0770 with root/domain admins as the principles and the user directory ends up with 0700 and root/root after restarting Samba in TrueNAS.

 

[nightcore500]

Hi Merubic,
nice to know that i'm apparently not alone with this problem :D

I tried another attempt with an english installation of the AD. I thought there might be a problem with "öäü" for the default groups "domain admins" and "domain users".
But this was not the problem. The same problem occurred here as well. The AD was a fresh installation with all available updates. First I set up the AD and added truenas and my windows 10 client to the AD.
Then added the share in truenas and set the permission to "NFS4_HOME" and changed the group to "XXX\domain users". Then added a user in AD and logged in with the windows client. As before the AD folder was created and also the user folder. But again with wrong permissions. (root/root)
The user could not access his home share again. I have also tried the group "domain admins" and the same again with "NFS4_DOMAIN_HOME". Always with the same result.
What the cause for this is I unfortunately still do not know.

I also noticed that setting Services -> SMB -> Advanced Settings -> Administrators Group leads to the error "[ENOMETHOD] Method 'synchronize_group_mapping' not found in 'smb'".
But this will probably not be the problem.

 

[nightcore500]

Hi @merubic @wildone81 ,
I have just created a ticket regarding the problem:

https://jira.ixsystems.com/browse/NAS-115631

 

[wildone81]

Well, with any luck we will either have an improved guide that makes sense for those that aren't too used to ACL, or there is some sort of setting that should have been set by default to work with AD.

 

[nightcore500]

@wildone81
I suspect that the smb service mistakenly creates this folder as root and then does not assign the permission to the user as intended. It is possible that another parameter is missing in the smb config which is necessary for this. However, this is only pure speculation.

We will have to be patient a little longer. The next code-freeze for the upcoming version 22.02.1 is already tomorrow (06 April 2022) The ticket was already dated by a developer for 22.02.2. The release would then be according to the release schedule on 21 June 2022.

Until then I just manually create the required shares.

 

[wildone81]

Well, we still have to wait to see if it'll actually be fixed for 22.02.2, given that it's still at the first stage. They probably just put a placeholder until they research it further.

 

[wildone81]

So a little more investigation, and I think part of the problem is the uid/gid isn't being respected in TrueNAS (all pii replaced with the usual):

dc1 / # getent passwd username
DOMAIN/username:*:3000018:3000004:First Last:/home/DOMAIN/username:/bin/bash
dc1 / # getent group "Domain Admins"
DOMAIN/domain admins:x:3000004:

root@truenas[~]# getent passwd DOMAIN\\username
username:*:100001105:100000514::/var/empty:/bin/sh
root@truenas[~]# getent group "DOMAIN\\Domain Admins"
domain admins:x:100000513:

 

[wildone81]

Another thing I found out is that none of additional settings I tried to add to the main smb config through the web interface are ever added to the smb4.conf file, so nothing I can try to resolve the issue will work.

 

[DannyB]

This looks like an IDMAP failure of some sort.
Does your active directory idmap range match your actual active directory ids?

A bunch of the config options are also stored in the registry, and smb4.conf is set to use the registry.
This includes all the idmap stuff, and i believe all the extra options you add are put there.

Run samba-regedit from a shell, go to HKLM\Software\Samba\smbconf and you should see the config settings.

 

[DannyB]

To go into a bit more detail:

The default idmap backend being used by truenas for AD is autorid, which assigns new local ids to each active directory user.
This lets it support multiple domains at once, since each domain could have conflicting ID ranges.

Normally, with a single AD server, you'd just use the ad backend, which does 1:1 mapping on it's own.
This doesn't look easily changeable in truenas.
Instead, you need to make sure the RID range matches your ad range exactly, and then you should get the same ids both locally and on the AD server.

 

[wildone81]

Yeah, that's about what I figured, since I couldn't actually force it to set up as the Samba-Wiki advised. For now I have it somewhat working, but it still is disappointing how my settings aren't being saved at all.

 

[DannyB]

I verified that settings are saved in the registry and used.

 

[wildone81]

Now I understand how they chose to set it up, registry versus a readable and accessible config file. I can see how difficult it is to change settings.

 

[DannyB]

Yeah. To be fair, samba is trying to move to registry config, because they now support AD, and the configs are complex and registry based on windows.
So if they want any tools to work with both, they need most of their config in the registry.

 

[T4ke]

Hey everyone, from my point of view this issue still exists, event with the new update released yesterday. Can anyone confirm this?

 

[nightcore500]

@T4ke
Hey, yes the issue still exists. You can watch the progress here: https://jira.ixsystems.com/browse/NAS-115631

 

[T4ke]

Ah yes, I see. So we can expect a fix from the line "Fix Version/s: SCALE-22.02.3 (Angelfish)" in the next release in August I guess, right?