Skip to content

Creating Users and Obtaining their ID’s

Once you have completed the steps here go back to the main guide you were following.

Creating a User

Navigate into the DSM control panel and open up ‘User’ then click Create.

You can call the user whatever you want, I just keep it simple and use the name of the container I am setting up so it’s nice and clear.

It’s also a good idea to generate a very strong random password for the user, while it will be a very limited account you don’t want to give it an easy to guess password. You will never need this password for what we are doing.

Next we are going to add this new user to the ‘users’ group as we don’t want it having any sort of admin access.

Next up we need to grant the user access to the specific shares required for the container. The screenshot shows what I used for Radarr, just customise this based on the container you are setting up, as a minimum it will require access to the Docker share.

Nothing to change on the User quota settings just click ‘Next’

Our user will not require any application permissions so check the ‘Deny’ button at the top of the screen.

Again we don’t need to set any speed limits for this user so click on ‘Next’

The final screen will just confirm your settings make sure the correct shares are in the ‘Writeable’ list, click on ‘Apply’ and your user has been created.

Obtaining the new users PUID and PGID

Now we have created the new user for your container we need to obtain the PUID and PGID as this is passed through in our container setup.

You will need to SSH into your Diskstation using ‘Putty’ or an equivalent program depending on if you are a Windows or Linux user.

So lets jump into the Control Panel again and enable SSH

Open up Putty, the only thing you need to enter is the IP address of your NAS and select the SSH radio button.

SSH into your Synology to find out your ID’s

Click on open, you will get a prompt asking if you trust the key, if this is the first time you have used SSH, just press OK or accept.

Enter the login information for your admin Synology user account, you will not be able to see the password as you type it, I use a very long one so I just paste it in from my password manager. (right click acts as paste in Putty)

Once logged in type ‘id nameofuser’ without the quotes and the ‘nameofuser’ will be the name of the user you created earlier. This will show the UID (aka PUID) and GID (aka PGID)

In the example screenshot you can see my Radarr user is UID=1030 and GID=100

You have now setup the locked down user account for the specific Docker container you are setting up. You can now go back to the User Guide you were following.

6 Comments

  1. Scott McNabb Scott McNabb

    Thanks for this. I noticed when updating my containers with the new IDs, some seemed to have GUID instead of PGID. Have you noticed this having changed at some point? I left the GUID and added PGID (but made sure both were the new ones).

    • Dr_Frankenstein Dr_Frankenstein

      On some of the original versions of the guides the containers did use GUID but they were all brought in line to PGID and PUID

  2. Scott McNabb Scott McNabb

    Next question. This appears to have broken each containers ability to import episode/track for me.

    e.g. sonarr:
    Couldn’t import episode /downloads/tv/dummyfilename
    System.UnauthorizedAccessException: Access to the path is denied.

    lidarr:
    Lidarr can see but not access downloaded track /downloads/music/dummyfilename
    Likely permissions error.
    19-9-18 17:14:36.5|Warn|ImportApprovedTracks|Couldn’t import track /downloads/music/dummyfilename

    My folder mappings are identical in each docker container:

    sabnzdb:
    docker/sabnzbd /config
    downloads/sabnzbd /downloads

    sonarr:
    docker/sonarr /config
    downloads/sabnzbd /downloads

    Any ideas? All I did was update the PUID and PGID to the new users which have read/write access to the downloads & docker shares.

    • Dr_Frankenstein Dr_Frankenstein

      I die have this initially as well I had to go in via filestation and double check that the permissions had been applied to any subfolders and then everything started working again

      • Scott McNabb Scott McNabb

        I sorted it (i think/hope!) The issue was the permissions sabnzbd was setting for completed downloads. I figured this out as once I had changed the IDs on all containers back to admin, they still couldn’t import the completed downloads that sab had done whilst under the non-admin IDs, which triggered me.

        I updated the sab permissions to 777 (as per https://sabnzbd.org/wiki/advanced/unix-permissions) under sab Settings – Folders – Advanced – Permissions for completed downloads.

        It worked previously as the default ‘private only’ access sab was giving completed downloads was fine as all containers were technically the same user (admin) accessing its own files.

        I’m sure you’re aware just thought I’d put this down for others who change their setup.

        Thanks for the guides! I wouldn’t have started down this road without them.

      • Scott Scott

        Updating the sab permissions did work for sonarr and radarr, and mostly for lidarr which is what I can’t work out.

        lidarr still having issues importing a few completed downloads. About 1 in 10 get the permissions error.

        I tried creating a new generic docker user so that both the sab and lidarr dockers use the same pgid and puid, but still get the same problem, so it seems like a different issue than before.

        Given that sonarr and radarr have no issues, perhaps it’s because lidarr is using the v3 architecture?

        Looking at file station everything is showing with the correct read/write permissions for the docker users that were created.

        For now I’ve had to have lidarr go back to using an admin pgid and puid to get things working.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.