Hi Everyone,

Thank you for any help in advance. sorry for the redactions and removals of some of the information in the screenshots. im not sure if its absolutely necessary for me to do so, but id rather error on the side of caution.

Here is some info that might help knowing to help troubleshoot:
net ads testjoin

version="7.2.3"

6.12.54-Unraid

16:28:52 up 1 day, 8:05, 0 users, load average: 4.57, 4.76, 4.66

Version 4.23.4

Version 4.23.4

Ping to winbindd succeeded

checking the trust secret for domain MTSEYMOUR via RPC calls succeeded

Workgroup: MTSEYMOUR

Realm: MTSEYMOUR.CA

Bind Path: dc=MTSEYMOUR,dc=CA

LDAP port: 389

Server time: Mon, 16 Mar 2026 16:28:52 PDT

KDC server: 192.168.1.4

Server time offset: 0

Join is OK

root@Tower:/var/log/samba#

I have recently had some issues with shares breaking. I initially noticed this because I use uptimekuma to keep track of my services. My ping on my unraid server is fine, but port 445 check with TCP to check the shares has been going up and down. I Keep seeing this:



But even when its down sometimes I can still reach my shares.

I am not at all a unraid or slackware expert so I use AI to help me figure some things out. Im hoping to get some real-person advice here above all else (especially above AI advice!@)

I should mention this is an active directory joined unraid.

In my syslogs I see this error over and over again, with differeht share names:

Mar 16 09:50:50 Tower smbd[2008201]: chdir_current_service: vfs_ChDir(/mnt/user/SHARENAME) failed: Permission denied. Current token: uid=12192, gid=10515, 7 groups: 12192 10515 13699 13698 3003 3004 3005 Mar 16 09:50:50 Tower smbd[2008201]: [2026/03/16 09:50:50.237822, 0] ../../source3/smbd/smb2_service.c:117(chdir_current_service)

and i see these errors with a few other shares as well.

AI had me run the following to help me diagnose the issue:

root@Tower:/var/log# grep -A 5 -i idmap /etc/samba/smb.conf

root@Tower:/var/log# testparm -s 2>/dev/null | grep -i idmap

net conf list 2>/dev/null | grep -i idmap

idmap cache time = 300

idmap config mtseymour : range = 10000-999999

idmap config mtseymour : backend = rid

idmap config * : range = 3000-7999

idmap config * : backend = tdb

root@Tower:/var/log#

AI had me do some checks. It had me check my processes and how long they have been running:

(a few were skipped between screenshots)

and then it had me check if "idmap cache has a stale or inconsistent entry, or winbind is being queried with a local UID and can't map it back to a SID cleanly under load."

and also had me check if Samba/Winbind credential caching timeout issue.

ps aux | grep smbd | wc -l ps aux | grep smbd | head -50
root 2300 0.0 0.0 90696 18096 ? Ss Mar15 0:09 /usr/sbin/smbd -D

root 2304 0.0 0.0 87436 9708 ? S Mar15 0:01 /usr/sbin/smbd -D

root 2305 0.0 0.0 87444 9240 ? S Mar15 0:00 /usr/sbin/smbd -D

root 23760 0.0 0.1 109740 36568 ? S Mar15 0:08 /usr/sbin/smbd -D

root 23861 0.0 0.1 107276 25996 ? S Mar15 0:01 /usr/sbin/smbd -D

root 28268 0.0 0.1 106384 29588 ? S Mar15 0:06 /usr/sbin/smbd -D

root 52889 0.0 0.1 104304 26688 ? S Mar15 0:00 /usr/sbin/smbd -D

root 55057 0.0 0.1 106016 26576 ? S Mar15 0:00 /usr/sbin/smbd -D

root 87360 0.0 0.0 102220 21908 ? S Mar15 0:00 /usr/sbin/smbd -D

REDACTED+ 99808 0.0 0.1 109672 36236 ? S Mar15 0:12 /usr/sbin/smbd -D

root 128488 0.0 0.1 105668 26216 ? S Mar15 0:00 /usr/sbin/smbd -D

root 190327 0.0 0.1 107708 34832 ? S Mar15 0:28 /usr/sbin/smbd -D

root 210907 0.0 0.1 105640 25952 ? S Mar15 0:01 /usr/sbin/smbd -D

root 225143 0.0 0.0 103540 21140 ? S Mar15 0:00 /usr/sbin/smbd -D

root 316348 0.0 0.0 102356 20516 ? S Mar15 0:00 /usr/sbin/smbd -D

root 373229 0.0 0.1 108652 29652 ? S Mar15 0:05 /usr/sbin/smbd -D

root 451515 0.0 0.1 103260 30680 ? S Mar15 0:00 /usr/sbin/smbd -D

root 464390 0.4 0.1 113824 41044 ? S Mar15 7:37 /usr/sbin/smbd -D

root 478361 0.0 0.0 91576 19512 ? S Mar15 0:00 /usr/sbin/smbd -D

root 531334 0.0 0.1 108244 24596 ? S Mar15 0:01 /usr/sbin/smbd -D

root 587352 0.0 0.0 106176 24200 ? S Mar15 0:00 /usr/sbin/smbd -D

root 689694 0.0 0.1 107012 29040 ? S Mar15 0:01 /usr/sbin/smbd -D

root 720181 0.0 0.1 105032 29332 ? S Mar15 0:01 /usr/sbin/smbd -D

root 725216 0.0 0.1 103404 26976 ? S Mar15 0:00 /usr/sbin/smbd -D

root 1050293 0.0 0.0 106992 23368 ? S Mar15 0:00 /usr/sbin/smbd -D

root 1065804 0.0 0.0 105536 22508 ? S Mar15 0:00 /usr/sbin/smbd -D

root 1877069 0.0 0.1 108204 32920 ? S 07:07 0:00 /usr/sbin/smbd -D

root 1888805 0.0 0.0 105472 24284 ? S 07:16 0:00 /usr/sbin/smbd -D

root 1937220 0.0 0.0 92948 19532 ? S 07:55 0:00 /usr/sbin/smbd -D

root 1952025 0.0 0.0 106196 22584 ? S 08:07 0:00 /usr/sbin/smbd -D

root 1954625 0.0 0.0 92956 19860 ? S 08:10 0:00 /usr/sbin/smbd -D

root 1984598 0.0 0.0 105468 21500 ? S 08:34 0:00 /usr/sbin/smbd -D

root 1999888 0.1 0.1 109912 36516 ? S 08:46 0:49 /usr/sbin/smbd -D

root 2007802 0.0 0.1 108276 29996 ? S 08:52 0:16 /usr/sbin/smbd -D

root 2008201 0.0 0.1 106712 26176 ? S 08:53 0:00 /usr/sbin/smbd -D

root 2019064 0.0 0.1 110596 36260 ? S 09:01 0:16 /usr/sbin/smbd -D

root 2055133 0.0 0.1 107576 25164 ? S 09:30 0:00 /usr/sbin/smbd -D

root 2063033 0.0 0.1 108124 28608 ? S 09:37 0:01 /usr/sbin/smbd -D

root 2146597 0.0 0.1 109192 36760 ? S 10:40 0:10 /usr/sbin/smbd -D

root 2165204 0.0 0.0 107520 21528 ? S 10:55 0:00 /usr/sbin/smbd -D

root 2168444 0.0 0.1 108356 24380 ? S 10:57 0:00 /usr/sbin/smbd -D

root 2209221 0.0 0.0 106576 23204 ? S 11:28 0:00 /usr/sbin/smbd -D

root 2216792 0.0 0.1 108720 35252 ? S 11:34 0:06 /usr/sbin/smbd -D

root 2255404 0.0 0.0 106576 22684 ? S 12:04 0:00 /usr/sbin/smbd -D

