multra

Folder re-scan stops re-scanning after a day

Recommended Posts

Good day,

I have BTsync installed on 2 devices: Centos7 vm and a remote Synology NAS.

Synchronization works well for about a day at which point Centos7's BTsync just stop re scanning folders. In other words, I make changes to folder structure that need to be synced with Synology NAS but BTysync does not pick those changes up on Centos7 until i restart the service. After restart folder rescan (every 600 seconds) works for another day.

Where can i find logs in Centos7 to determine whats going wrong?

Thank you!

Share this post


Link to post
Share on other sites

multra, could you reproduce it, send us all logs from CentOS7 and mention at which time it Sync stopped detecting changes and which files were added/updated? I created a ticket for you in the support system where you can find the link to upload logs.

Share this post


Link to post
Share on other sites

This is a followup of my research.Thanks Remirus for your help with this issue.

I was getting spammed by errors in sync.log:

"SyncFileEntry: Failed to write attributes for file /mnt/share .... -1"

The reason this was happening is because btsync user was trying to change file attributes (still curious if this is necessary and/or can be disabled) in the mounted share.

My mounted share was mounted using CIFS and according to mount.cifs:

Quote

The core CIFS protocol does not provide unix ownership information or mode for files and directories. Because of this, files and directories will generally appear to be owned by whatever values the uid= or gid= options are set, and will have permissions set to the default file_mode and dir_mode for the mount. Attempting to change these values via chmod/chown will return success but have no effect.

In my case, I was getting "No permission" when attempting to change file permissions in that mount using something like "sudo -u btsync chmod 700"

I even tried mounting the share using a non-root account/group (which I will be sticking with) and adding btsync to that group with above sad results.

The solution was to add "noperm" option like so

//NAS/Share /mnt/share cifs credentials=/root/.secret,noperm,uid=3000,gid=3000,iocharset=utf8 0 0

As per: mount.cifs

Quote

noperm
Client does not do permission checks. This can expose files on this mount to access by other users on the local client system. It is typically only needed when the server supports the CIFS Unix Extensions but the UIDs/GIDs on the client and server system do not match closely enough to allow access by the user doing the mount. Note that this does not affect the normal ACL check on the target machine done by the server software (of the server ACL against the user name provided at mount time).

 

Now it appears to be working well. I am still closely monitoring but I believe this is the answer to the issue.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.