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:
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?