Hi,
I use Syncthing to sync certain folders from my devices to my home server, a kind of backup.
Unfortunately, the synchronization of the screenshot folder from my android phone doesn’t work and I get the following error message:
I had some similar issues in the past. Could you try to change the whole path from
/storage/emulated/0/DCIM/Camera
to
/sdcard/DCIM/Camera
and then try again? In order to change the path, you can remove and re-add the folder (or just use the Advanced Configuration if you know what you are doing).
That’s interesting, I didn’t know about this directory before.
But my camera-folder is synchronizing fine.
I’ve got only problems with the Screenshot directory.
Edit: I just realized that the error is still there (even with pointing the screenshot sync to /sdcard/DCIM/Camera)
Probably it’s a problem with the Application. I’ll reinstall it and tell you the outcome!
Reinstalling the program didn’t help, the error message still occurs.
But it’s also pretty weird that screenshots witch I take are now synced to the server but not the other way around though on both, server and phone the “Folder Type” is set to “Send & Receive”.
Edit: The phone is a Pixel 5 with an Android AOSP called GrapheneOS. It’s very security hardened and privacy focused which is why I first thought it might have something to do with it.
But why does this problem occure only with /storage/emulated/0/Pictures/Screenshots and not with all the other Syncs under /storage/emulated/ …
Edit 2:
I just noticed, that this means lstat isn’t existing on my phone in general. Is this a bug of the syncthing app?
I don’t think so. I also get the not found error when trying to call lstat like that, but the file watcher works fine regardless.
This may be some kind of a permission issue. The only thing that I can think about right now is that the /sdcard/Camera/DCIM folder seems to exist in Android by default from the very first boot, while the /sdcard/Pictures/Screenshots folder gets created only when you actually take the first screenshot.
I get it working without errors by deleting the F-Droid Syncthing package and installing it from the Play Store.
To be honest I don’t want to play around with it too much until I mess things up again ^^
For those who encounter the same problem:
My Camera pictures are syncing from /storage/emulated/0/DCIM/Camera
And my Screenshots syncing from /storage/emulated/0/Pictures/Screenshot/
Seems, that it was a problem with the F-Droid package …
Interesting. Are you using the official app or the Fork? As far as I know, there is no difference when it comes to the official one, regardless of the source.
I’m currently working on Syncthing-Fork v1.14.x and after compiling SyncthingNative v1.14.0 and putting it into the wrapper, starting the whole thing on my existing Android 11 emulator instance, the same error immediately popped up.
If I run the v1.13.1.1 (containing SyncthingNative v1.13.1 compiled from source), the error is not coming up. I suspect some code change causes this to happen, but maybe it was just an android restriction SyncthingNative did not “see” before and now it does some more extensive checks of the environment / paths?
Interesting, I don’t have the filewatcher error on Android 10. I guess it’s the Android 11 restrictions to blame here, as they limit listing parent paths like /storage/ and /storage/emulated/. The first list-able path is /storage/emulated/[uid]/
Did you recompile now with v1.13.1 to check it isn’t anything else that changed in between?
There’s no changes relating to the filesystem watcher in between v1.13.1 and v1.14.0.
Seems likely to be due to Android 11: In that discussion about the external SD being accessible, info was posted that suggest that now all “native filesystem calls” are routed through androids storage access framework. And that hardly implements inotify. If that’s, I guess the only option is to disable filesystem watching. As far as I recall the app had it’s own watching using android apis and then syncthing’s rest api before filesystem notifications were introduced in Syncthing itself - maybe that can be resurrected.
@imsodin : I’ve now tried fresh setups of all Syncthing(Native) versions beginning from v1.8.x until nowadays on Android 11 emulator and all show the filewatcher error. So it definitely IS Android 11 related. (Did not notice it before, because my physical device is Android 10, sorry for the noise.)
This would be a good idea for Android 11+ users.
Do we have alternatives? Would it be possible to do a “test Syncthing code” which avoid accessing /storage and /storage/emulated but directly try to setup watching from /storage/emulated/0 (going deeper on) or is that technically impossible ?
You can probably run with enough tracing to see exactly where the error originates and comment that out. My guess would be that it’s the part where we resolve the correct casing of the folder root.
2021-03-13 14:28:52 casefs.go:241 basic /storage/emulated/0/DCIM Stat . {0x6272bc20} <nil>
2021-03-13 14:28:52 casefs.go:321 basic /storage/emulated/0/DCIM Watch . Matcher/[]@0x62658190 true lstat /storage/emulated: no such file or directory
2021-03-13 14:28:52 Error while trying to start filesystem watcher for folder "Android Camera" (sdk_gphone_x86_arm_f78t-photos), trying again in 1m0s: lstat /storage/emulated: no such file or directory
Notify (underlying library) also does checks on all path components (resolving symlinks).
I don’t know what to do about android. On the one hand it is used by many (including me), on the other hand it is terrifying: It’s clear now that under certain circumstances android reports that paths are missing, when in fact it’s a permission issue. That will destroy user data (the thing they are so concerned about when it comes to privacy…). Probably one can handle it by having code in the wrapper, that checks that folder roots are accessible. I would hope it behaves sanely if that is the case. @Catfriend1 Do you already do something like that?
@imsodin I do not check from the wrapper if folders are there and accessible as I would then have to go through SAF to do that with the (Android deprecated) absolute paths. Or we would have more of the ugly shell command wrapping which I’ve already used in some places where I’d like to have the same point of view as if I were a native executable but from the wrapper.
It depended on new File() objects. This is what Google also restricted more and more ; it could maybe work together well if we use all files access.
What I dislike in that code is that it was the “battery eater” in the past. Example: back in 2017, I’ve setup a sync folder which points to my internal storage root. I then ignored my messengers database dir as it constantly changed the files and the Syncthing app dir as it contained the logs. With that, my phone got hot and burned the battery through fast because the watch mechanism picked up a messenger db change (as the android code does not respect .stignore), fired the scan via restapi and logged this, then it watched the syncthing log change, fired a scan, and so on. That was btw one main reason to join the Android dev in 2018 because I wanted to get Syncthings internal watcher in which is technically very good.