Because of how Docker’s volumes work, passing in two volumes such as the commonly suggested /tv, /movies, and /downloads makes them look like two different file systems, even if they are a single file system outside the container. If you’re wondering why hardlinks aren’t working or why a simple move is taking far longer than it should, this section explains it. The easiest and most important detail is to create unified path definitions across all the containers. This guide is more conceptual in nature while TRaSH's tutorial walks you through the process. Many folks find TRaSH's Hardlink Tutorial helpful and easier to understand than this guide. In a single user setup, this would of course be the one user you’ve chosen. ¶ Ownership and permissions of /configĭon’t forget that your /config volume will also need to have correct ownership and permissions, usually the daemon’s user and that user’s group like sonarr:sonarr and a umask of 022 or 077 so only that user has access. This does make it harder to share with other users, so you may still end up wanting a UMASK of 002 even with this setup. The group no longer really matters, so you’ll probably just use the group named after the user. The UMASK for this is 022 which results in 755 ( drwxr-xr-x) for folders and 644 ( -rw-r-r-) for files. It isn’t as secure and doesn’t follow best practices, but in the end it is easier to understand and implement. ¶ Single user and optional shared groupĪnother popular and arguably easier option is a single, shared user. and the user/group are a little tricky because inside the container, they have a different name. An UMASK of 002 results in 775 ( drwxrwxr-x) for folders and 664 ( -rw-rw-r-) for files. The previous settings should negate these, but you could configure them if you wanted. Sonarr also lets you configure the user, group as well as folder and file permissions. You configure the Docker image to run with -e PUID=123 -e PGID=321 -e UMASK=002. You run Sonarr using hotio/sonarr, you’ve created a sonarr user with uid 123 and a shared group media with gid 321 which the sonarr user is a member of. Perhaps let one system pick the UID/GIDs, then re-use those on the other system, assuming they don’t conflict. If you’re using storage from another system via NFS or CIFS, it will make your life easier if that system also has matching users and group.
![synology docker run as root synology docker run as root](https://shidevil.github.io/assets/images/Blog/Deluge/1.png)
If you ever peak in, you’ll find that username is something like abc, nobody or hotio, but because it uses the UID/GID you pass in, on the outside it looks like the expected user. Many Docker images also take a -e PUID=123 and -e PGID=321 that lets you change the UID/GID used inside to that of an account on the outside.
#Synology docker run as root software#
If you are using existing folders and files, you will need to fix their current ownership and permissions too, but going forward they will be correct because you set each software up right. This will ensure that files and folders created by one can be read and written by the others. Many Docker images accept -e UMASK=002 as an environment variable and some software can be configured with a user, group and umask (NZBGet) or folder/file permission (Sonarr/Radarr), inside the container. For a deeper explanation, try the Arch Linux wiki articles about file permissions and attributes and UMASK. You can restrict permissions even more by denying read from “other”, which would be a umask of 007 for a user per daemon or 077 for a single shared user. A sane alternative to this is a single shared user, which would use 755 and 644 which is a umask of 022. Ideally, each software runs as its own user and they are all part of a shared group with folder permissions set to 775 ( drwxrwxr-x) and files set to 664 ( -rw-rw-r-), which is a umask of 002. ¶ Multiple users and a shared group ¶ Permissions This is easy to say, but not so easy to understand and explain. The idea is that you run each Docker container as its own user, with a shared group and consistent volumes so every container sees the same path layout. This article will not show you specifics about the best Docker setup, but it describes an overview that you can use to make your own setup the best that it can be.
![synology docker run as root synology docker run as root](https://images1.tqwba.com/20201014/phj3ozrqdhd.png)
Note: Many folks find TRaSH's Hardlink Tutorial helpful and easier to understand than this guide. And most of all, ignore most of the Docker image’s path documentation!
#Synology docker run as root download#
Using one volume (so the download folder and library folder are on the same file system) makes hardlinks and instant moves (atomic moves) possible for Sonarr, Radarr, Lidarr and Readarr. Consistent path definitions between all containers that maintains the folder structure. TL DR: An eponymous user per daemon and a shared group with a umask of 002.