root 2279780 0.0 0.1 111720 35568 ? S 12:23 0:02 /usr/sbin/smbd -D

root 2309112 0.0 0.0 108256 21352 ? S 12:46 0:00 /usr/sbin/smbd -D

root 2309113 0.0 0.0 105468 11736 ? S 12:46 0:00 /usr/sbin/smbd -D

root 2320308 0.0 0.1 108504 27080 ? S 12:55 0:00 /usr/sbin/smbd -D

root 2390986 0.0 0.1 108628 32964 ? S 13:50 0:00 /usr/sbin/smbd -D

root 2402109 0.0 0.0 108256 22692 ? S 13:58 0:00 /usr/sbin/smbd -D

root@Tower:/var/log#



This is what AI had concluded:

##################ai copy paste starts here######################

Now we have everything we need. The fix is straightforward — you need to add deadtime and a winbind credentials cache timeout to smb-extra.conf, which is the correct place to put persistent custom config on Unraid (it survives reboots, unlike smb.conf which gets regenerated).

A few observations from the full picture first:

• 59 smbd processes but only ~37 active sessions in smbstatus — so there are already ~20 orphaned processes accumulating

• PID 464390 (SOMEUSERNAME from 192.168.1.16) has been running since Mar 15 and has consumed 7 minutes 36 seconds of CPU — that's the heaviest session by far and likely your ReportServer automation

• The ANOTHERUSERNAME user connecting from 172.40.1.135 is coming in from what looks like a different subnet (Starlink/off-site?) — that's worth noting

• No deadtime is set anywhere in smb.conf, confirming idle sessions never expire

The fix — add to /boot/config/smb-extra.conf:

bash

cat >> /boot/config/smb-extra.conf << 'EOF'

# Kill idle smbd processes after 15 minutes of no activity
deadtime = 15

# How long winbind caches credentials (seconds) - reduces DC hammering
winbind cache time = 300

# Ensure winbind refreshes group membership periodically
winbind offline logon = yes

# Prevent runaway smbd process accumulation
max smbd processes = 200
EOF

Then verify it looks right:

bash

cat /boot/config/smb-extra.conf

Then test the config is valid and reload:

bash

testparm -s 2>/dev/null | grep -E "deadtime|winbind cache|max smbd"
/etc/rc.d/rc.samba reload

After the reload, the existing 59 processes will persist until their clients disconnect or hit the new deadtime, but no new orphans will accumulate. Within an hour you should see the count drop significantly, and the intermittent WBC_ERR_DOMAIN_NOT_FOUND errors should stop.

The remaining issue to address separately: the XX user failing on YY/YYYYY is a legitimate missing group membership — if VV should have access, add unraid-YYYYY to that user in Unraid's user management GUI. Same applies to any other shares where the permission denials are expected vs. accidental.

#####################################################

(some things redacted for reasons.)

Now I should note that yesterday I had this exact same issue happen and AI had recommended pretty much the exact same thing. Instead of doing its recommendation I rebooted the server thinking that it would help get rid of the stalled proceesses. Instead I found the issue had not gone away and seen it start again today.

Does what the AI suggest make sense? Will this stop it from intermittently going down every so often?



also, one last thing, when i do a cat log.smbd all i see is this over and over for many different shares.:



i hope to get any help at all with this issue. Any insight at all will be greatly appreciated!

thank you for any help!@ if there are any questions I can answer please ask! IF theres anything else I can add please do let me know!

at that point and level your better of writing your own smb config.

see script here:

that said deadtime while it will help kill dead/stale connections may not be the answer per data shown...

you have some form or kind of tracking that is creating or makeing a conenction to test nad that test is going crazy given the pitures and parts of teh data listed with in...

6 minutes ago, bmartino1 said:

at that point and level your better of writing your own smb config.

see script here:

that said deadtime while it will help kill dead/stale connections may not be the answer per data shown...

