"Failed to monitor paths" behaviour changed

[TroelsWibergJensen]

Hi @jlesage ,
I don't know if this is related to the newest release or if its because of crashplan itself.
But since November release which i pulled yesterday i get many windows with failed to monitor paths. Previously i got only one and could dismiss that. Then move on to login. Now its impossible to get to the login screen. Is that something you can affect?

Of course it would be best to fix the root problem of the crashplan user being able to access the failing paths. But that problem i don't fully understand.

I get this from the service log:

[10.31.22 05:08:55.573 WARN Thread-628 ode42.jna.inotify.InotifyManager] Unable to add watch for path /volume1/NetBackup/DiskStation_0011320383DF/lorem og ipsum/3 lorem og ipsum/Foxtrot V/@eaDir, errno: , 13

but when i ssh as the crashplan user I have no problem cd'ing to that path.

Container has this user set:

Which corresponds to this user
uid=1043(crashplan) gid=100(users) groups=100(users),101(administrators)

Does anyone recognize this problem?

[jlesage]

I confirm the multiple windows issue. This will be fixed.

For the other issue, being able to cd to the path doesn't means that CrashPlan can read the file. Execute ls -l <file> on one of the failed file to verify the owner/permission of the file. It is probably incompatible with the configured user/group.

[TroelsWibergJensen]

Thanks for confirming the multiple window issue :)

I tried to do the ls- l command on one of the files and got this:

$ ls -l \@eaDir/16386857_10154934418928536_5597665846367469425_n.jpg\@SynoEAStream
-rwxrwxrwx 1 rsync users 174 Feb  1  2017 @eaDir/16386857_10154934418928536_5597665846367469425_n.jpg@SynoEAStream

The owner is not the same, but group is, so i thought that would be sufficient. But maybe i'm wrong.
I could even cat the file with my crashplan user, so wouldn't that mean there is something else at play?

[jlesage]

For this file, the log message had the errno 13 ?

[metastatic1]

I'm also experiencing this issue, but with all shared folders. As an example, the following entry was regularly identified in the service.log.0 file relating to the homes shared folder:

Unable to add watch for path /volume1/homes, errno: , 13

The permissions and ownership for the /volume1/homes folder are shown below:

drwxrwxrwx+ 31 root root homes

The other shared folders have the same owner and group. Through testing I have found that if I change the group owner to administrators then the issue clears. However, I'm unsure whether that is a wise idea.

@jlesage What do you advise I do in this instance?

[jlesage]

That's strange, the folder has technically the right permissions to allows everyone to read it. There is probably something specific to Synology that explains the problem.

Are all there shares normally owned by root/root ? I don't have a Synology to play with, so I think you should probably try to seek help from Synology...

[TroelsWibergJensen]

I confirm the multiple windows issue. This will be fixed.

For the other issue, being able to cd to the path doesn't means that CrashPlan can read the file. Execute ls -l <file> on one of the failed file to verify the owner/permission of the file. It is probably incompatible with the configured user/group.

Confirmed that the multiple window issue is fixed. And i have tried to make folder exclusions of the @eadir to avoid further failed paths notification... but i still got one (only one window), but no new entries in the service log. Strange!?