Bug report: Sync ignores Linux group permissions

[Stronginthearm]

I want to sync a folder which has the owner:group root:system and the permissions drwxrwxr-x (775).

I've edited /lib/systemd/system/resilio-sync.service to run sync as user:group rslsync:system.

I've edited /etc/passwd so tha the user rslsync has the group system.

I've made a systemctl daemon-reload and a systemctl restart resilio-sync.

Sync runs but won't write to the folder and says it has no permission.

When I login as user rslsync I can obviously write to the folder because I have sufficient group permissions.

Only when I change the owner of the folder to rslsync Sync can write to that folder.

 

Ubuntu 18.04.2 LTS and Resilio Sync 2.6.3 installed with apt.

[Stronginthearm]

Update on further research:

Changing the permissions to 777 has no effect.

After changing the owner to rslsync and accessing the folder with Sync I can change the owner back to root and Sync can still access the folder. So probably Sync has some kind of internal database where it stores assumed permissions?

[Stronginthearm]

Sooo... nobody cares?

[Timbo]

I don't know if this is a Resilio or Linux issue, as I run into problems with users not having write permissions despite being in the group on Linux from time to time.

Solution has been to use setfacl and give write access to the Resilio dirs to the user. Easier than changing users, systemd files or using chown over and over.

[stijnos]

The product simply is unstable and development has stopped.

[Augur]

On 7/18/2019 at 7:45 PM, Stronginthearm said:

Sooo... nobody cares?

Hi,

same issue. Any ideas about this here? I chengaed the owner of the files to the user Sync is running (with netgear it is user "admin") restartet sync and then changed the owner back. The sync is fine again but like to see this solved.

Cheers,

Nils

[Jason26]

In my testing, I was hoping that the mode bits would get synced, but they appear not to which is unfortunate.  Syncthing and Seafile to appear to sync the mode bits though.

[momm_momm]

Same here. Still present ind 2.7.0.1366-1.

Copy of my Bugreport:

 

Dear Support,

with my to resilio-sync_2.7.0.1366-1_amd64, rslsync introduced two new problems:

Issue 1:

It stopped to honor linux group permissions, reporting countless "cannot update timestamp" problems on files with absolutely proper permissions that had no issues with previous version.

###

passwd
rslsync:x:AAA:BBB:Bittorrent Sync:/home/btsync:/bin/false

###

group
rslsync:x:BBB:userA,userB,rslsync

###

cat /etc/systemd/system/resilio-sync.service
[Unit]
Description=Resilio Sync service
Documentation=http://help.getsync.com/
After=network.target

[Service]
Type=forking
User=rslsync
Group=rslsync
UMask=0002
Restart=no
LimitCORE=infinity
PermissionsStartOnly=true
PIDFile=/var/run/resilio-sync/sync.pid
ExecStartPre=/bin/mkdir -p /var/run/resilio-sync
ExecStartPre=/bin/chown -R rslsync:rslsync /var/run/resilio-sync
ExecStart=/usr/bin/rslsync --config /etc/resilio-sync/config.json
Nice=15

[Install]
WantedBy=multi-user.target

###

ps shows rslsync running on user rslsync

###

Permissions

ls -la /srv/share/ |grep 0000
drwxrwxrwx  1 root    rslsync   182 Apr  3  2018 0000_Testfile

This directory is so blatantly read-writable... but still reports "cannot update timestamp".

The seems to be a linux problem not specific to my machine, I´d therefore prefer to spare the logs.
 

Issue 2:

rslsync stopped recognizing storage folders behind symlinks. Exactly this configuration worked before updating. I only updated the resilio deb file, so no other actions were taken between last running config and update. Also my system restarts resilio on every night and resilio was running prior to updating, so the configuration was not accidentially changed without restarting...

Raw folder:
/disk/ssd/resilio

Link:
/srv/resilio => /disk/ssd/resilio

Config
"storage_path" : "/srv/resilio/"

Good Bughunting - quick fix appreciated.