you have some form or kind of tracking that is creating or makeing a conenction to test nad that test is going crazy given the pitures and parts of teh data listed with in...

What do you mean by that last part "you have some form or kind of tracking that is creating or makeing a conenction to test nad that test is going crazy"?

could it be the amount of users and shares? There are many users using a few specific shares constantly. Or do you mean it could be something else entirely?

Oh, and thank you so much for the reply (the very quick reply at that!!!!)

Edited March 16Mar 16 by mtseymour

1 hour ago, mtseymour said:

What do you mean by that last part "you have some form or kind of tracking that is creating or makeing a conenction to test nad that test is going crazy"?

could it be the amount of users and shares? There are many users using a few specific shares constantly. Or do you mean it could be something else entirely?

Oh, and thank you so much for the reply (the very quick reply at that!!!!)

the system monitoring may be causing ghost / cashed session to reactive adn given the other data



ps aux | grep smbd | wc -l ps aux | grep smbd | head -50

this looks like smb connections and reconencitons due to whats singed and currently connected to the system.

example:

What your screenshot shows is a very specific Samba failure pattern that happens when an SMB client session still exists but the filesystem permissions or mount state underneath the share has changed.

The repeating error line is the key:

vfs_ChDir(/mnt/user/... )
chdir_current_service: failed: Permission denied.
Current token: uid=12192, gid=10515, 7 groups: ...

That tells us several important things.

What the log actually means

Samba is trying to switch the working directory of an already-connected client session.

Internally Samba does:

chdir("/mnt/user/<share>/<path>")

But the UNIX permissions for the UID/GID token Samba is using no longer allow access.

his happens in Unraid most often when one of these occurs:

Cached SMB sessions after permission changes

Example sequence:

1. Windows client connects to share

2. You run Docker/Unraid tools that change UID/GID

3. Existing SMB session still uses old idmap token

4. Next filesystem access → Permission denied

The Samba session keeps retrying → you get spam like your screenshot.

but this is and assumption. diagnostic file would help.

UID/GID mapping mismatch (possible from your output)

Your idmap configuration:

idmap config mtseymour : backend = rid
idmap config mtseymour : range = 10000-999999

idmap config * : backend = tdb
idmap config * : range = 3000-7999

The log shows:

uid=12192 gid=10515

So Samba generated a mapped domain UID, but the filesystem likely expects nobody:users (99:100) or another fixed mapping.

This mismatch is very common on Unraid when:

• AD/LDAP was previously configured

• idmap changed

• cached tokens still exist
  
  

Run this on Unraid:

smbstatus

Look for:

PID     Username     Group      Machine
-----------------------------------------

and

Service      pid     machine
-----------------------------------------

If you see the same client repeatedly accessing the share → that's your spam source.

Recommend removing all customizations, then reboot to clear the logs and post the diagnostics once the issue happens.

On 3/16/2026 at 6:39 PM, bmartino1 said:

the system monitoring may be causing ghost / cashed session to reactive adn given the other data



ps aux | grep smbd | wc -l ps aux | grep smbd | head -50

this looks like smb connections and reconencitons due to whats singed and currently connected to the system.

example:

What your screenshot shows is a very specific Samba failure pattern that happens when an SMB client session still exists but the filesystem permissions or mount state underneath the share has changed.

The repeating error line is the key:

vfs_ChDir(/mnt/user/... )
chdir_current_service: failed: Permission denied.
Current token: uid=12192, gid=10515, 7 groups: ...

That tells us several important things.

What the log actually means

Samba is trying to switch the working directory of an already-connected client session.

Internally Samba does:

chdir("/mnt/user/<share>/<path>")

But the UNIX permissions for the UID/GID token Samba is using no longer allow access.

his happens in Unraid most often when one of these occurs:

Cached SMB sessions after permission changes

Example sequence:

1. Windows client connects to share

2. You run Docker/Unraid tools that change UID/GID

3. Existing SMB session still uses old idmap token

