github-starred/vaultwarden
2
0
Fork 0
mirror of https://github.com/dani-garcia/vaultwarden.git synced 2026-08-27 05:35:03 -05:00
Code Issues 534 Packages Projects Releases 86 Wiki Activity

Synology NAS Set PUID and PGID as Variables #400

New Issue
Closed
opened 2025-11-07 06:35:04 -06:00 by GiteaMirror · 10 comments
GiteaMirror commented 2025-11-07 06:35:04 -06:00
Owner
Copy Link
Copy Source

Originally created by @newkind on GitHub (Sep 5, 2019).

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). 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!
GiteaMirror added the help wanted label 2025-11-07 06:35:04 -06:00
GiteaMirror commented 2025-11-07 06:35:05 -06:00
Author
Owner
Copy Link
Copy Source

@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.

@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.
GiteaMirror commented 2025-11-07 06:35:05 -06:00
Author
Owner
Copy Link
Copy Source

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

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

@mtonnie commented on GitHub (Dec 2, 2019): What about a native package for synology, this would propably support more models than a docker solution.
GiteaMirror commented 2025-11-07 06:35:05 -06:00
Author
Owner
Copy Link
Copy Source

@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?

@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?
GiteaMirror commented 2025-11-07 06:35:06 -06:00
Author
Owner
Copy Link
Copy Source

@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.

@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.
GiteaMirror commented 2025-11-07 06:35:06 -06:00
Author
Owner
Copy Link
Copy Source

@PrivatePuffin 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.

@PrivatePuffin 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.
GiteaMirror commented 2025-11-07 06:35:06 -06:00
Author
Owner
Copy Link
Copy Source

@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

@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
GiteaMirror commented 2025-11-07 06:35:07 -06:00
Author
Owner
Copy Link
Copy Source

@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.

@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.
GiteaMirror commented 2025-11-07 06:35:07 -06:00
Author
Owner
Copy Link
Copy Source

@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

@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
GiteaMirror commented 2025-11-07 06:35:07 -06:00
Author
Owner
Copy Link
Copy Source

@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.

@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.
GiteaMirror commented 2025-11-07 06:35:07 -06:00
Author
Owner
Copy Link
Copy Source

@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
  ...
@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 ... ```
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
better for forum
bug
documentation
duplicate
enhancement
future Vault
good first issue
help wanted
low priority
notes
pull-request
Mirrored from GitHub Pull Request
 question
SSO
Third party
troubleshooting
wontfix
No labels help wanted
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
GiteaMirror ninjasurge (Kaehlen Rog)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/vaultwarden#400