starred/ProxmoxVE
1
0
Fork 0
mirror of https://github.com/community-scripts/ProxmoxVE.git synced 2026-02-05 00:29:55 +03:00
Code Issues 14 Packages Projects Releases 10 Wiki Activity

Warning: Syncthing should not run as a privileged or system user #42

New Issue
Closed
opened 2026-02-04 16:21:37 +03:00 by OVERLORD · 4 comments
OVERLORD commented 2026-02-04 16:21:37 +03:00
Owner
Copy Link

Originally created by @unknownFalleN on GitHub (Nov 13, 2024).

Please verify that you have read and understood the guidelines.

yes

A clear and concise description of the issue.

The LXC Script is started the service as root. Then Syncting give a warning: "Syncthing should not run as a privileged or system user. Please consider using a normal user account."

What settings are you currently utilizing?

Default Settings

Which Linux distribution are you employing?

Debian 12

If relevant, including screenshots or a code block can be helpful in clarifying the issue.

No response

Please provide detailed steps to reproduce the issue.

  1. start the bash -c "$(wget -qLO - https://github.com/community-scripts/ProxmoxVE/raw/main/ct/syncthing.sh)"
  2. Call webservice Url
Originally created by @unknownFalleN on GitHub (Nov 13, 2024). ### Please verify that you have read and understood the guidelines. yes ### A clear and concise description of the issue. The [LXC Script ](https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/install/syncthing-install.sh) is started the service as root. Then Syncting give a warning: "Syncthing should not run as a privileged or system user. Please consider using a normal user account." ### What settings are you currently utilizing? Default Settings ### Which Linux distribution are you employing? Debian 12 ### If relevant, including screenshots or a code block can be helpful in clarifying the issue. _No response_ ### Please provide detailed steps to reproduce the issue. 1. start the `bash -c "$(wget -qLO - https://github.com/community-scripts/ProxmoxVE/raw/main/ct/syncthing.sh)" ` 2. Call webservice Url
OVERLORD commented 2026-02-04 16:21:43 +03:00
Author
Owner
Copy Link

@thegasta commented on GitHub (Nov 16, 2024):

Keep in mind that syncthing is running inside of the container as user root (uid 0).
Uid 0 of the LXC is mapped as uid 100000 in the host.

So, from what I undestood, this is excpected, you can simply ignore the notification (as I am doing).

@thegasta commented on GitHub (Nov 16, 2024): Keep in mind that syncthing is running inside of the container as user `root` (uid `0`). Uid `0` of the LXC is mapped as uid `100000` in the host. So, from what I undestood, this is excpected, you can simply ignore the notification (as I am doing).
OVERLORD commented 2026-02-04 16:21:45 +03:00
Author
Owner
Copy Link

@aaronblair commented on GitHub (Dec 4, 2024):

To add to this, I believe that the current setup with the root user adds some additional complexity when trying to map the root user to a host user through a bind mount. I don't believe you can map 0->1000, for example.

I'd really like to know how others are mounting local user files to the syncthing container (NFS, etc).

What is the objection to running this with something like syncthing:syncthing?

@aaronblair commented on GitHub (Dec 4, 2024): To add to this, I believe that the current setup with the root user adds some additional complexity when trying to map the root user to a host user through a bind mount. I don't believe you can map 0->1000, for example. I'd really like to know how others are mounting local user files to the syncthing container (NFS, etc). What is the objection to running this with something like syncthing:syncthing?
OVERLORD commented 2026-02-04 16:21:48 +03:00
Author
Owner
Copy Link

@pawilli commented on GitHub (Aug 14, 2025):

To add to this, I believe that the current setup with the root user adds some additional complexity when trying to map the root user to a host user through a bind mount. I don't believe you can map 0->1000, for example.

I'd really like to know how others are mounting local user files to the syncthing container (NFS, etc).

What is the objection to running this with something like syncthing:syncthing?

I had the same issue and I am replying to this thread to provide a solution for others who might run into this same problem.

Run the script and let it finish. Then go into the console of the newly created lxc and run these commands.

# stop the service
   systemctl stop syncthing@root.service
 