4. Next filesystem access → Permission denied

The Samba session keeps retrying → you get spam like your screenshot.

but this is and assumption. diagnostic file would help.

UID/GID mapping mismatch (possible from your output)

Your idmap configuration:

idmap config mtseymour : backend = rid
idmap config mtseymour : range = 10000-999999

idmap config * : backend = tdb
idmap config * : range = 3000-7999

The log shows:

uid=12192 gid=10515

So Samba generated a mapped domain UID, but the filesystem likely expects nobody:users (99:100) or another fixed mapping.

This mismatch is very common on Unraid when:

• AD/LDAP was previously configured

• idmap changed

• cached tokens still exist
  
  

Run this on Unraid:

smbstatus

Look for:

PID     Username     Group      Machine
-----------------------------------------

and

Service      pid     machine
-----------------------------------------

If you see the same client repeatedly accessing the share → that's your spam source.

bmartino1:

Thank you very much for your insights and help!

Attached is the diagnostic. The system has been rebooted several times and the problem has re-occurred soon after the reboot. Diagnostics attached.


I ran smbstatus and did not see anything out of the ordinary. I seen a single user logging into several shares from 7 different IPs which is 100% normal and expected. Several other users also logging in from single IPs to their own shares as well as shared shares.

A few other things. Whenever I have a management session open it stops responding every once and a while and I need to refresh. If i have the web console open it will close on me randomly... but ping never times out at all...
after refreshing several times it still times out...

If I try to putty in during this time it times out as well:

After a few minutes it will again respond and I can open a web console again.

It took me 2 tries to get the diagnostics. the first time it got hung up. I should have taken a screenshot on the command it hung up on. I had to close the page and try again. The second attempt worked. Not sure if it was because of the command it was attempting to run or because of the same issue that was causing the managementsmb_status_users_removed.txt page to time out.

For the system monitoring theory with uptime kuma, what might cause that to happen?

I have uptime kuma monitoring the shares using a tcp connection on port 445 and another monitor just pinging the server. Both of these monitors I have been using for at least a few years I think and the file share uptime failure has only recently started to happen. The ping time monitor is always green (only goes down when I need to reboot the server). I cant think of any changes that were made that might cause a change in the monitoring of the file shares.

When I tried running your commands the management window kept closing on me. Very fustrating. Took me many tries just to get the commands to run before the window would close.

root@Tower:~# ps aux | grep smbd | wc -l

46

root@Tower:~#

root@Tower:~# ps aux | grep smbd | head -50

root 2300 0.0 0.0 90696 16132 ? Ss Mar15 0:17 /usr/sbin/smbd -D

root 2304 0.0 0.0 87436 8684 ? S Mar15 0:02 /usr/sbin/smbd -D

root 2305 0.0 0.0 87444 8256 ? S Mar15 0:01 /usr/sbin/smbd -D

root 23760 0.0 0.1 112172 35284 ? S Mar15 0:15 /usr/sbin/smbd -D

root 23861 0.0 0.1 110288 28116 ? S Mar15 0:02 /usr/sbin/smbd -D

root 25371 0.0 0.0 112780 22488 ? S Mar17 0:00 /usr/sbin/smbd -D

rents+ 28268 0.0 0.1 111072 34076 ? S Mar15 0:16 /usr/sbin/smbd -D

root 52889 0.0 0.0 107808 20764 ? S Mar15 0:01 /usr/sbin/smbd -D

root 55057 0.0 0.0 108084 24132 ? S Mar15 0:01 /usr/sbin/smbd -D

root 87360 0.0 0.0 106672 21764 ? S Mar15 0:01 /usr/sbin/smbd -D

root 99808 0.0 0.1 112104 36120 ? S Mar15 0:18 /usr/sbin/smbd -D

root 128488 0.0 0.0 107296 24272 ? S Mar15 0:01 /usr/sbin/smbd -D

