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.

You are likely to get more informed feedback if you attach your system's diagnostics zip file to your next post in this thread.

It is always a good idea to do this to allow us to see the current state of your system and so we can see logs.

It might be worth running a check filesystem on all your drives as file system corruption can cause this sort of issue.

I assume that "Plex TV Shows" is a User Share? If so check that in the Sonarr mapping that /tv which you have mapped to /mnt/user/Plex TV Shows/ has its access set read/write?

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

3 minutes ago, wjmiller said:

Not sure what you are wanting me to check for the mapping.

If you go into the mappings for the sonarr container then check that the access permissions are set to allow read/write for the mapping (you may need to click on the Edit option for that mapping to see). Alternatively posting the docker run command for sonarr will allow us to see it that way instead. Unfortunately nothing about docker container settings are included in the diagnostics so cannot check from there.

Having said that I think that file system level corruption is a more likely suspect although I saw no sign of it in the syslog included in the diagnostics that you posted. To make it easier I have attached a simple script I use with the User Scripts plugin to run xfs_repair against all drives - it is easier than doing them one at a time if you have a lot. It does assume that all drives are in xfs format which does seem to be the case for you?

I must admit though that I am trying to guess at what might be wrong as there is nothing that stands out from your description.

BTW: You seem to have a lot of .cfg files on the flash drives under config/shares for shares that I think no longer exist. Using the Clean Up button on the Shares tab will remove unused ones which will make it easier for anyone looking at the diagnostics.

CheckFilesystems.sh

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.

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

4 hours ago, wjmiller said:

I rebooted the server and it seems that permission issue between the dockers and shares has been resolved.

Did you save the diags before rebooting? Or is it covered by the syslog-previous, i.e., was the previous boot to the current one.

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.

Edited August 2, 2025Aug 2 by wjmiller

OK, in that case, syslog-previous covers the previous boot, the only issue I see is that Windows pool SSD dropped offline, making that filesystem no longer accessible.

Jul 28 11:05:07 ZEUS kernel: ata3: limiting SATA link speed to 3.0 Gbps

Jul 28 11:05:07 ZEUS kernel: ata3.00: limiting speed to UDMA/133:PIO3

Jul 28 11:05:13 ZEUS kernel: ata3: SATA link down (SStatus 0 SControl 320)

Jul 28 11:05:13 ZEUS kernel: ata3.00: disable device

Jul 28 11:05:13 ZEUS kernel: sd 4:0:0:0: rejecting I/O to offline device

Jul 28 11:05:13 ZEUS kernel: ata3.00: detaching (SCSI 4:0:0:0)

Jul 28 11:05:13 ZEUS kernel: XFS (sdb1): Block device removal (0x20) detected at fs_bdev_mark_dead+0x4a/0x60 (fs/xfs/xfs_super.c:1178). Shutting down filesystem.

Replace both cables and try again.