Apple Time Machine issues (smbd: chdir_current_service: vfs_ChDir(/mnt/user/TimeMachine2) failed: Permission denied)

[devalias]

Just wanted to make a forum post about this, as it's been an issue for me for over a year (since 2022-01-23 seemingly), and every time I looked into it, following all the relevant advice/posts here for TimeMachine issues, I could never get it solved.

 

Today I was looking at my Unraid logs when trying to connect to the TimeMachine SMB share (via macOS' 'Connect to Server'; Cmd+K), and saw a log like this:
 

Dec 31 14:01:32 Foo smbd[28609]: [2023/12/31 14:01:32.856310,  0] ../../source3/smbd/smb2_service.c:168(chdir_current_service)
Dec 31 14:01:32 Foo smbd[28609]:   chdir_current_service: vfs_ChDir(/mnt/user/TimeMachine2) failed: Permission denied. Current token: uid=1000, gid=100, 4 groups: 100 3003 3004 3006

 

This corresponds with Finder failing to connect, and showing the following error:

Quote

There was a problem connecting to the server “SERVERNAME”.
You do not have permission to access this server.

 

Googling for "smbd chdir_current_service failed Permission denied" lead me to this forum thread:

• https://www.truenas.com/community/threads/chdir_current_service-vfs_chdir-mnt-failed-permission-denied.95458/

 

Edit: Here are some more relevant results from that search in case it's useful for others, which all seem to indicate similar `chmod` / `chown` solutions:

• https://github.com/dperson/samba/issues/409#issuecomment-1049512587
• https://forums.freebsd.org/threads/samba413-samba416-chdir_current_service-vfs_chdir-failed-permission-denied-current-token-uid-1003-gid-1003-2-groups-1003-1005.88569/#post-604353

 

Which suggested that it could be a permission error, where even if the correct permissions were set on the specific TimeMachine share, if they weren't set correctly on the parent folders, the user would be unable to switch to the correct directory.

 

They suggested checking the permissions using `getfacl` for each of the folders leading up to the share, which for me, would be:

⇒ getfacl /mnt

⇒ getfacl /mnt/user

⇒ getfacl /mnt/user/TimeMachine2

 

Unfortunately I didn't save the results of this, so can't show it here, but basically my share folder permissions seemed to be messed up:

root@Foo:/mnt# ls -la
total 19
drwxr-xr-x 15 root   root  300 Dec 31 14:18 .
drwxr-xr-x 20 root   root  420 Nov 29 11:32 ..
drwxrwxrwt  2 nobody users  40 Dec 31 09:12 addons
drwxrwxr-x  1 nobody users 214 Dec 31 14:28 cache
drwx------ 18 nobody users 504 Dec 31 14:28 disk1
drwx------ 17 nobody users 488 Dec 31 14:28 disk2
drwx------ 18 nobody users 496 Dec 31 14:28 disk3
drwx------ 25 nobody users 808 Dec 31 14:28 disk4
drwxrwxrwx 14 nobody users 272 Dec 31 14:28 disk5
drwxrwxrwx 14 nobody users 275 Dec 31 14:29 disk6
drwxrwxrwt  2 nobody users  40 Dec 31 09:12 disks
drwxrwxrwt  2 nobody users  40 Dec 31 09:12 remotes
drwxrwxrwt  2 nobody users  40 Dec 31 09:12 rootshare
drwx------  1 nobody users 504 Dec 31 14:29 user
drwx------  1 nobody users 504 Dec 31 14:29 user0

 

We can see there that `disk1`, `disk2`, `disk3`, `disk4`, `user` and `user0` all seem to be missing the full permissions that `disk5`/`disk6`/the other folders here have.

 

In my Unraid web UI, looking at Tools -> Docker Safe New Perms:

 

• http://MY-UNRAID-NAS/Tools/DockerSafeNewPerms

 

Seems to imply that the permissions should be set as follows:

For directories:
  drwxrwxrwx

For read/write files:
  -rw-rw-rw-

For readonly files:
  -r--r--r--

 

I didn't want to use that tool as it seemed like it would make changes to ALL my shares/files, and without being able to see what it was going to do before running it, that seemed like a bit of a 'nuclear' option to me.

 

Though based on that, I decided to try manually fixing the permissions on my disk/share folders by `ssh`ing in to my Unraid server, and then using `chmod` on those top level folders.

 

In the end, I think all I ended up running was the following:

⇒ cd /mnt

⇒ chmod 777 user

⇒ chmod 777 user0

 

Which then somehow seemed to also change the permissions on the other folders that were set weirdly before (or allowed something else to run that then fixed it?):
 

root@Foo:/mnt# ls -la /mnt
total 19
drwxr-xr-x 15 root   root  300 Dec 31 14:53 ./
drwxr-xr-x 20 root   root  420 Nov 29 11:32 ../
drwxrwxrwt  2 nobody users  40 Dec 31 09:12 addons/
drwxrwxrwx  1 nobody users 214 Dec 31 15:03 cache/
drwxrwxrwx 18 nobody users 504 Dec 31 15:03 disk1/
drwxrwxrwx 17 nobody users 488 Dec 31 15:03 disk2/
drwxrwxrwx 18 nobody users 496 Dec 31 15:03 disk3/
drwxrwxrwx 25 nobody users 808 Dec 31 15:03 disk4/
drwxrwxrwx 14 nobody users 272 Dec 31 15:03 disk5/
drwxrwxrwx 13 nobody users 251 Dec 31 15:03 disk6/
drwxrwxrwt  2 nobody users  40 Dec 31 09:12 disks/
drwxrwxrwt  2 nobody users  40 Dec 31 09:12 remotes/
drwxrwxrwt  2 nobody users  40 Dec 31 09:12 rootshare/
drwxrwxrwx  1 nobody users 504 Dec 31 15:03 user/
drwxrwxrwx  1 nobody users 504 Dec 31 15:03 user0/

Sanity Test

As a 'sanity test', I just tried 'undoing' this change to test that it was what fixed it by doing the following:

⇒ chmod 700 /mnt/user

 

Which seems to change all of the  `disk*` and `user*` folders at once.. which was a little unexpected:

root@Foo:/mnt# ls -la
total 19
drwxr-xr-x 15 root   root  300 Dec 31 14:53 ./
drwxr-xr-x 20 root   root  420 Nov 29 11:32 ../
drwxrwxrwt  2 nobody users  40 Dec 31 09:12 addons/
drwx------  1 nobody users 214 Dec 31 15:03 cache/
drwx------ 18 nobody users 504 Dec 31 15:03 disk1/
drwx------ 17 nobody users 488 Dec 31 15:03 disk2/
drwx------ 18 nobody users 496 Dec 31 15:03 disk3/
drwx------ 25 nobody users 808 Dec 31 15:03 disk4/
drwx------ 14 nobody users 272 Dec 31 15:03 disk5/
drwx------ 13 nobody users 251 Dec 31 15:03 disk6/
drwxrwxrwt  2 nobody users  40 Dec 31 09:12 disks/
drwxrwxrwt  2 nobody users  40 Dec 31 09:12 remotes/
drwxrwxrwt  2 nobody users  40 Dec 31 09:12 rootshare/
drwx------  1 nobody users 504 Dec 31 15:03 user/
drwx------  1 nobody users 504 Dec 31 15:03 user0/

 

I then tried connecting to the share via Finder again, and got the same error dialog as before.

 

Then, after fixing it with `chmod` again:

⇒ chmod 777 /mnt/user

root@Foo:/mnt# ls -la
total 19
drwxr-xr-x 15 root   root  300 Dec 31 14:53 ./
drwxr-xr-x 20 root   root  420 Nov 29 11:32 ../
drwxrwxrwt  2 nobody users  40 Dec 31 09:12 addons/
drwxrwxrwx  1 nobody users 214 Dec 31 15:03 cache/
drwxrwxrwx 18 nobody users 504 Dec 31 15:03 disk1/
drwxrwxrwx 17 nobody users 488 Dec 31 15:03 disk2/
drwxrwxrwx 18 nobody users 496 Dec 31 15:03 disk3/
drwxrwxrwx 25 nobody users 808 Dec 31 15:03 disk4/
drwxrwxrwx 14 nobody users 272 Dec 31 15:03 disk5/
drwxrwxrwx 13 nobody users 251 Dec 31 15:03 disk6/
drwxrwxrwt  2 nobody users  40 Dec 31 09:12 disks/
drwxrwxrwt  2 nobody users  40 Dec 31 09:12 remotes/
drwxrwxrwt  2 nobody users  40 Dec 31 09:12 rootshare/
drwxrwxrwx  1 nobody users 504 Dec 31 15:03 user/
drwxrwxrwx  1 nobody users 504 Dec 31 15:03 user0/

 

I can connect via Finder 🎉:

 

Hopefully this is helpful for someone else having Time Machine issues 🖤

 

Saving future headaches

I wonder if this is a check that Unraid could add to the 'Fix Common Problems' plugin?

Edited December 31, 2023 by devalias
add a few more relevant links

[Frank1940]

11 hours ago, devalias said:

As a 'sanity test', I just tried 'undoing' this change to test that it was what fixed it by doing the following:

⇒ chmod 700 /mnt/user

 

 

The same physical disks are used to store both Disk Shares and User Shares.  There is a just a layer of software that assembles into a 'collection' (called a User Share) of the resources for all the contents of the directories in the root directory of each data disk (i.e, Disk Share if you like ) having the name of the User Share.  When you change the permissions of using either the Disk Share or the User Share, you will make that change on those underlying physical disk(s).   (That is one of the reasons why Disk Shares are normally not exported in the GUI as most folks do not understand what problems can occur when one uses both Disk Shares and User Shares in file operations!) 

 

Edited December 31, 2023 by Frank1940