wjmiller

Umm, if I am following correctly… the diags from the second post in the thread would be pre restart (though it’s been several days) and the diags from my post yesterday were after I got the server back up. I did not grab fresh ones before rebooting.

So my desktop support days should have kicked in... I rebooted the server and it seems that permission issue between the dockers and shares has been resolved. BUT The reboot did not go according to plan. The server locked up and I ended up driving an hour to it and there was nothing not the screen when I hooked up a monitor. Usually you can see where it hangs, it was blank this time. I had issues a couple years back with the server hanging on boot and in the end what seemed to solve the problem was replacing the flash device. Could a corrupt flash drive be a possible common denominator for these issues? If so, what is killing these drives? I even spent a little extra for some metal Samsung flash drives hoping that would be a good quality with good thermal handling. They tend to get a little warm it seems. Another thing that has historically gummed things up was the UPS serial connection to the server - not sure if that could be an issue either. I also checked the file system on all of the xfs drives and they all passed "no filesystem corruption detected" zeus-diagnostics-20250801-1911.zip

Thank you. Yeah the shares are set to read/write in the docker mappings. Also reflected in the docker run (below) docker run -d --name='Sonarr-20251' --net='bridge' --pids-limit 2048 -e TZ="America/Los_Angeles" -e HOST_OS="Unraid" -e HOST_HOSTNAME="ZEUS" -e HOST_CONTAINERNAME="Sonarr-20251" -e 'PUID'='99' -e 'PGID'='100' -e 'UMASK'='022' -l net.unraid.docker.managed=dockerman -l net.unraid.docker.webui='http://[IP]:[PORT:8989]' -l net.unraid.docker.icon=' -p '8989:8989/tcp' -v '/mnt/user/Plex TV Shows/':'/tv':'rw' -v '/mnt/downloads/Downloads/Downloads - Complete/':'/complete':'rw' -v '/mnt/cache/appdata/sonarr':'/config':'rw' 'lscr.io/linuxserver/sonarr:develop' 461b2b25936e54035486a135606baaecbe6ce1089b016acf781bf3226198dbd1 All disks are xfs except 2 pool devices which are btrfs. I have cleaned up the shares, thanks for the tip. There are still a lot of buttons in Unraid I have yet to tinker with or look up. I will try the script when I get a chance, I take it the script still needs the array to be in maintenance mode? @itimpi I appreciate your time looking into this... it's been driving me nuts. When I updated to 7.1.4 the first attempt failed and I had to restore the flash from backup. The server was purring like a kitten for years until this.

Diagnostics are attached. I can look into running the check filesystem - the server is remote and I would rather be local when taking the array offline to put it in maintenance mode. And yes that is a user share... Not sure what you are wanting me to check for the mapping. Here is the result from checking the user permissions on the shares: root@ZEUS:~# ls -al /mnt/user/ total 84 drwxrwxrwx 1 nobody users 33 Jul 31 20:28 ./ drwxr-xr-x 36 root root 720 Jul 28 23:18 ../ drwxrwxrwx 1 nobody users 164 Jul 21 00:02 Back-ups/ drwxrwxrwx 1 nobody users 0 Mar 27 21:15 Domains/ drwxrwxrwx 1 nobody users 114 Sep 10 2024 Downloads/ drwxrwxrwx 1 nobody users 213 Jul 28 11:05 Nextcloud/ drwxrwxrwx 1 nobody users 88 Sep 22 2024 Pictures/ drwxrwxrwx 1 nobody users 16384 Feb 15 20:46 Plex\ Audiobooks/ drwxrwxrwx 1 nobody users 65536 Jul 29 17:52 Plex\ Movies/ drwxrwxrwx 1 nobody users 12288 Jul 26 23:20 Plex\ TV\ Shows/ drwxrwxrwx 1 nobody users 4096 Jul 13 2022 Pre-Rolls/ drwxrwxrwx 1 nobody users 34 Feb 19 21:48 Staging/ drwxrwxrwx 1 nobody users 492 Jul 31 19:29 appdata/ drwxrwxrwx 1 nobody users 218 Jul 28 19:56 isos/ drwxrwxrwx 1 nobody users 26 Sep 8 2024 system/ root@ZEUS:~# ls -al /mnt/user/Plex\ TV\ Shows/ | head -n 10 total 784 drwxrwxrwx 1 nobody users 4096 Apr 19 2024 #Cybersleuths\ -\ The\ Idaho\ Murders\ (2024)/ zeus-diagnostics-20250731-2028.zip

I am unable to write files to shares. I believe my paths are good - they worked before I had to restore my flash from backup. I think I have narrowed the issue down to permissions - but I do not know where I am supposed to change the permissions. I have tried actions in the user directory, I have tried the new permissions tool for disk and shares. I have tried the docker safe new perms tool. I have rebuilt containers, checked the GUID/PUID in the containers. Everything I have checked shows the owner being 'nobody' and permissions to be drwxrwxrwx. One container I rebuilt - Sonarr - when attempting to add the root share for the data path gives an error message of "Unable to add root folder - Folder '/tv/' is not writable by user 'nobody'" The container path is /tv with the data path being /mnt/user/Plex TV Shows/ Please tell me there is something I am missing. This is not just a single container with an issue, it's all of my containers that write to shares.