root 190327 0.0 0.1 120448 35256 ? S Mar15 1:02 /usr/sbin/smbd -D

root 210907 0.0 0.0 107620 20504 ? S Mar15 0:01 /usr/sbin/smbd -D

root 225143 0.0 0.0 106692 19660 ? S Mar15 0:01 /usr/sbin/smbd -D

root 316348 0.0 0.0 105284 18368 ? S Mar15 0:01 /usr/sbin/smbd -D

root 373229 0.0 0.1 114428 35096 ? S Mar15 0:13 /usr/sbin/smbd -D

root 451515 0.0 0.0 107712 20400 ? S Mar15 0:01 /usr/sbin/smbd -D

root 464390 0.5 0.1 121292 44652 ? S Mar15 21:15 /usr/sbin/smbd -D

root 522708 0.0 0.0 96012 17400 ? S Mar17 0:00 /usr/sbin/smbd -D

root 725216 0.0 0.1 103404 24552 ? S Mar15 0:01 /usr/sbin/smbd -D

root 1050293 0.0 0.0 106992 20940 ? S Mar15 0:01 /usr/sbin/smbd -D

root 1065804 0.0 0.1 109968 27244 ? S Mar15 0:01 /usr/sbin/smbd -D

root 1301116 0.0 0.0 113948 21760 ? S Mar17 0:00 /usr/sbin/smbd -D

root 1708097 0.0 0.1 112772 27048 ? S Mar17 0:00 /usr/sbin/smbd -D

root 1954625 0.0 0.0 92956 17496 ? S Mar16 0:00 /usr/sbin/smbd -D

root 1984598 0.0 0.1 110588 32364 ? S Mar16 0:01 /usr/sbin/smbd -D

root 2165204 0.0 0.0 110592 22024 ? S Mar16 0:00 /usr/sbin/smbd -D

root 2209221 0.0 0.0 106576 21224 ? S Mar16 0:00 /usr/sbin/smbd -D

root 2309112 0.0 0.0 108256 18924 ? S Mar16 0:00 /usr/sbin/smbd -D

root 2309113 0.0 0.0 107292 12168 ? S Mar16 0:00 /usr/sbin/smbd -D

root 2320308 0.0 0.1 110328 25164 ? S Mar16 0:00 /usr/sbin/smbd -D

root 2876642 0.0 0.0 109832 21088 ? S Mar16 0:00 /usr/sbin/smbd -D

root 3177781 0.0 0.0 97104 20216 ? S 02:44 0:00 /usr/sbin/smbd -D

root 3241966 0.0 0.0 112924 21044 ? S 03:00 0:00 /usr/sbin/smbd -D

root 3306383 0.0 0.0 112768 21536 ? S 03:18 0:00 /usr/sbin/smbd -D

root 3386105 0.0 0.0 105192 20272 ? S 03:41 0:00 /usr/sbin/smbd -D

root 3392259 0.0 0.0 4268 2484 pts/0 S+ 03:43 0:00 grep smbd

root 3887882 0.0 0.1 113008 32564 ? S Mar17 0:00 /usr/sbin/smbd -D

root 3954609 0.0 0.0 112456 23932 ? S Mar17 0:00 /usr/sbin/smbd -D

root 4075869 0.0 0.1 115732 35052 ? S Mar17 0:08 /usr/sbin/smbd -D

root 4136288 0.0 0.0 95852 17964 ? S Mar17 0:00 /usr/sbin/smbd -D

root 4148336 0.0 0.1 112988 27240 ? S Mar17 0:00 /usr/sbin/smbd -D

root 4161288 0.0 0.1 112456 29120 ? S Mar17 0:00 /usr/sbin/smbd -D

root 4192413 0.0 0.0 95852 18224 ? S Mar17 0:00 /usr/sbin/smbd -D

root@Tower:~#

ive also added some log files with smb diagnostics (sanitized of user/share names but still readable)

JorgeB: which customizations do you mean? I am in the process of removing all unneeded plugins but it is slow going with the management timing out

