[GH-ISSUE #602] Synology NAS Set PUID and PGID as Variables #402

New issue

Closed

opened 2026-03-03 01:28:46 +03:00 by kerem · 10 comments

kerem commented 2026-03-03 01:28:46 +03:00

Owner

Copy link

Originally created by @newkind on GitHub (Sep 5, 2019).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/602

I'd like to kindly request a feature that would allow Synology NAS users to change the UID and GID as environment variables.

I know that there's a guide in WIKI on how to change the user to non-root but having this possiblity using environment variables would be awesome.

This is exactly the same feature request as it was made in the piHole : https://github.com/pi-hole/docker-pi-hole/issues/328

Thank you!

Originally created by @newkind on GitHub (Sep 5, 2019). Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/602 I'd like to kindly request a feature that would allow Synology NAS users to change the UID and GID as environment variables. I know that there's a guide in WIKI on how to change the user to non-root but having this possiblity using environment variables would be awesome. This is exactly the same feature request as it was made in the piHole : https://github.com/pi-hole/docker-pi-hole/issues/328 Thank you!

kerem 2026-03-03 01:28:46 +03:00

• closed this issue
• added the
  help wanted
  label

kerem commented 2026-03-03 01:28:47 +03:00

Author

Owner

Copy link

@mprasil commented on GitHub (Sep 6, 2019):

Can someone with synology submit a PR they've been able to verify that it works as expected? I can help making sure this does not break stuff on rest of the platforms.

<!-- gh-comment-id:528782924 --> @mprasil commented on GitHub (Sep 6, 2019): Can someone with synology submit a PR they've been able to verify that it works as expected? I can help making sure this does not break stuff on rest of the platforms.

kerem commented 2026-03-03 01:28:47 +03:00

Author

Owner

Copy link

@mtonnie commented on GitHub (Dec 2, 2019):

What about a native package for synology, this would propably support more models than a docker solution.

<!-- gh-comment-id:560411011 --> @mtonnie commented on GitHub (Dec 2, 2019): What about a native package for synology, this would propably support more models than a docker solution.

kerem commented 2026-03-03 01:28:47 +03:00

Author

Owner

Copy link

@aledexter commented on GitHub (Apr 30, 2020):

Can someone with synology submit a PR they've been able to verify that it works as expected? I can help making sure this does not break stuff on rest of the platforms.

What do you mean with PR?

<!-- gh-comment-id:622154768 --> @aledexter commented on GitHub (Apr 30, 2020): > Can someone with synology submit a PR they've been able to verify that it works as expected? I can help making sure this does not break stuff on rest of the platforms. What do you mean with PR?

kerem commented 2026-03-03 01:28:47 +03:00

Author

Owner

Copy link

@BlackDex commented on GitHub (Sep 22, 2020):

Can someone with synology submit a PR they've been able to verify that it works as expected? I can help making sure this does not break stuff on rest of the platforms.

What do you mean with PR?

Since we do not have a Synology to test on, we can't debug and test these changes.
Also, since almost any and all systems work this way, we do not want to break stuff.

So if someone has a fix, they can request to merge/pull that change into the master branch.

<!-- gh-comment-id:696790246 --> @BlackDex commented on GitHub (Sep 22, 2020): > > Can someone with synology submit a PR they've been able to verify that it works as expected? I can help making sure this does not break stuff on rest of the platforms. > > What do you mean with PR? Since we do not have a Synology to test on, we can't debug and test these changes. Also, since almost any and all systems work this way, we do not want to break stuff. So if someone has a fix, they can request to merge/pull that change into the master branch.

kerem commented 2026-03-03 01:28:47 +03:00

Author

Owner

Copy link

@Crow-Control commented on GitHub (Feb 18, 2021):

@newkind maybe file an issue with Synology instead?
Because they thosen to use a non-standard environment var (which is a bad idea) AND choose to use env-vars instead of docker to set permissions in the first place (also not in compliance with any decent docker standard).

It shouldn't be up to every container out there to fix the fuckups by synology imho.

<!-- gh-comment-id:781443493 --> @Crow-Control commented on GitHub (Feb 18, 2021): @newkind maybe file an issue with Synology instead? Because they thosen to use a non-standard environment var (which is a bad idea) AND choose to use env-vars instead of docker to set permissions in the first place (also not in compliance with any decent docker standard). It shouldn't be up to every container out there to fix the fuckups by synology imho.

kerem commented 2026-03-03 01:28:47 +03:00

Author

Owner

Copy link

@7opf commented on GitHub (Feb 19, 2021):

The issue is that the UI from Synology's Docker package doesn't support the --user flag (in addition to some others like --cap-add). Current work around to get this project to run non-root would be to ssh into the NAS and use docker-compose .

# Create a non-privileged service user and add to group (Synology's distribution doesn't have useradd or adduser)
sudo synouser --add bitwardenrs Pa$$w0rd "Bitwarden_rs Docker" 0 "" ""
sudo synogroup --add bitwardenrs bitwardenrs

# Create a directory somewhere to hold your compose file and volume mount
mkdir -p /volume1/docker/bitwardenrs/data
cd /volume1/docker/bitwardenrs

# ensure the service user has access to data dir
sudo chown bitwardenrs:bitwardenrs data
sudo chmod 750 data

# create your docker-compose file
vi docker-compose.yml

Your compose file might look something like this

version: '3.3'
services:
  bitwardenrs:
    image: bitwardenrs/server:latest
    restart: always
    user: 'bitwardenrs:bitwardenrs'
    volumes:
      - '/volume1/docker/bitwardenrs/data/:/data'
    environment:
      ADMIN_TOKEN: <AdminToken> # (if admin UI is desired)
      WEBSOCKET_ENABLED: 'false' # I had to hack around with Synology's moustache templates to get websockets working behind reverse proxy, it's not possible with what Synology exposes through DSM (I'm happy to be proven overwise!). I don't recommend attempting this unless you know what you're doing.
    ports:
      - '8181:80'
    #  - '3012:3012' # normally for websockets
networks: 
  default:
    external:
      name: bridge # Synology docker sets up a network called bridge by default. If you don't specify this, compose will create a new network which also works, but just be aware that you may need to configure your firewall as appopriate.

When you are ready, run compose. You'll see the container will turn up in the UI as well

sudo docker-compose up -d

Disclaimer: I haven't actually tested this yet. Will probably try this week.

Some refs

https://docs.docker.com/compose/compose-file/compose-file-v3/#domainname-hostname-ipc-mac_address-privileged-read_only-shm_size-stdin_open-tty-user-working_dir

https://github.com/dani-garcia/bitwarden_rs/wiki/Using-Docker-Compose

<!-- gh-comment-id:781767589 --> @7opf commented on GitHub (Feb 19, 2021): The issue is that the UI from Synology's Docker package doesn't support the `--user` flag (in addition to some others like `--cap-add`). Current work around to get this project to run non-root would be to ssh into the NAS and use `docker-compose` . ``` # Create a non-privileged service user and add to group (Synology's distribution doesn't have useradd or adduser) sudo synouser --add bitwardenrs Pa$$w0rd "Bitwarden_rs Docker" 0 "" "" sudo synogroup --add bitwardenrs bitwardenrs # Create a directory somewhere to hold your compose file and volume mount mkdir -p /volume1/docker/bitwardenrs/data cd /volume1/docker/bitwardenrs # ensure the service user has access to data dir sudo chown bitwardenrs:bitwardenrs data sudo chmod 750 data # create your docker-compose file vi docker-compose.yml ``` Your compose file might look something like this ``` version: '3.3' services: bitwardenrs: image: bitwardenrs/server:latest restart: always user: 'bitwardenrs:bitwardenrs' volumes: - '/volume1/docker/bitwardenrs/data/:/data' environment: ADMIN_TOKEN: <AdminToken> # (if admin UI is desired) WEBSOCKET_ENABLED: 'false' # I had to hack around with Synology's moustache templates to get websockets working behind reverse proxy, it's not possible with what Synology exposes through DSM (I'm happy to be proven overwise!). I don't recommend attempting this unless you know what you're doing. ports: - '8181:80' # - '3012:3012' # normally for websockets networks: default: external: name: bridge # Synology docker sets up a network called bridge by default. If you don't specify this, compose will create a new network which also works, but just be aware that you may need to configure your firewall as appopriate. ``` When you are ready, run compose. You'll see the container will turn up in the UI as well ``` sudo docker-compose up -d ``` Disclaimer: I haven't actually tested this yet. Will probably try this week. Some refs https://docs.docker.com/compose/compose-file/compose-file-v3/#domainname-hostname-ipc-mac_address-privileged-read_only-shm_size-stdin_open-tty-user-working_dir https://github.com/dani-garcia/bitwarden_rs/wiki/Using-Docker-Compose

kerem commented 2026-03-03 01:28:47 +03:00

Author

Owner

Copy link

@7opf commented on GitHub (Feb 28, 2021):

What ended up working for me on Synology was this:

# get UID and GID of the non-root user on host
sudo synouser --get bitwardenrs
sudo synogroup --get bitwardenrs

version: '3.7'
services:
  bitwardenrs:
    image: bitwardenrs/server:latest
    restart: always
    user: 'UID:GID' # you have to use the IDs (see above), the names won't work as they won't exist inside the container
    volumes:
      - '/volume1/docker/bitwardenrs/data/:/data'
    environment:
      # ADMIN_TOKEN:
      # WEBSOCKET_ENABLED: 'false' # I had to hack around with Synology's moustache templates to get websockets working behind reverse proxy, it's not possible with what Synology exposes through DSM (I'm happy to be proven overwise!). I don't recommend attempting this unless you know what you're doing.
      LOG_FILE: /data/bitwarden.log
      ROCKET_PORT: '8080' # since non-root user is used, rocket cannot run on port 80 (default)
    ports:
      - '8181:8080'
    #  - '3012:3012' # normally for websockets

Docker didn't like re-using the pre-existing network synology sets up so you can let it create one automatically. I didn't need to configure anything special in the firewall for it to work contrary to my prev comment.

<!-- gh-comment-id:787506423 --> @7opf commented on GitHub (Feb 28, 2021): What ended up working for me on Synology was this: ```shell # get UID and GID of the non-root user on host sudo synouser --get bitwardenrs sudo synogroup --get bitwardenrs ``` ```yaml version: '3.7' services: bitwardenrs: image: bitwardenrs/server:latest restart: always user: 'UID:GID' # you have to use the IDs (see above), the names won't work as they won't exist inside the container volumes: - '/volume1/docker/bitwardenrs/data/:/data' environment: # ADMIN_TOKEN: # WEBSOCKET_ENABLED: 'false' # I had to hack around with Synology's moustache templates to get websockets working behind reverse proxy, it's not possible with what Synology exposes through DSM (I'm happy to be proven overwise!). I don't recommend attempting this unless you know what you're doing. LOG_FILE: /data/bitwarden.log ROCKET_PORT: '8080' # since non-root user is used, rocket cannot run on port 80 (default) ports: - '8181:8080' # - '3012:3012' # normally for websockets ``` Docker didn't like re-using the pre-existing network synology sets up so you can let it create one automatically. I didn't need to configure anything special in the firewall for it to work contrary to my prev comment.

kerem commented 2026-03-03 01:28:47 +03:00

Author

Owner

Copy link

@DrDeath commented on GitHub (Apr 18, 2021):

I can confirm, this is working on a synology NAS.

[...]
    user: 'UID:GID' # you have to use the IDs (see above), the names won't work as they won't exist inside the container
[...]
    ROCKET_PORT: '8080' # since non-root user is used, rocket cannot run on port 80 (default)
    ports:
      - '8181:8080'
[...]

Maybe this solution could be inserted into the wiki.

Edit: Already in the Wiki: https://github.com/dani-garcia/bitwarden_rs/wiki/Hardening-Guide

<!-- gh-comment-id:821962005 --> @DrDeath commented on GitHub (Apr 18, 2021): I can confirm, this is working on a synology NAS. ``` [...] user: 'UID:GID' # you have to use the IDs (see above), the names won't work as they won't exist inside the container [...] ROCKET_PORT: '8080' # since non-root user is used, rocket cannot run on port 80 (default) ports: - '8181:8080' [...] ``` Maybe this solution could be inserted into the wiki. Edit: Already in the Wiki: https://github.com/dani-garcia/bitwarden_rs/wiki/Hardening-Guide

kerem commented 2026-03-03 01:28:47 +03:00

Author

Owner

Copy link

@waschinski commented on GitHub (Apr 29, 2021):

I am using portainer on my Synology NAS and don't see any option to set user. So having ENV variables for UID/GID would still be helpful in my use case.

<!-- gh-comment-id:829054741 --> @waschinski commented on GitHub (Apr 29, 2021): I am using portainer on my Synology NAS and don't see any option to set `user`. So having ENV variables for UID/GID would still be helpful in my use case.

kerem commented 2026-03-03 01:28:47 +03:00

Author

Owner

Copy link

@MilesTEG1 commented on GitHub (Jun 26, 2021):

I use docker on a Synology DS920+, and I use PGID and PUID.
Here an extract of my docker-compose.yml (with Portainer, or docker-compose in SSH) :

---
version: "2.4"

services:
  vaultwarden:
    image: vaultwarden/server:latest    # https://github.com/dani-garcia/vaultwarden
                                        # https://github.com/dani-garcia/vaultwarden/wiki
    container_name: vaultwarden
    networks:
      - vaultwarden_network
    environment:
      # Utiliser la commande (en SSH) : id NOM_UTILISATEUR
      - PUID=1000
      - PGID=1000
      - TZ=Europe/Paris
  ...

<!-- gh-comment-id:869045231 --> @MilesTEG1 commented on GitHub (Jun 26, 2021): I use docker on a Synology DS920+, and I use PGID and PUID. Here an extract of my docker-compose.yml (with Portainer, or docker-compose in SSH) : ```yaml --- version: "2.4" services: vaultwarden: image: vaultwarden/server:latest # https://github.com/dani-garcia/vaultwarden # https://github.com/dani-garcia/vaultwarden/wiki container_name: vaultwarden networks: - vaultwarden_network environment: # Utiliser la commande (en SSH) : id NOM_UTILISATEUR - PUID=1000 - PGID=1000 - TZ=Europe/Paris ... ```

kerem referenced this issue 2026-03-03 08:52:48 +03:00

[PR #402] [MERGED] Include git repo in build so we get version #2731

Sign in to join this conversation.

No Branch/Tag specified

Branches Tags

main

revert-7033-patch-1

cached-config-operations

test_dylint

1.35.8

1.35.7

1.35.6

1.35.5

1.35.4

1.35.3

1.35.2

1.35.1

1.35.0

1.34.3

1.34.2

1.34.1

1.34.0

1.33.2

1.33.1

1.33.0

1.32.7

1.32.6

1.32.5

1.32.4

1.32.3

1.32.2

1.32.1

1.32.0

1.31.0

1.30.5

1.30.4

1.30.3

1.30.2

1.30.1

1.30.0

1.29.2

1.29.1

1.29.0

1.28.1

1.28.0

1.27.0

1.26.0

1.25.2

1.25.1

1.25.0

1.24.0

1.23.1

1.23.0

1.22.2

1.22.1

1.22.0

1.21.0

1.20.0

1.19.0

1.18.0

1.17.0

1.16.3

1.16.2

1.16.1

1.16.0

1.15.1

1.15.0

1.14.2

1.14.1

1.14

1.13.1

1.13.0

1.12.0

1.11.0

1.10.0

1.9.1

1.9.0

1.8.0

1.7.0

1.6.1

1.6.0

1.5.0

1.4.0

1.3.0

1.2.0

1.1.0

1.0.0

0.13.0

0.12.0

0.11.0

0.10.0

0.9.0

Labels

Clear labels   

SSO

  

Third party

  

better for forum

  

bug

  

bug

  

documentation

  

duplicate

  

enhancement

  

future Vault

  

future Vault

  

future Vault

  

good first issue

  

help wanted

  

low priority

  

notes

  

pull-request

Mirrored from GitHub Pull Request

  

question

  

troubleshooting

  

wontfix

No labels

SSO

Third party

better for forum

bug

bug

documentation

duplicate

enhancement

future Vault

future Vault

future Vault

good first issue

help wanted

low priority

notes

pull-request

question

troubleshooting

wontfix

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/vaultwarden#402

No description provided.