Myself and many other users are experiencing many issues with SMB shares using Windows Active Directory since upgrading to 6.10.2. Upgrading to later versions has not fixed this, tested on 6.10.3 and 6.11.1

 

These issues are reported in this forum thread:

 

 

 

Reported symptoms are:

 

Intermittent access issues from Windows PCs to the Unraid shares. Occasionally only some user accounts are affected and some accounts are fine and have no problems.

 

UNRAID log drive filling up due to very large syslog files. The syslog shows continual refused mount requests for my account and this seems to be as it cannot convert my SID to a UID.
 

Jul 15 21:58:49 UNRAID01 smbd[****]:   check_account: Failed to convert SID S-1-5-21-XXXXXXXX-XXXXXXXX-XXXXXXXX-1105 to a UID (dom_user[DOMAIN\username)

 

The  /var/log/samba/log.smbd log file is also full of the same error message.

 

Also calling wbinfo fails for some user's Windows accounts:

root@UNRAID01:~# wbinfo -i myuser
failed to call wbcGetpwnam: WBC_ERR_DOMAIN_NOT_FOUND
Could not get info for user myuser
root@UNRAID01:~# wbinfo -i okuser
okuser:*:NNNNNNNN:NNNNNNNNNN:okuser:/home/DOMAIN/okuser:/bin/false

 

 

Potential workarounds for this issue are reported in this thread:

 

 

Edited November 4, 20223 yr by Geoff Bland

This is a workaround for the issue that has been found and has worked for a number of users. 

 

Use this fix at your own risk.

 

The problem appears to be that Unraid is using a later version of the Samba Service but with an ID mapper (idmap_hash) that was end of life over 5 years ago and is known to cause issues. The fix is to "correct" Unraid's standard server configuration for Samba to use the correct ID mappers. 

 

These sites were of particular use:

 

https://support.microfocus.com/kb/doc.php?id=7007006
https://lists.samba.org/mailman/listinfo/samba
https://www.samba.org/samba/docs/current/man-html/
https://www.samba.org/samba/docs/current/man-html/idmap_hash.8.html
https://www.samba.org/samba/docs/current/man-html/idmap_tdb.8.html
https://www.samba.org/samba/docs/current/man-html/idmap_rid.8.html

 

NOTE after this fix, as user IDs get changed, permissions need to be re-applied (although see also GrantE's post that details you can do some calculation to determine the new ID range for users and preserve any correct working permissions).

 

Workaround UNRAID Samba Access Issues.

 

Open the Unraid terminal, ">_" button on top of each Unraid page. 

 

First back up smb-extra.conf  file as follows:

cp /boot/config/smb-extra.conf /boot/config/smb-extra.conf.bkp

Edit the contents of /boot/config/smb-extra.conf and add these lines, replacing <SHORT_DOMAIN_NAME> with the name of your domain (the same as appears in the "AD short domain name" field of your Unraid SMB settings):

 

[global]
idmap config * : backend = tdb
idmap config * : range = 1000-7999      
idmap config <SHORT_DOMAIN_NAME> : backend = rid
idmap config <SHORT_DOMAIN_NAME> : range = 10000-4000000000

 
The idea is that RID ID mappings are consistent and a given domain account will always map to the same local ID on Unraid, so if for some reason the IDs get reset the same domain accounts will remap to the same local IDs and retain access rights. Also a range of tdb IDs is assigned in case any SMB accounts are used without a domain. 

 

This will be shown as "extra configuration" on the Unraid SMB Settings page. Other Unraid plugins (such as unassigned devices) may also add configuration to this same smb-extra.conf - leave these as is and just add these extra lines to the top.

 

Then reboot Unraid (just restarting the SMB service does not work fully).

 

Finally check and fix all your permissions, as detailed below.

 
Reset/Re-apply UNRAID Permissions.

Open the Unraid terminal, ">_" button on top of each Unraid page. 

Run the following commands where <share> is the name of the share (each can take a long time if you have many files). 

chown -R root /mnt/user/<Share>
chgrp -R domain\ users /mnt/user/<Share>
setfacl -R -b /mnt/user/<Share>
chmod -R g+rwx /mnt/user/<Share>

 
If you need Windows permissions on the folder then apply permissions via Windows (NOT via Unraid Share SMB User Access settings).

 

Open UNRAID Shares in File Explorer.

Right click on the Share, select Properties.
Select Security tab.
Click "Advanced".
Add, remove and alter permissions as required - note you may need to check the "Replace child object permissions" options to get this to work properly. 
Hit apply  
If using NFS from this share just refresh it (add/delete a space on the NFS rule and hit Apply) on UNRAID for some reason these seem to lose access rights when Windows changes the permission even when they should not. 

 

Some commands to diagnose issues:

 

root@UNRAID01:~# net ads info

 Checks UNRAID is correctly joined to your AD domain.

 

net ads user --user=DomainName/username --password=*********

Checks UNRAID can correctly connect to Windows AD users and get user access information.

 

wbinfo -i username

Checks UNRAID can authenticate this user with Windows AD users and get this user's access information.
 

Hi Geoff.


That has done the trick for the most part. Only issue I have is. which may be just a "me" issue.

Even with perms tied down for the most part. I can only get Access to my Shares if I set "chmod 777 /mnt" on the Root Folder (Not Recursive) without that, I get the typical Access Denied speak to the Administrator etc etc.

 

So, I have added a Delayed "chmod 777 /mnt" to my Go File so Shares (all Shares) can become Accessible. without that. I get Red X's stating "Denied" this is Across all 3 Servers.


 

On 11/15/2022 at 4:44 PM, Stan464 said:

I can only get Access to my Shares if I set "chmod 777 /mnt" on the Root Folder (Not Recursive) without that, I get the typical Access Denied speak to the Administrator etc etc.

 

Weird. My /mnt directory has the expected 755 permissions and works fine with this.

 

root@UNRAID:/# ls -la / | grep mnt
drwxr-xr-x  16 root root   320 Nov 15 16:27 mnt/

 

2 hours ago, Geoff Bland said:

On 11/15/2022 at 11:44 AM, Stan464 said:

I can only get Access to my Shares if I set "chmod 777 /mnt" on the Root Folder (Not Recursive) without that, I get the typical Access Denied speak to the Administrator etc etc.

 

Weird. My /mnt directory has the expected 755 permissions and works fine with this.

 

root@UNRAID:/# ls -la / | grep mnt
drwxr-xr-x  16 root root   320 Nov 15 16:27 mnt/

 

 

I have contended for years that solving SMB problems has more to do with Witchcraft than Science...     😈

This is still an issue in Unraid over a year later. I'd forgive it if it was just another free to use Linux distro, but I've paid good money for licenses for a software I can't even use

3 hours ago, RockHub said:

This is still an issue in Unraid over a year later. I'd forgive it if it was just another free to use Linux distro, but I've paid good money for licenses for a software I can't even use

 

You really need to provide complete details about what your specific issues are.   (What you have told us so far is similiar to saying, "I have a problem with my car and I want it fixed!"  Without details, we don't know if the engine won't start or if the radio doesn't work or if the left rear window won't go down...)

 

 

 

      

On 1/8/2024 at 12:50 PM, Frank1940 said:

 

You really need to provide complete details about what your specific issues are.   (What you have told us so far is similiar to saying, "I have a problem with my car and I want it fixed!"  Without details, we don't know if the engine won't start or if the radio doesn't work or if the left rear window won't go down...)

 

 

 

      

This is literally an entire thread dedicated to the problem at hand. It's been bought up many times since, and all other threads eventually point back to this thread and Geoff's great effort in figuring out a workaround

 

That said, I've since managed to upgrade to 6.12.6, so let's see if I need to humbly retract my previous (and overly aggressive, my apologies) comment 😁

1 hour ago, RockHub said:

This is literally an entire thread dedicated to the problem at hand. It's been bought up many times since, and all other threads eventually point back to this thread and Geoff's great effort in figuring out a workaround

 

That said, I've since managed to upgrade to 6.12.6, so let's see if I need to humbly retract my previous (and overly aggressive, my apologies) comment 😁

 

I also owe you a bit of a apology.  I was 'following' this thread and didn't realize that it was in the 'Active Directory' sub-forum.  All of my experience is with the 'ugly-stepchild' of Windows Networking--- the peer-to-peer part of SMB.  (Most of the Unraid users employ peer-to-peer networking and MS is more concerned with AD security--- and their corporate clients ---than with the small universal of people who use peer-to-peer.) 

 

Many of those 'home network' Unraid users are just not concerned about security and try use use peer-to-peer with as little thought to security as possible.  When MS addresses a security issue that effects the corporate world, it often breaks those minimum security Unraid network setups.  Then they scramble to find a solution to undo the security fix.  (A whack-a-mole approach!)  The Samba software team will update the samba code as required to address these changes. 

 

It is my contention, that all Unraid SMB/Samba users should employ a reasonably secure network setup.  MS has and will continue to upgrade security to SMB on Windows clients as they deem necessary.  If those security changes break some peer-to-peer networks that are attempting to run with little-to-no security on them, so be it.  These SMB security upgrade issues can be avoided 99% of the time by just setting up the peer-to-peer network to be secure.  This requires that no Windows computer will ever need to use a guest connection to a server.  Every Windows will have a user name and password to access their Unraid server.   It means that the network should be configured so that SMBv1 is not required for operation.   (I might point out this eliminates the need for 'Public' or 'Secure' Security settings on Shares if one is using all Windows clients.  The need for those two settings is often dictated by other devices--- like old Media players from the 2010 time period that only use SMBv1.)

Please install the "Active Directory Extras" plugin from CA and make the adjustments you think you need to get AD working.  If there are other settings required, let me know and I'll make adjustments to the plugin.

 

I believe it will let you make the changes needed to get AD working.

Hi, it didn't fix anything for me. 
The permissions shown from the Unraid CLI are:
drwxrwx---+ 1 administrator domain admins  6 Apr 22 07:34 ./
drwxrwxrwx  1 administrator domain admins 28 Apr 22 07:34 ../

What I see when looking at the permissions from the Windows PC with Domain Admin logged in is:

The gw account should have permissions when you look on the Windows side, but it doesn't exist on the Unraid side.

Did you make any adjustments to the settings?

This are my settings:

No idea what I have to change to fix my issue. I can list the AD users with "wbinfo -u", so the connection to the DC should be ok. The server is joined to the AD.

It's just that Unraid doesn't care about what permissions I set from the Windows machine.

I was checking the permissions again with getfacl:
root@nas01:/mnt/user# getfacl Pub
# file: Pub
# owner: gwadmin
# group: domain\040admins
user::rwx
user:domain\040admins:rwx
user:gw:rwx
group::rwx
group:domain\040admins:rwx
group:gwadmin:rwx
group:gw:rwx
mask::rwx
other::---
default:user::rwx
default:user:gwadmin:rwx
default:user:gw:rwx
default:group::---
default:group:domain\040admins:---
default:group:gwadmin:rwx
default:group:gw:rwx
default:mask::rwx
default:other::---

I found this in the log:
Apr 22 17:04:11 nas01 smbd[31377]: [2024/04/22 17:04:11.224805,  0] ../../source3/smbd/smb2_service.c:168(chdir_current_service)
Apr 22 17:04:11 nas01 smbd[31377]:   chdir_current_service: vfs_ChDir(/mnt/user/Pub) failed: Permission denied. Current token: uid=11111, gid=10513, 14 groups: 11111 10513 11146 11144 14631 11118 11632 11138 11637 11635 1003 1004 1006 1001

 

What am I doing wrong?

2 hours ago, kontraschub said:

What am I doing wrong?

Try clicking on the "Clear Cache" button.

This are my settings:

No idea what I have to change to fix my issue. I can list the AD users with "wbinfo -u", so the connection to the DC should be ok. The server is joined to the AD.

It's just that Unraid doesn't care about what permissions I set from the Windows machine.

Edited April 22, 20242 yr by kontraschub

I tried the "Clear Cache" button already more than one time. Unfortunately no change.

As noted on the "Active Directory Extras" page, if you change the backend database, you need to re-enter all your permissions.  The default backend database in Unraid is 'hash' and if you change to 'tdb', you have to reset all your permissions.

If re-enter means to set the permision to a share again using a Windows machine, then I did it already. Even new shares don't work. 

If I add "full control" to "everyone" then it works. But that's not what I want. 

 

Edited April 23, 20242 yr by kontraschub

4 hours ago, kontraschub said:

If re-enter means to set the permision to a share again using a Windows machine, then I did it already. Even new shares don't work. 

If I add "full control" to "everyone" then it works. But that's not what I want. 

 

Try some of the ideas mentioned earlier in this forum post.  If I can get ideas from users on what additional settings the AD Extras plugin needs, I can implement those.  Unfortunately, I don't have any way of testing AD because I do not have a Windows server.  I rely on the users here to give me ideas on what is needed.

Thx for your help dlandon, but I give up for now.

I am having the same problem as unable to join an active dir domain. 

This was working fine until i has restore the virtual machine running AD with a backup. 

the util shows the correct info for reaching  AD.

All my desktops were able to rejoin the domain and can see each other. 

root@Tower:~# net ads info
LDAP server: 192.168.0.4
LDAP server name: closet.pimmmmmer.local
Workgroup: PIMmmmMER0
Realm: PIMmmmMER.LOCAL
Bind Path: dc=PIMmmmMER,dc=LOCAL
LDAP port: 389
Server time: Fri, 02 May 2025 18:45:18 PDT
KDC server: 192.168.0.4
Server time offset: 0
Last machine account password change: Wed, 31 Dec 1969 16:00:00 PST

 

[global]
domain master = no
preferred master = no
local master = no

idmap config * : backend = tdb
idmap config * : range = 1000-7999      
idmap config PIMMER0 : backend = rid
idmap config PIMMER0 : range = 10000-4000000000

 

added to extra config 

 

I am not sure what else to try 

Thanks , john