1.7 beta 2 issues with access to file locations from containers (Radarr, Sonarr and NZBget)

Since upgrading to the 1.7 beta (1-2) I’ve been experiencing several frustrating issues with Radarr, Sonarr, and NZBGet that I never encountered on 1.6.

For some reason, Radarr and Sonarr no longer seem to have the correct permissions or access to the mapped folders. They can communicate with NZBGet without any issues, and NZBGet successfully downloads and places the files in the correctly mapped folders. However, when Radarr or Sonarr attempts to import the downloads, they don’t see any files or directories at all, even though I’ve verified that the files and folders are present and ready to be imported.

I’ve reinstalled all the applications multiple times, but I still can’t identify the root cause. I’ve also tried changing user permissions using the recommended commands and tested different PUID/PGID combinations, including 1000:1000 and 1000:0, but nothing has resolved the issue.

At this point, I’m at a loss. The exact same setup worked perfectly and seamlessly under version 1.6, so I’m struggling to understand what changed in 1.7.

Thank you for your patience. We performed additional controlled tests on ZimaOS 1.7.0 and were able to reproduce two different permission-related behaviors.

1. When the completed-download directory was owned by root:root with mode 755, Radarr could see, identify, and read the MKV file, but the Move import failed when Radarr attempted to delete the source file. The Radarr log showed an UnauthorizedAccessException.

2. When the completed-download directory was owned by root:root with mode 700, Radarr could not enter the directory. Manual Import returned an empty list, making it appear as if no files or directories existed.

3. After changing only the affected test directory and file to 1000:1000, while keeping the directory at 755 and the file at 644, the same Move import completed successfully. We also tested an upgrade from ZimaOS 1.6.2 to the final ZimaOS 1.7.0 release. With matching Docker volume mappings and files owned by 1000:1000, Radarr completed the import successfully on both versions.

Your issue may therefore be caused by either:

- The actual ownership and permissions of the completed-download directory;

- A Docker volume-mapping mismatch introduced after the applications were reinstalled.

Both conditions can make Manual Import appear empty, so we need the actual configuration from your system before recommending a permission change. Please do not reinstall the applications again or recursively change the permissions of the entire /DATA directory. Could you please send us the following information?

1. Your exact ZimaOS version, including whether it is Beta 1, Beta 2, or the final 1.7.0 release.

2. Screenshots of the storage/volume mappings for: - NZBGet - Sonarr - Radarr Please include both the host/NAS path and the container path.

3. The PUID and PGID configured for each of the three applications.

4. The output of the following commands, using one affected completed download:

stat -c ‘%n | uid=%u gid=%g mode=%a’ \

/DATA/Downloads \

/DATA/Downloads/completed \ "

/DATA/Downloads/completed/AFFECTED-DOWNLOAD" \

“/DATA/Downloads/completed/AFFECTED-DOWNLOAD/FILE.mkv”

Please replace AFFECTED-DOWNLOAD and FILE.mkv with the actual folder and file names.

5. The relevant Radarr or Sonarr log entries from the failed import. In particular, please check for:

- UnauthorizedAccessException

- Permission denied

- Access to the path is denied

- Folder does not exist

- Import failed

- Couldn’t import

Once we have these details, we can determine whether the issue is caused by directory permissions, Docker volume mappings, or behavior specific to an earlier 1.7 beta build.

Hey Vera, Im on holiday at this moment so it will take me some time to try to get all the information. Before I resume testing. Does it matter if I use ZimaOS v1.7.1-alpha1. I also have a FILES-app issue regarding NTFS external drives. My contact for this issue is Dina.

Thank you for the update. We’re currently working on a fix for the Files app issue, and improvements will be available soon. In the meantime, you can continue using ZimaOS v1.7.1-alpha1 as usual. Wishing you a wonderful holiday!