What permissions does freefilesync run on?

Question

I have mounted a webdav folder using webdav as described here . For mounting this directory I use the following command:

sudo mount -t davfs -o uid=bruni,gid=users https://serveraddress /home/bruni/mountpoint

However, when trying to sync this folder using freefilesync I get the following error:

Cannot set directory lock for "/path/to/mountpoint".

Cannot write file "/path/to/mountpoint/sync.ffs_lock".

Error Code 13:Permission denied (open)

Please note that this problem is not related to the TLS encryption as it also arises when I do not use https (when I am at office).

Also note that I am able to create files in the mounted directory from the terminal or even nautilus. So my question is, why can't freefilesync and how could I solve the particular problem?

I use Ubuntu 16.04 and Freefilesync 8.2, but I can imagine that this is redundant information.

UPDATE 5/7/2016: Here are the permissions on the top level mount point:

ls -l
drwxr-xr-x 16 bruni users    488 Jun 14 14:19 Infolog

And here on the directory the lock file should be made

ls -l
drwxr-xr-x 16 bruni users 0 May  31 22:07 id54843

id54843 is a directory, deep under Infolog.

Freefilesync is running as bruni

bruni   8448  1.9  0.2 753820 46684 ?        Sl   11:24   1:05 /home/bruni/Downloads/Software/Linux/FreeFileSync/FreeFileSync

I wan't to sync 2way.

Answer 1

+1 : Interesting question.

Freefilesync may require sudo privileges to backup certain files in the volumes it parses. To my knowledge it is not good to preserve rwx oder ownership of files.

If you execute it from cli, the proper syntax is:

$ sudo -i -g bruni /usr/bin/FreeFileSync "${HOME}"/.FreeFileSync/backup-jobref.ffs_batch 2> "${HOME}"/.FreeFileSync/backup-jobref.ffs_log

The above suppose that within FreeFileSync's GUI you have previously defined a batch job and saved it as: "${HOME}"/.FreeFileSync/backup-jobref.ffs_batch.

If however you intend to run the job from an automated script, make sure that the variables you use explicitly or implicitly are known in yr execution environment (cron, udev, ...):

• $HOME
• $DISPLAY
  Don't leave it undefined in your script, include for instance:
  # define local default display and pass it on to any child process
DISPLAY=:0 ; export DISPLAY

DISPLAY=:0 ; export DISPLAY may not suit your use case if you are doing remote admin on a distant volume while executing a remote instance of FreeFileSync. In that case you'll have to define DISPLAY appropriately.

If you don't want to have to enter your sudo password every time yr backup job runs, or if you want it to run unattended, then go to: /etc/sudoers.d/ and sudo-edit the file 10_user or whatever name you choose, with:

%admin yr_host = NOPASSWD: /usr/bin/FreeFileSync

where admin is any user group that contains you and those you authorize to run FreeFileSync with root privileges. Visit man sudoers to learn about the grammar and syntax of sudoers rules.

More details on sudoers are outside OP's scope, but for the sake of being a little more complete, just 2 more comments.

1) RULE PATTERN FOR sudoers

# who where = tags:(as_whom) what
# "who" is either a group or a collection of users
# "where" is a host or a collection of hosts
# "tags" is the permission granted to "what" is being allowed
# "as_whom" specifies under whose guise the cmd(s) are executed;
#   can be a user "user:" or a group ":group" 
#   or a user and group "user:group"
# "what" is a cmd or a collection of cmds

2) WARNING: messing with sudoers may end up with a user either smiling or creating a security black hole or making himself and others unable to access sudo altogether. In the latter case, with this you can still go home in the evening and have yr cake too. Make sure you know what you are doing.

The above tests well for me on a plain vanilla 14.04.4 LTS Desktop, but can be further hardened security wise. Doing so is not terribly complicated, but again it falls outside the scope of this question.
HTH