tower-diagnostics-20260318-0300.zip

1 hour ago, mtseymour said:

which customizations do you mean?

All the stuff from SMB-extras and the go file, then reboot and post new diags if it still happens using stock settings.

thank you for posting diagnostics. as you clearly edited or added into smb extra to make your winbind ad (not samba defult)

quote:

Here is some info that might help knowing to help troubleshoot:

net ads testjoin

version="7.2.3"

6.12.54-Unraid

16:28:52 up 1 day, 8:05, 0 users, load average: 4.57, 4.76, 4.66

Version 4.23.4

Ping to winbindd succeeded

checking the trust secret for domain MTSEYMOUR via RPC calls succeeded

Workgroup: MTSEYMOUR

Realm: MTSEYMOUR.CA

Bind Path: dc=MTSEYMOUR,dc=CA

LDAP port: 389

Server time: Mon, 16 Mar 2026 16:28:52 PDT

KDC server: 192.168.1.4

Server time offset: 0

Join is OK

per diag and data I'm still at a widnows server ldap issues and posix gid/pid...

Samba/AD identity mapping is working enough to authenticate users, but the underlying Unraid share permissions or ACL expectations do not line up with those mapped IDs/groups.

So the pattern is:

1. user authenticates through AD

2. Samba maps them to a UID/GID via winbind/rid

3. Samba tries to enter /mnt/user/<share>

4. Linux/Unraid permissions on that share deny access

5. Samba logs vfs_ChDir(... ) failed: Permission denied

That is a permissions/ACL/idmap mismatch problem first.

Not a network outage first.
Not a disk error first.
Not a Kuma ping/TCP monitor first.

What I do see that is worth paying attention to:

• a lot of custom plugins

• autotweak

• unassigned.devices

• unassigned.devices.plus

• ipmi

• old/deprecated plugins

• custom Samba AD config

• remote SMB mounts via Unassigned Devices, including failed CIFS mount attempts

That combination is enough that I would not assume “stock Unraid behavior” anymore.

As jorge has mentions to start narowing it down and fixing things would be to remove the custom confiruagation tnd get unriad base stable.

One especially suspicious thing

Unassigned Devices is trying to mount remote SMB shares and some are failing:

Remote Share '//192.168.0.2/test' failed to mount.
CIFS: VFS: cifs_mount failed w/return code = -13

-13 is permission denied.

That is not proof UD is breaking local Samba, but it does reinforce the broader theme:

there are multiple SMB/permissions/authentication layers in play here, and at least one of them is already misaligned.

My read of the likely root cause

Most likely:

AD/winbind/idmap was added or adjusted, but the actual Linux-side share ownership/ACLs on the Unraid filesystem were not fully rebuilt to match the AD-backed access model.

That would explain why:

• multiple users authenticate

• multiple shares fail

• failures happen repeatedly

• the token UIDs/GIDs look like domain-mapped IDs

• the problem appears intermittent from the user side but is actually permission-dependent per share/session

But again asumptions.

So lets double check.

Verify the AD mapping itself

Run:

wbinfo -u | head
wbinfo -g | head
getent passwd 'DOMAINUSER'
getent group 'DOMAINGROUP'

They need to confirm winbind is resolving users/groups consistently.

Check actual permissions on failing shares

For a failing share:

namei -om /mnt/user/"Password Manager"
getfacl /mnt/user/"Password Manager"
ls -ld /mnt/user/"Password Manager"
ls -ld /mnt/disk*/"Password Manager" 2>/dev/null

That will show whether /mnt/user/... and the underlying disk paths actually permit traversal for the mapped AD user/group.

Check whether ACLs exist but are wrong

Because with AD on Unraid, the issue is often not authentication itself but directory execute/traverse bits and ACL inheritance.

Temporarily remove the custom Samba overlay

