devalias

Members
  • Posts

    8
  • Joined

  • Last visited

Everything posted by devalias

  1. 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?
  2. This had a bunch of things to update, but still seem to be getting issues unfortunately. Perhaps mine is something different. For those not 100% what to do: I SSH'd into my unraid server (can probably use the 'console' in the webUI if it works for you) Got the hash of the running container: docker ps | grep jackett Got a shell in that container: docker exec -it 756ff4e65268 bash Downloaded the CA bundle as above: wget https://curl.haxx.se/ca/cacert.pem Weirdly, it wouldn't work like this, so had to rename with .crt: mv cacert.pem cacert.crt Then I could import as above: cert-sync --user cacert.crt This gave me a whole pile of output as it imported the new certificates. When I ran it again, this is what the output looks like if it had nothing to update: root@756ff4e65268:/tmp# cert-sync --user cacert.crt Mono Certificate Store Sync - version 5.14.0.177 Populate Mono certificate store from a concatenated list of certificates. Copyright 2002, 2003 Motus Technologies. Copyright 2004-2008 Novell. BSD licensed. Importing into legacy user store: I already trust 132, your new list has 132 Import process completed. Importing into BTLS user store: I already trust 132, your new list has 132 Import process completed. I restarted the Jackett container to make sure it was using the updated certificates, but I still see a bunch of errors in my logs, and the tests fail: at Jackett.Server.Middleware.CustomExceptionHandler+<Invoke>d__3.MoveNext () [0x0008a] in <01c04986aa9e4ce994ffbe35ff12148b>:0 Jackett.Common.IndexerException: Exception (eztv): No route to host ---> System.Net.Http.HttpRequestException: An error occurred while sending the request ---> System.Net.WebException: Error: ConnectFailure (No route to host) ---> System.Net.Sockets.SocketException: No route to host
  3. It may have been mentioned previously, but I don't quite feel like skimming 72 pages.. I was wondering, what is the canonical/best way to create new plugin XML for a dockerised application? I'm a contributor on an open source project, and want to make things easy and nice to install it, but keep coming up blank on how exactly to go about that.. Is there a guide or similar I am missing? Or a feature of this that allows generating? Or..?
  4. Just because it might help save future users some time, I had to log on to my unraid box and run ifconfig to check which interface had the IP. Using the unraid 'rackmount' box, the interface I had to configure was called bond0
  5. Didn't read the entire thread to see if it was mentioned before, but it would be useful to include the template repo in the original post. I only managed to find it after some digging around. https://github.com/linuxserver/docker-templates
  6. Same issue with 6.0.1 Jul 20 23:32:21 Dalekanium php: /usr/local/emhttp/plugins/dynamix.docker.manager/event/started;/usr/local/emhttp/plugins/dynamix.docker.manager/dockerupdate.php Jul 20 23:32:21 Dalekanium php: Starting Docker... Jul 20 23:32:21 Dalekanium kernel: BTRFS info (device loop0): disk space caching is enabled Jul 20 23:32:21 Dalekanium kernel: BTRFS: has skinny extents Jul 20 23:32:21 Dalekanium logger: Resize '/var/lib/docker' of 'max' Jul 20 23:32:21 Dalekanium logger: starting docker ... Jul 20 23:32:21 Dalekanium kernel: BTRFS: new size for /dev/loop0 is 10737418240 Jul 20 23:32:39 Dalekanium php: Updating templates... Updating info... Jul 20 23:32:39 Dalekanium php: Warning: stream_socket_client(): unable to connect to unix:///var/run/docker.sock (No such file or directory) in /usr/local/emhttp/plugins/dynamix.docker.manager/dockerClient.php on line 505 Jul 20 23:32:39 Dalekanium php: Couldn't create socket: [2] No such file or directory Done. Edit: After reading https://lime-technology.com/forum/index.php?topic=36430.0 I removed my docker.img and let it create a new one, seems like it might be working now (but need to reinstall images)
  7. Firstly, I just wanted to say nice work on the deluge+vpn container, almost exactly what I was looking for!! I was wondering though.. and I know it's probably kind of a big ask.. but would you possibly be inclined to make a similar transmission+vpn container? I would hope it wouldn't take as long since you probably figured out the kinks/hurdles for the deluge one maybe..?