Not sure if it's clear from the above, but the two downloaders share this download directory. I ran a chmod last night and this morning, and two folders in completed had their permissions changed. I've been adding the changes flag (-c) to my chmod runs to see, and there are consistently alot. It should have root:users as the owner (I've chown'd before too) so I've been suspecting transmission is doing something strange. The /Downloads/completed folder has permissions drwxrwsr-x+ TM_Docker:users. The sub folders created by the docker have the issues. 0_Media is drwxrwsrwx+ root:users (set to 777 out of curiosity/desperation), and 0_Media/Downloads is drwxrwsrwx+ (same for desperation). The main parent directories /0_Media and /0_Media/Downloads are the same when working and not working. Except I have not made users the owner of the folder/files, I left it as root:users. Every docker has its own user, but all are apart of a group +default user group. Portainer: In my docker container, i have a -e variable PGID (group) and PUID (user) Use the IDs you made a note of earlier Mount the correct directories on the Volumes tab you wish the container to access, which it sounds like you already have so I wont go into detail (permissions) (user) (group) (size, date etc) (directory)ĭrwxrwxr-x 6 radarr media 4096 May 15 10:36 radarr drwxrwsr-x 6 sabnzbd media 4096 Mar 2 21:41 sabnzbd When you do an 'ls -l' on the directories, it should read: (775 is overkill, but my docker containers are behind a firewall) SSH into OMV as root and fetch group and user IDs (id or id ) and make a note Create the necessary folders on my /srv/disk target and then 'chown user:media folder' (persistent storage volume) Also, chmod 00775 to make sure the created group (media) has permissions on your media folder In OMV, create a group (media) create a user for each container (sabnzbd, sonarr, radarr) Make those users members of the created group (as well as the default users group) What are the differences in an 'ls -l' (lower Letter L) on the directory when it works, and when it doesnt? Has anyone experienced anything like this, or have a guess where the problem is coming from? I'm not very familiar with Unix permissions, but I can't figure why it would be fixed for 24-72 hours only to have it come back later. I have NZBGet using umask 002, sonarr and radarr running chmods in their settings (775), and I've run the above chmods/chgrp in both the /sharedfolders/ and srv/dev-disk-by-label to try to fix the issue. I usually run chmod g+s /directory for the parent directory as well. I can run chgrp -R users /directory and chmod -R g+w /directory for a temporary fix. The shared folder is on a RAID array.Įvery few days, NZBGet starts failing it's unpacks with error code 9: permission denied when trying to create the directory. They all have read/write permission as a user and group in the shared folder. They share a download/media folder which is a set up as a shared folder in OMV. They are using different users, but all with the default group "users". I have sonarr/radarr as well as transmission all running in Docker as well. I keep having permissions issues while unpacking archives using NZBGet in Docker.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |