Synology DS1515+ (DSM 6): Sync can't detect changes?

Marc84
 Share

Recommended Posts

Marc84 New User

Marc84

Posted
Posted

Hello,
I have two Synology NAS
- DS414
- DS214 +
I setup a folder on DS414 read / write copy of the key.
The DS214 + I am sharing with the key.

If I add, modify, delete a file on the DS414 is ok. It is the syncho the DS214 + but if I make a change on the DS214 + => Nothing no syncho on the DS414.

I forget what? what is my mistake?
Thank you for your advice.
(Sorry google translation)

Link to comment
Share on other sites
  • 5 weeks later...
RomanZ Advanced Member

RomanZ

Posted
Posted

@mikedr It is not a bug, but the way how your DSM works. The fact that changes only detected during rescan on your DS214 indicate that notifications are not coming from NAS OS. The most common reasons for non-working notifications are:

1. Files are getting changed on NAS over SMB/Samba below v3, OR files getting changed by AFP.
2. Your NAS runs with Glibc of version 2.3 which does not support file notifications at all.
3. You've got extreme number of folders and files in synced folders and your NAS ran out of inotify handles to track them all.
 

Link to comment
Share on other sites
  • 2 months later...
mhn New User

mhn

Posted
Posted

Just bought Sync Pro and is running into some issues.

NAS: Synology DS1515+

OS: DSM 6.0.2-8451 Update 4

Devices: Mac Client, NAS, Windows Client

Scenario 1: Mac Client make a file change, changes are detected and propagated correctly to the NAS and Windows Client, no issue here.

Scenario 2: Windows Client make a file change, changes are detected and propagated correctly to the NAS and Mac Client, no issue here.

Scenario 3: NAS make a file change via NAS services such as File Station, Cloud Sync, SMB, AFP etc..., changes are NOT detected and are not propagated to Mac Client or Windows Client.

I can decrease the file_rescan_interval, but would prefer an actual fix and not a work around.

Anyone know what's going on here?

Link to comment
Share on other sites
terminalsolutions New User

terminalsolutions

Posted
Posted

I am having almost exactly the same issue. Even when I force a reindex by disconnecting and reconnecting a folder, the files that were changed over AFP or SMB aren't getting caught and pushed out. This is driving me crazy. Any way you can post the solution here or reach out to me? I have a ticket in the system #53429 but the similarity here is striking. @Helen Any chance of filling me in?

Link to comment
Share on other sites
Helen Advanced Member

Helen

Posted
Posted

@terminalsolutions,

there is no need to disconnect/reconnect the share to force indexing. Restarting Sync is enough.
No, downgrading won't help. At least at this moment I cannot confirm it will. 
As far as I can see your ticket is being worked on. Please follow the ticket. 

10 hours ago, terminalsolutions said:

Any insight into how many files would fall under option 3

need to see the logs. The logs you've submitted to support show very little information. Else, you can check notifiers on NAS's terminal -  

cat /proc/sys/fs/inotify/max_user_watches

it will show the number of notify watchers the NAS currently has. But I don't think notifiers is the problem in your case, otherwise files would have got synced after Sync restart or periodic scan.

In @mhn's case the problem was indeed in system notifications. 

Link to comment
Share on other sites
  • 2 weeks later...
Denning New User

Denning

Posted
Posted

Hi there @Helen

I think have exactly the same problem as @terminalsolutions. I have a DS213 where the sync is working perfectly, but on a DS1511+ files which are updated on that NAS do not propagate to other devices until the Sync service is restarted. 

What are the troubleshooting steps I need to go through to check this problem before I log a ticket?

Thanks
 

 

Link to comment
Share on other sites
Helen Advanced Member

Helen

Posted
Posted

Mike, if your NAS uses old C library, notifications won't work there. Check with "/lib/libc.so.6" command when ssh connected.  See what "GNU C Library (EGLIBC) stable release version" it will give? 

Try the 2.4.4 from the helppage. it's recompiled with new libraries.  But if the new libs are not compatible with those on your NAS, Sync will not start. in this case you can download the x64 (or x86) package and switch to that - it's still using the old libs. 

Link to comment
Share on other sites
  • 5 months later...
diamondsw New User

diamondsw

Posted
Posted

Running into this exact same issue with a Synology DS1817+ and DSM 6.1.1-15101 Update 4, and Resilio Sync Pro 2.4.5 (903). None of the causes above apply, yet changes are not being detected and synced out. Only on restarting Sync does it see any changes. Like others, incoming changes have no problem; this is Sync not getting filesystem change notifications.