# create user and follow the prompts
   adduser syncthing
 
 
 # Change directory to the new home directory    
    cd /home/syncthing
 
 # create new configuration directory in the new home directory
    mkdir .local
    mkdir .local/state 
 
 # move the configuration from the root home folder to this folder
    mv ~/.local/state/syncthing .local/state
 
# change ownership of the directory to the local user
   sudo chown -R syncthing:syncthing .local

# make new default directory 
# note you will have to delete the default directory and create a new defaut using this path once you start the GUI
   mkdir Sync
  chown -R syncthing:syncthing Sync

# change ownership one more time to make sure the permissions are valid - may not be necessary but better to be sure.
   chown -R syncthing:syncthing /home/syncthing

# test the new configuration
   systemctl start syncthing@syncthing

# everything should work now with a non-root user.

# make sure the correct user starts the service after reboot.
   systemctl enable syncthing@syncthing.service

Reboot

#Once it reboot you should be running syncthing using the new account.
#Don't forget to delete the default folder (which points to /root/Sync and replace it with a new default folder pointing to #/home/syncthing/Sync
#You should be good to go.

Hopefully, those who know more than me can incorporate these commands into the script.

Thank you all

@pawilli commented on GitHub (Aug 14, 2025): > To add to this, I believe that the current setup with the root user adds some additional complexity when trying to map the root user to a host user through a bind mount. I don't believe you can map 0->1000, for example. > > I'd really like to know how others are mounting local user files to the syncthing container (NFS, etc). > > What is the objection to running this with something like syncthing:syncthing? I had the same issue and I am replying to this thread to provide a solution for others who might run into this same problem. Run the script and let it finish. Then go into the console of the newly created lxc and run these commands. ``` # stop the service systemctl stop syncthing@root.service # create user and follow the prompts adduser syncthing # Change directory to the new home directory cd /home/syncthing # create new configuration directory in the new home directory mkdir .local mkdir .local/state # move the configuration from the root home folder to this folder mv ~/.local/state/syncthing .local/state # change ownership of the directory to the local user sudo chown -R syncthing:syncthing .local # make new default directory # note you will have to delete the default directory and create a new defaut using this path once you start the GUI mkdir Sync chown -R syncthing:syncthing Sync # change ownership one more time to make sure the permissions are valid - may not be necessary but better to be sure. chown -R syncthing:syncthing /home/syncthing # test the new configuration systemctl start syncthing@syncthing # everything should work now with a non-root user. # make sure the correct user starts the service after reboot. systemctl enable syncthing@syncthing.service ``` `Reboot` #Once it reboot you should be running syncthing using the new account. #Don't forget to delete the default folder (which points to /root/Sync and replace it with a new default folder pointing to #/home/syncthing/Sync #You should be good to go. Hopefully, those who know more than me can incorporate these commands into the script. Thank you all
OVERLORD commented 2026-02-04 16:21:48 +03:00
Author
Owner
Copy Link

@aaronblair commented on GitHub (Aug 14, 2025):

I think this is a good solution for the immediate issue of Syncthing running as a root user, but it doesn't resolve the bigger issues of simplifying bind mounting host folders or other setups. I found that doing things like this really messed up the permissions. In the end, I found it easier to make my own containers and skip the scripts. A bit of a shame and I really like the concept.

@aaronblair commented on GitHub (Aug 14, 2025): I think this is a good solution for the immediate issue of Syncthing running as a root user, but it doesn't resolve the bigger issues of simplifying bind mounting host folders or other setups. I found that doing things like this really messed up the permissions. In the end, I found it easier to make my own containers and skip the scripts. A bit of a shame and I really like the concept.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Implemented in VED waiting push to Main
breaking change
bug
bug
bugfix
deferred
delete script
dependencies
enhancement
external
feature
github
help wanted
in project pipeline
invalid
investigation
json
maintenance
needs triage
new script
new script
nice to have
not a script issue
not planned
organization
pull-request
Mirrored from GitHub Pull Request
 question
refactor
rename script
security
update script
website
wontdo
🛑 Failure to comply with the guidelines
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
OVERLORD
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/ProxmoxVE#42
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?