Permission denied when updating from webGUI

Support
1

Hi,

I manually installed my syncthing linux binaries (version 0.9.4) under /usr/local/bin with permissions 755 and owner root. I guessed this is where they should be. Syncthing is started with my regular user.

I never used the autoupdater from the webGUI until today I wanted to update to 0.9.5. Very nice feature, but it refuses to update because syncthing running under my regular user doesn’t have write permissions to /usr/local/bin.

Which is the best solution here:

  1. Change the binary location to ~/bin or somthing similar with full ownership for my regular user?
  2. Give global write permissions to /usr/local/bin? (I did this to make the update possible, but it doesn’t seem the most secure solution…)
  3. Something else …?

Regards,

psilonux

2

This is my recommendation at least.

3

Okay thx, I moved the binaries on my linux boxes and adjusted my upstart script.

So I suppose running syncthing is all done on a per user basis.

4

At least if the upgrade stuff is supposed to work, yes. If a system wide installation is done (like from a package), the auto-upgrade stuff should be disabled at build time.

5

I know this is old, but I had (and presumably others will have) the same problem. You do not need to give global write permission to /usr/local/bin to allow a regular user to update syncthing. If you set the directory’s GID execute bit to “s” you will allow a group member to update a file in that directory as though they are the root user. The prerequisite is that the directory has root:staff ownership and the syncthing user is a member of the group staff. First, check that /usr/local/bin is owned by user root and group staff -

ls -ld /usr/local/bin
drwxrwxr-x 2 root staff 4.0K Mar 16 15:34 /usr/local/bin/

and that the syncthing executable is owned by user your_uid and group staff:

ls -l /usr/local/bin/syncthing
-rwxr-xr-x 1 stuser staff 8.5M Mar 16 15:34 /usr/local/bin/syncthing

Then just run sudo chmod 2775 /usr/local/bin/ and syncthing will update automatically.

# sudo chmod 2775 /usr/local/bin/
# ls -ld /usr/local/bin
drwxrwsr-x 2 root staff 4096 mar  5 22:06 /usr/local/bin
#
7

I am grateful for this, but had no success, even after doing as suggested. I fear I must have missed something, and would appreciate any help.

The relevant results on my pi are as follows:

 sudo chmod 2775 /usr/local/bin/
pi@somerset ~ $ ls -ld /usr/local/bin
drwxrwsr-x 3 root staff 4096 Sep 25 14:40 /usr/local/bin
pi@somerset ~ $ ls -ld /usr/local/bin/syncthing 
-rwxr-xr-x 1 pi pi 10132705 Sep 13 09:51 /usr/local/bin/syncthing
pi@somerset ~ $ id
uid=1000(pi) gid=1000(pi) groups=1000(pi),4(adm),20(dialout),24(cdrom),27(sudo),29(audio),44(video),46(plugdev),60(games),100(users),105(netdev),999(input),1002(spi),1003(gpio)
pi@somerset ~ $ 
pi@somerset ~ $ sudo usermod -a -G staff pi
pi@somerset ~ $ ls -ld /usr/local/bin/syncthing 
-rwxr-xr-x 1 pi pi 10132705 Sep 13 09:51 /usr/local/bin/syncthing
pi@somerset ~ $ ls -ld /usr/local/bin
drwxrwsr-x 3 root staff 4096 Sep 25 14:40 /usr/local/bin

Many thanks,

Ben

9

You may need to log out / log in or restart for your group change to take effect. After doing so, you can test the permissions from your normal account. If you are able to create and rename files in /use/local/bin it worked.

Personally I think it’s easier to just keep the binary in ~/bin instead.

1 Like