I would like to allow a certain user who does not own the files in a directory to execute chmod on them. Interactively, I know that I can do this by configuring sudo with the sudoers config file(s), and I can also define an alias like

alias chmod='sudo chmod'

in .bashrc, .profile, or .bash_profile so that the user does not need to type sudo chmod each time anymore. This approach breaks though if chmod is not executed from the command line within a bash shell, but from a program. How could I make this still work?

The background is in setting up Syncthing, which I want to use to synchronize files from different users. Also, syncthing shall not be running as root but as user syncuser. The syncuser user does not have permissions to execute chmod on files it does not own but which it has synced (read/write permissions managed by groups), and this is where it fails.

This situation must occur more frequently. I am pretty much convinced that there is another solution than running syncthing as root, but at the moment I don't see how...

  • 1
    Is setting the setuid flag an option? chmod is probably already owned by root so if you also setuid it, it should be able to do it's magic on all files. A concern would be that this essentially means you're giving root rights to all your users. chmod could be used by normal users to set more binaries as setuid. A nice example would be /bin/sh. I guess you could make a copy of chmod, make that setuid and restrict access to only syncthing.
    – Paul
    Apr 12, 2015 at 18:51
  • The first solution of setting setuid on chmod is not an option for the concern you give. The second one (make a copy, restrict access to the executable) is clever! Syncthing is written in Go and seems to call os.chmod() for executing a chmod. I am wondering if your trick would still work then, but I guess not. If there is no other idea, I'll give it a try anyhow!
    – bdoering
    Apr 12, 2015 at 19:38
  • @Paul that deserves to be an answer. Especially one explaining how the access to the suid copy can be restricted. Clever idea!
    – terdon
    Apr 12, 2015 at 22:32
  • I am not familair with go. But if the program is running as a dedicated user you might be able to change the path settings so the first location will be the suid copy of chmod. Because you can put it in any path this way you can still name it chmod...
    – Paul
    Apr 14, 2015 at 21:26
  • @bdoering If it’s an API, it won’t call chmod at all. Instead, it’ll call chmod() directly.
    – Daniel B
    Apr 16, 2015 at 5:36

3 Answers 3


When I had a similar issue with a completely different background I found chmod was restricted to root. This is by design. My solution was a incron job (inotify) [1] on the folder where the files were stored. The incron (run as root) would chmod all new files to 'user:user' allowing it to be processed further.

[1] http://inotify.aiken.cz/?section=inotify&page=about&lang=en

  • I understand the concept, but it goes against the "synchronizing files concept" where I specifically want to keep user/group and permissions synchronized between different machines.
    – bdoering
    Apr 16, 2015 at 8:18

If you're on a recent enough Linux, you can use the capabilities system to give syncthing the ability to chmod any file. This will also give it some additional abilities like changing extended attributes on files or modifying the access time of any file. See man 7 capabilities for the full list.

To do that, just use setcap "CAP_FOWNER=EP" syncthing. Replace syncthing with the full path to the executable if you're not in the right folder.

  • I hadn't heard of that. Sounds promising! I'll look into it later, thanks!
    – bdoering
    Apr 16, 2015 at 8:20

I ran into the same issue:

[YNQCP] 12:42:21 INFO: Puller: shortcut: chmod /some/file.name: operation not permitted

See also this other earlier question on the more general issue of allowing non-owners to use chmod and chown.

In my case, we have a single computer with multiple users on, all of which have sudo rights. They share a single folder with a number of subfolders that should sync automatically and be available to all. I chmod 777 the main folder and the subfolders, but syncthing still complains and tries to chmod the files for some reason (why?).

I used the hack solution of running syncthing as root. This works fine but produces:

enter image description here

This seems like a better alternative then trying to mess with permissions settings so that syncthing is allowed to chmod files it doesn't own.

An alternative solution is to make a syncthing user and grant it ownership of the files, and have others use them via chmod 777.

Problem also reported elsewhere:

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.