(this is what jorge is saying...) Not necessarily delete it, but move /boot/config/smb-extra.conf out of the way and test with a simpler config if possible. If the issue vanishes, that confirms the custom ADS layer is central.

Strip plugins down while testing

For the intermittent management access problem, I would especially test with these disabled first:

• autotweak

• unassigned devices / remote SMB automounts

• any plugin modifying nginx/php/webgui behavior

• deprecated plugins still hanging around

This may be muti plugin issues and conflicts...

So there are likely two issuesif not more...:

A. SMB/AD permissions mismatch

causing share access failures

B. WebUI/PHP worker exhaustion

causing management timeout symptoms

#SOLUTIONS###############

*try this for smb extra.

[global]
   workgroup = MTSEYMOUR
   security = ADS
   realm = MTSEYMOUR.CA

   local master = no
   preferred master = no
   domain master = no

   winbind use default domain = yes
   winbind enum users = yes
   winbind enum groups = yes
   winbind nested groups = yes
   winbind refresh tickets = yes

   dedicated keytab file = /etc/krb5.keytab
   kerberos method = secrets and keytab

   idmap config * : backend = tdb
   idmap config * : range = 3000-7999

   idmap config MTSEYMOUR : backend = rid
   idmap config MTSEYMOUR : range = 10000-999999

   winbind cache time = 300
   idmap cache time = 300

No full-file override.
No immutable flag.
No manual [global] duplication elsewhere.
No forced root shares unless there is a very special one-off need.

Remove the override script from startup

I would disable that script completely for now.

If they want a “recovery” script, make it a plain Samba restart script, not a file replacement script.

Example:

#!/bin/bash
logger -t RestartShareServices "Restarting Samba cleanly"
/etc/rc.d/rc.samba restart

But for diagnosis, even that should be manual first.

verify the mapped AD identities

Run these on the box:

wbinfo -u | head -50
wbinfo -g | head -50
getent passwd "some_ad_user"
getent group "Domain Users"

Also for one failing user from the logs:

id "that_user"

We want to confirm the AD user resolves consistently and that the expected domain groups are present.

---

inspect one failing share all the way down

Pick one failing share, like ReportServer or Bulletin-Board, and run:

namei -om /mnt/user/ReportServer
getfacl -p /mnt/user/ReportServer
ls -ld /mnt/user/ReportServer
ls -ld /mnt/disk*/ReportServer 2>/dev/null

This is where the truth will be.

Because Samba is already showing us the mapped token, for example:

uid=11135 gid=10515 groups: 11135 10515 3003 3004 3005

If that token cannot traverse the share path, Linux will deny it no matter how good the AD join is.

What I strongly suspect is wrong

One or more of these is likely true:

• share path ownership is still nobody:users with restrictive mode bits

• execute/traverse bit is missing on a parent directory

• underlying /mnt/diskX/share permissions differ from /mnt/user/share

• ACL inheritance is inconsistent across disks

• some shares were created before AD integration and never re-permissioned for domain groups

That would perfectly match the repeated vfs_ChDir(... Permission denied) messages.

About “correct gids”

With RID idmap, the GIDs are not something you should hand-author into Samba share stanzas. They are generated from the domain SID mapping.

So the right move is:

• keep RID mapping stable

• verify the intended AD group

• grant filesystem permissions/ACLs to that mapped group

Not:

• force group = root

• force user = root

• rewrite smb.conf to pretend the IDs are different

On the WebUI timeouts

That php-fpm max_children warning is worth addressing separately.

It suggests the UI is being starved of PHP workers. That can come from:

• heavy dashboard polling

• plugins

• diagnostics pages

• lots of active tabs/widgets

I would trim plugin load while troubleshooting, especially anything nonessential. The SMB problem is likely independent, but the WebUI timeouts are making the whole situation harder to work on.

This is signs of sytem exhaustion and a potentail memory leak...

review:

and

that go over editing fasctcgi adn openign up the fasct cgi info statu page to see what may be runnign previenting ssh/webui access.