On 9/20/2016 at 6:01 AM, RomanZ said:

@mikedr It is not a bug, but the way how your DSM works. The fact that changes only detected during rescan on your DS214 indicate that notifications are not coming from NAS OS. The most common reasons for non-working notifications are:

1. Files are getting changed on NAS over SMB/Samba below v3, OR files getting changed by AFP.
2. Your NAS runs with Glibc of version 2.3 which does not support file notifications at all.
3. You've got extreme number of folders and files in synced folders and your NAS ran out of inotify handles to track them all.
 

  1. I'm moving files directly via 'mv' on an SSH session. As direct as it gets.
  2. '/lib/libc.so.6' yields 'GNU C Library (crosstool-NG 1.20.0) stable release version 2.20-2014.11'. So just 17 versions past 2.3.
  3. I have a several dozen small text files in Sync. A horribly underpowered Drobo 5N never broke a sweat.

Meanwhile, Transmission manages to detect file changes immediately and load torrents from its watch folder. Sync does not see changes right under its nose. This is a Sync bug, and extremely aggravating.

Link to comment
Share on other sites
Helen Advanced Member

Helen

Posted
Posted

notification did not work.  Please send the logs to support to verify, or you can grep the logs yourself, you shall see something like that (taken from my recent test of your case - moving file on ssh session):  

SyncFolderNotify: SyncFolderNotify: "file.txt", event = "IN_MOVED_TO"

Log file is /usr/local/resiliosync/var/sync.log

Link to comment
Share on other sites
diamondsw New User

diamondsw

Posted
Posted

Here's what I did:

  1. Stopped Resilio Sync.
  2. Rotated /usr/local/resiliosync/var/sync.log (which had grown to 66MB in a couple days).
  3. Started Resilio Sync, and allowed it to discover peers.
  4. Created a test file via 'touch /volume1/Apps/Sync/General/test-file' (General is one of my synced folders). Confirmed nothing appeared on other hosts.
  5. Stopped Resilio Sync. Made a copy of the log (attached as 'sync-1.log'); rotated logfile.
  6. Started Resilio Sync, allowed it to discover peers and transfer the test file, which is does on initial launch.
  7. Stopped Resilio Sync. Made a copy of the log (attached as 'sync-2.log'); rotated logfile.
  8. Verified ACL/permission access: 
jochs@Synology ~ $ sudo synoacltool -get-perm /volume1/Apps/Sync/General/ rslsync
ACL version: 1 
Archive: is_inherit,is_support_ACL 
Owner: [jochs(user)] 
--------------------- 
	 [0] user:jochs:allow:rwxpdDaARWc--:fd--  (level:2)
	 [1] user:rslsync:allow:rwxpdDaARWc--:fd--  (level:2)
	 [2] user:guest:allow:rwxpdDaARWc--:fd--  (level:2)
	 [3] user:admin:allow:rwxpdDaARWc--:fd--  (level:2)
	 [4] user:transmission:allow:rwxpdDaARWc--:fd--  (level:2)
==================================================== 
User/Group: [rslsync/users,administrators,sc-download,rslsync]

Final permission: [rwxpdDaARWc--]

 

The first time Sync sees the test file is in 'sync-2.log', line 1744 (i.e., only after starting fresh and scanning its folders). I can provide whatever additional logs, details, and tests are needed.

 

 

Link to comment
Share on other sites
diamondsw New User

diamondsw

Posted
Posted (edited)

I assume you're referring to x64 at https://help.getsync.com/hc/en-us/articles/206664850-Synology (nothing on the page refers to glibc version or dependencies). If so, that's what I already have installed. Or is there a reason to install a chip-specific version (for instance, the DS1817+ is based on an Intel Atom C2538, i.e. avoton)?

EDIT: Swapping in the "Avoton" file for the original "x64" file appears to have done the trick. I originally went straight to x64 since I knew it was a 64-bit Intel platform, and the various chip names meant nothing to me at the time.

Edited by diamondsw
Link to comment
Share on other sites
SueSHon New User

SueSHon

Posted
Posted

Thank you, I have a 1517+ and downloading the avoton file instead of the x64 did the trick. I have a DS1517+ synchronized with a DS216j. Added files to the DS216j immediately pushed to the DS1517+, but not the other way round.

I was beginning to look for a BTRFS problem maybe blocking notifications.... but no!

Link to comment
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.

×
 Share
Go to topic listing