Radarr Not able to move files automatically/manually - Permissions Issues? There is a lot to unpack... but the general behavior/issue being that when downloads complete in Deluge, Radarr see that the file is complete but fails to move the files to the share on the array. This also applies to manual attempts to move the files via the import function. Everything was working before jumping to 7.1.4 Short story long... I finally jumped to 7.1.4 from 6.1.2 - this ended with a corrupt flash device which I restored from my backup and the rest of the sshow aside I got everything back up and running... or so I thought. I am now on 7.1.4 and all dockers and VMs are functioning. The only issue is the transferring of files to the shares. What is also odd is that I can move files from the completed downloads directory to the movies share via Krusader - scan the files in Radarr it finds the newly added file then seemingly deletes the file as it disappears shortly after it appeared. This is to a specific array disk - Krusader cannot complete a move directly to the movies share. This leads me to believe it is a permissions issue but I cannot find the correct place to fix the permissions. Reading through forums and other posts on Reddit where users had similar issues - I have cleaned up the permissions for all disks and shares (aside from appdata) to be owned by 'nobody' and though they were working before the update I also verified I am using the same share paths/naming across my dockers. I have rebuilt docker containers, run the 'new permissions' tool, 'docker safe new perms' tool, checked paths which worked previously. Last manual import attempt - log entry from Radarr: 025-07-29 17:44:42.4|Warn|ImportApprovedMovie|Couldn't import movie /complete/Movie.mkv [v5.26.2.10099] System.IO.IOException: I/O error : '/movies/Movie (2025)/Movie (2025).mkv' at Interop.CheckIo(Error error, String path, Boolean isDirectory, Func`2 errorRewriter) at Microsoft.Win32.SafeHandles.SafeFileHandle.Open(String path, OpenFlags flags, Int32 mode) at Microsoft.Win32.SafeHandles.SafeFileHandle.Open(String fullPath, FileMode mode, FileAccess access, FileShare share, FileOptions options, Int64 preallocationSize) at System.IO.FileSystem.CopyFile(String sourceFullPath, String destFullPath, Boolean overwrite) at NzbDrone.Mono.Disk.DiskProvider.TransferFilePatched(String source, String destination, Boolean overwrite, Boolean move) in ./Radarr.Mono/Disk/DiskProvider.cs:line 356 at NzbDrone.Common.Disk.DiskProviderBase.CopyFile(String source, String destination, Boolean overwrite) in ./Radarr.Common/Disk/DiskProviderBase.cs:line 256 at NzbDrone.Common.Disk.DiskTransferService.TryCopyFileVerified(String sourcePath, String targetPath, Int64 originalSize) in ./Radarr.Common/Disk/DiskTransferService.cs:line 483 at NzbDrone.Common.Disk.DiskTransferService.TransferFile(String sourcePath, String targetPath, TransferMode mode, Boolean overwrite) in ./Radarr.Common/Disk/DiskTransferService.cs:line 296 at NzbDrone.Core.MediaFiles.MovieFileMovingService.TransferFile(MovieFile movieFile, Movie movie, String destinationFilePath, TransferMode mode, LocalMovie localMovie) in ./Radarr.Core/MediaFiles/MovieFileMovingService.cs:line 159 at NzbDrone.Core.MediaFiles.UpgradeMediaFileService.UpgradeMovieFile(MovieFile movieFile, LocalMovie localMovie, Boolean copyOnly) in ./Radarr.Core/MediaFiles/UpgradeMediaFileService.cs:line 38 at NzbDrone.Core.MediaFiles.MovieImport.ImportApprovedMovie.Import(List`1 decisions, Boolean newDownload, DownloadClientItem downloadClientItem, ImportMode importMode) in ./Radarr.Core/MediaFiles/MovieImport/ImportApprovedMovie.cs:line 136 Here is the terminal result from "ls -al /mnt/user0/": drwxrwxrwx 1 nobody users 164 Jul 21 00:02 Back-ups/ drwxrwxrwx 1 nobody users 213 Jul 28 11:05 Nextcloud/ drwxrwxrwx 1 nobody users 16384 Feb 15 20:46 Plex\ Audiobooks/ drwxrwxrwx 1 nobody users 65536 Jul 29 04:48 Plex\ Movies/ drwxrwxrwx 1 nobody users 12288 Jul 26 23:20 Plex\ TV\ Shows/ root@ZEUS:~# ls -al /mnt/user0/Plex\ Audiobooks/ total 52 drwxrwxrwx 1 nobody users 16384 Feb 15 20:46 ./ drwxrwxrwx 1 nobody users 33 Jul 28 23:53 ../ drwxrwxrwx 1 nobody users 127 Apr 29 2023 Andy\ Weir/ drwxrwxrwx 1 nobody users 142 Nov 2 2021 Anthony\ Bourdain/ docker run -d --name='Radarr-2025' --net='bridge' --pids-limit 2048 -e TZ="America/Los_Angeles" -e HOST_OS="Unraid" -e HOST_HOSTNAME="ZEUS" -e HOST_CONTAINERNAME="Radarr-2025" -e 'PUID'='99' -e 'PGID'='100' -l net.unraid.docker.managed=dockerman -l net.unraid.docker.webui='http://[IP]:[PORT:7878]' -l net.unraid.docker.icon='' -p '7878:7878/tcp' -v '/mnt/downloads/Downloads/Downloads - Complete/':'/complete':'rw' -v '/mnt/user/Plex Movies/':'/movies':'rw' -v '/mnt/cache/appdata/radarr':'/config':'rw' 'linuxserver/radarr'