/e/ Drive stopped syncing since march 2025

Using /e/OS Troubleshooting
,
1

Synchronization of Documents/photos/etc was working fine on my device (FP5, official image), with my Nextcloud instance (31.0.2).

Since around one month, new photos/videos/documents are not pushed to Nextcloud any more.
I hoped it was a bug in 2.8, but upgrade to 2.9 did not help.

I also tried to remove the data of the eDrive app (in Settings): after that, I see that the device downloads a lot of data from Nextcloud, but new photos are still not pushed.

I sometimes have a eDrive notification saying that around 50 files are currently synchronizing, but the number does not change.
I don’t have crash notifications of eDrive.
Some other devices (at least an FP3 with /e/OS 2.8 official) still push photos to the same nextcloud instance.
My nextcloud account does not have any space quota.

How to troubleshoot/workaround?

I’ve had a look at the adb logcat, but only found this kind of errors:


04-05 17:44:38.904 23614 23759 D OwnCloudClient #0: REQUEST PROPFIND /remote.php/dav/files/myuser/Documents/path/to/a/directory/
04-05 17:44:38.968 23614 23759 E ReadFolderRemoteOperation: Synchronized /Documents/path/to/a/directory/: Local file does not exist

And, indeed, it’s a directory I removed (on another synchronized device)

1 Like
2

Browsing adb logcat, I’ve found some stacktraces about invalid characters in some files (downloaded from nextcloud), that could not be stored. Because there was character : in their names. Example stacktrace (I replaced the file path and name)

04-11 09:31:16.605 18877 18966 I DownloadFileRemoteOperation: Download of /Documents/path/to/a:b.md to /storage/emulated/0/Android/data/foundation.e.drive/cache/Documents/path/to/a:b.md: Operation finished with HTTP status code 200 (success)
04-11 09:31:16.608  3768  7746 E MediaProvider: File name contains invalid characters
04-11 09:31:16.610 18877 18966 W FileUtils: java.nio.file.FileSystemException: /storage/emulated/0/Documents/path/to/a:b.md: Operation not permitted
04-11 09:31:16.610 18877 18966 W FileUtils:     at sun.nio.fs.UnixCopyFile.copyFile(UnixCopyFile.java:243)
04-11 09:31:16.610 18877 18966 W FileUtils:     at sun.nio.fs.UnixCopyFile.copy(UnixCopyFile.java:581)
04-11 09:31:16.610 18877 18966 W FileUtils:     at sun.nio.fs.UnixFileSystemProvider.copy(UnixFileSystemProvider.java:253)
04-11 09:31:16.610 18877 18966 W FileUtils:     at java.nio.file.Files.copy(Files.java:1274)
04-11 09:31:16.610 18877 18966 W FileUtils:     at foundation.e.drive.utils.FileUtils.copyFile(FileUtils.kt:93)
04-11 09:31:16.610 18877 18966 W FileUtils:     at foundation.e.drive.synchronization.tasks.DownloadFileOperation.moveTmpFileToRealLocation(DownloadFileOperation.kt:199)
04-11 09:31:16.610 18877 18966 W FileUtils:     at foundation.e.drive.synchronization.tasks.DownloadFileOperation.downloadFile(DownloadFileOperation.kt:164)
04-11 09:31:16.610 18877 18966 W FileUtils:     at foundation.e.drive.synchronization.tasks.DownloadFileOperation.run(DownloadFileOperation.kt:67)
04-11 09:31:16.610 18877 18966 W FileUtils:     at com.owncloud.android.lib.common.operations.RemoteOperation.execute(RemoteOperation.java:207) 
04-11 09:31:16.610 18877 18966 W FileUtils:     at foundation.e.drive.synchronization.SyncTask.runDownload(SyncTask.kt:107)
04-11 09:31:16.610 18877 18966 W FileUtils:     at foundation.e.drive.synchronization.SyncTask.run(SyncTask.kt:56)
04-11 09:31:16.610 18877 18966 W FileUtils:     at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:463)
04-11 09:31:16.610 18877 18966 W FileUtils:     at java.util.concurrent.FutureTask.run(FutureTask.java:264)
04-11 09:31:16.610 18877 18966 W FileUtils:     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1137)
04-11 09:31:16.610 18877 18966 W FileUtils:     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:637)
04-11 09:31:16.610 18877 18966 W FileUtils:     at java.lang.Thread.run(Thread.java:1012)

I’ve renamed those files on nextcloud side, the stacktraces disappeared. I’ve also renamed some photos that had a size of zero bytes (I suspect these were photos I took on my phone, and removed right away: maybe it confused the sync process)
But it did not help resuming synchronization from the device to nextcloud.

Now I see from times to times a notification saying there are ~50 files to sync, and the number counts down very quickly to reach zero (without a significant network activity). I suppose these files are the ones that need to be uploaded, and it probably fails somehow

3

Today I could capture an adb logcat of when I have the sync notification fast coutdown to zero. It was at 13h06.

I pasted the whole logcat of that minute (and previous one) in the link below.
I found the following lines to be most relevant:

04-13 13:06:03.116  1628  3889 E NotificationService: Package enqueue rate is 6.80724. Shedding 0|foundation.e.drive|2003004|null|10106. package=foundation.e.drive
04-13 13:06:07.904  1628 14185 W JobScheduler: Job didn't exist in JobStore: cfd3e39 #u0a106/507 foundation.e.drive/androidx.work.impl.background.systemjob.SystemJobService

And I indeed see frequent occurences of the first line “Package enqueue rate is…”, at other times.
I suppose it’s related the fast countdown, but it does not explain why it’s so fast, and why eDrive does not upload files.

4

I can’t help much, but worker/job scheduling was an issue previously, that thread can give you some commands how to debug further, vincent wrote parts (or most? unsure) of earlier eDrive - [eDrive] worker issue after update (#7740) · Issues · e / Backlog · GitLab

1 Like
5

Many thanks @tcecyk

Here is the result of the command mentioned in gitlab ticket:

04-13 17:03:36.602 19970 20001 I WM-DiagnosticsWrkr: Recently completed work:
04-13 17:03:36.602 19970 20001 I WM-DiagnosticsWrkr: 
04-13 17:03:36.605 19970 20001 I WM-DiagnosticsWrkr:  Id 	 Class Name	 Job Id	 State	 Unique Name	 Tags	
04-13 17:03:36.605 19970 20001 I WM-DiagnosticsWrkr: 71a66a3a-1890-4906-ba24-dde903afa813	 foundation.e.drive.synchronization.SyncWorker	 null	 SUCCEEDED	 syncWorker	 foundation.e.drive.synchronization.SyncWorker,eDrive	
04-13 17:03:36.605 19970 20001 I WM-DiagnosticsWrkr: a4328384-7d2f-4e97-97de-00bde04574ec	 foundation.e.drive.periodicScan.FullScanWorker	 538	 SUCCEEDED	 fullScan	 foundation.e.drive.periodicScan.FullScanWorker,eDrive	
04-13 17:03:36.605 19970 20001 I WM-DiagnosticsWrkr: c11f5c4b-c7a8-44f4-9a39-6ef1602fec84	 foundation.e.drive.periodicScan.ListAppsWorker	 537	 SUCCEEDED	 fullScan	 foundation.e.drive.periodicScan.ListAppsWorker,eDrive	
04-13 17:03:36.605 19970 20001 I WM-DiagnosticsWrkr: Running work:
04-13 17:03:36.605 19970 20001 I WM-DiagnosticsWrkr: 
04-13 17:03:36.606 19970 20001 I WM-DiagnosticsWrkr:  Id 	 Class Name	 Job Id	 State	 Unique Name	 Tags	
04-13 17:03:36.606 19970 20001 I WM-DiagnosticsWrkr: 97194a60-af04-48b6-8393-bafdcf5a89c1	 androidx.work.impl.workers.DiagnosticsWorker	 540	 RUNNING 	 androidx.work.impl.workers.DiagnosticsWorker	
04-13 17:03:36.606 19970 20001 I WM-DiagnosticsWrkr: Enqueued work:
04-13 17:03:36.606 19970 20001 I WM-DiagnosticsWrkr: 
04-13 17:03:36.608 19970 20001 I WM-DiagnosticsWrkr:  Id 	 Class Name	 Job Id	 State	 Unique Name	 Tags	
04-13 17:03:36.608 19970 20001 I WM-DiagnosticsWrkr: 741a779e-9dee-43b8-871e-5442ec81e15c	 foundation.e.drive.periodicScan.PeriodicScanWorker	 532	 ENQUEUED	 periodicScanWork	 foundation.e.drive.periodicScan.PeriodicScanWorker,eDrive	
04-13 17:03:36.608 19970 20001 I WM-DiagnosticsWrkr: b29a7908-b5b4-4305-9619-3dc68503eb55	 foundation.e.drive.account.AccountUserInfoWorker	 533	 ENQUEUED	 AccountUserInfoWorker	 foundation.e.drive.account.AccountUserInfoWorker,eDrive

But maybe I need to wait a bit more to have more logs

6

do you want to get to the root cause or get it over with? if you have backup and the data itself isn’t much of a concern, you could purge eDrives state and see if any state caused the hiccup - backing up it’s current sqlite db beforehand. You can restore it again to debug some more

/data/data/foundation.e.drive/databases/eelo_drive.db

the state is in .schema synced_file_state

7

Having a workaround would already be great.
But I’ve already deleted several times the data of app eDrive. When I do that and reboot my device, I have a notification with a lot of files to sync, it seems to re-download all content from nextcloud (I can see the download bandwidth), which takes a while. But it ends up in the same state: recent photos are not uploaded

1 Like
8

the workaround is the official nextcloud-client?

What “type” is your android webdav account btw: “murena.io” type or “webdav”? it should work with both, but there’s no guarantee the type will not be used at some point for different code flow.

If you’re keen to sort out a bug, I’d recheck open/closed eDrive issues last updated and if any of the latest commits either address the behaviour or read like having introduced it. As in:

  • the quota stuff: is your user account above quota?
  • is your connection being determined to be metered?

For debugging I’d look at accesslog of your nextcloud instance at the same time as eDrive tries to queue uploads. Beyond resetting the state, you could empty your device for yet another sanity check.

9

Thanks for the hints @tcecyk

The webdav account on my device is of type “murena.io”.
My nextcloud account does not have any quota (and there’s plenty of disk space on the nextcloud server)
My connection is currently over WiFi+fiber, and is not considered as metered. In any case, I’ve configured to enable data sync over metered networks, too.

I’ve just seen again a file sync countdown, and could see the nextcloud access logs of that time: there’s no log about my account at this time, which is consistent with the fact that my phone status bar did not show any network activity at that time either. Looks like the error (if any) happens on the device side.

I re-enabled adb diagnostics for eDrive, and got this:

$ adb logcat | grep 'WM-DiagnosticsWrkr'
04-16 15:06:17.902 19905 19971 I WM-DiagnosticsWrkr: Recently completed work:
04-16 15:06:17.902 19905 19971 I WM-DiagnosticsWrkr: 
04-16 15:06:17.915 19905 19971 I WM-DiagnosticsWrkr:  Id 	 Class Name	 Job Id	 State	 Unique Name	 Tags	
04-16 15:06:17.915 19905 19971 I WM-DiagnosticsWrkr: e4cba338-a6e0-4cf0-9595-7c821885ebc4	 foundation.e.drive.periodicScan.FullScanWorker	 null	 FAILED	 fullScan	 foundation.e.drive.periodicScan.FullScanWorker,eDrive	
04-16 15:06:17.915 19905 19971 I WM-DiagnosticsWrkr: 3e839adf-5b20-4ded-b59e-606b87e5df13	 foundation.e.drive.periodicScan.ListAppsWorker	 163	 SUCCEEDED	 fullScan	 foundation.e.drive.periodicScan.ListAppsWorker,eDrive	
04-16 15:06:17.915 19905 19971 I WM-DiagnosticsWrkr: fcb2555f-5baa-47ae-8a06-1de606256b3c	 foundation.e.drive.synchronization.SyncWorker	 null	 SUCCEEDED	 syncWorker	 foundation.e.drive.synchronization.SyncWorker,eDrive	
04-16 15:06:17.915 19905 19971 I WM-DiagnosticsWrkr: 4d2513cb-90ea-4520-b9d7-b9b38f14f029	 foundation.e.drive.periodicScan.ListAppsWorker	 null	 CANCELLED	 	 foundation.e.drive.periodicScan.ListAppsWorker,eDrive	
04-16 15:06:17.915 19905 19971 I WM-DiagnosticsWrkr: 5b0b4c84-ec14-45c9-a53e-9547fe9ea8af	 foundation.e.drive.account.setup.FinishSetupWorker	 12	 SUCCEEDED	 	 foundation.e.drive.account.setup.FinishSetupWorker,eDrive,eDrive-init	
04-16 15:06:17.915 19905 19971 I WM-DiagnosticsWrkr: 90c6119e-1008-4262-8956-71b8e36d6f0e	 foundation.e.drive.account.setup.RootFolderSetupWorker	 null	 SUCCEEDED	 	 foundation.e.drive.account.setup.RootFolderSetupWorker,eDrive,eDrive-init	
04-16 15:06:17.915 19905 19971 I WM-DiagnosticsWrkr: 30f47b05-63be-45e9-a823-00295ca1be28	 foundation.e.drive.account.setup.RootFolderSetupWorker	 null	 SUCCEEDED	 	 foundation.e.drive.account.setup.RootFolderSetupWorker,eDrive,eDrive-init	
04-16 15:06:17.915 19905 19971 I WM-DiagnosticsWrkr: 2cfd77d8-e93a-4cc8-9b47-ef806194916a	 foundation.e.drive.account.setup.RootFolderSetupWorker	 9	 SUCCEEDED	 	 foundation.e.drive.account.setup.RootFolderSetupWorker,eDrive,eDrive-init	
04-16 15:06:17.915 19905 19971 I WM-DiagnosticsWrkr: 985656f9-0e19-4ed7-8534-9c3269382aec	 foundation.e.drive.account.setup.RootFolderSetupWorker	 null	 SUCCEEDED	 	 foundation.e.drive.account.setup.RootFolderSetupWorker,eDrive,eDrive-init	
04-16 15:06:17.915 19905 19971 I WM-DiagnosticsWrkr: ccce7436-3148-43ed-abf0-d7b5df5ef948	 foundation.e.drive.account.setup.RootFolderSetupWorker	 null	 SUCCEEDED	 	 foundation.e.drive.account.setup.RootFolderSetupWorker,eDrive,eDrive-init	
04-16 15:06:17.915 19905 19971 I WM-DiagnosticsWrkr: af665c4b-d412-43f6-a347-4319c4dbadb3	 foundation.e.drive.account.setup.RootFolderSetupWorker	 null	 SUCCEEDED	 	 foundation.e.drive.account.setup.RootFolderSetupWorker,eDrive,eDrive-init	
04-16 15:06:17.915 19905 19971 I WM-DiagnosticsWrkr: d58e98d9-53ed-43b0-9295-427442c4a8ad	 foundation.e.drive.account.setup.RootFolderSetupWorker	 5	 SUCCEEDED	 	 foundation.e.drive.account.setup.RootFolderSetupWorker,eDrive,eDrive-init	
04-16 15:06:17.915 19905 19971 I WM-DiagnosticsWrkr: b85ee7c7-ff4c-47e0-9fc4-cd5820db2a20	 foundation.e.drive.account.setup.RootFolderSetupWorker	 4	 SUCCEEDED	 	 foundation.e.drive.account.setup.RootFolderSetupWorker,eDrive,eDrive-init	
04-16 15:06:17.915 19905 19971 I WM-DiagnosticsWrkr: 4d66e1a9-a169-4d6b-b8a7-bd9890f7216d	 foundation.e.drive.account.setup.RootFolderSetupWorker	 3	 SUCCEEDED	 	 foundation.e.drive.account.setup.RootFolderSetupWorker,eDrive,eDrive-init	
04-16 15:06:17.915 19905 19971 I WM-DiagnosticsWrkr: c7fe71ea-038f-4077-8923-410b9ec298f8	 foundation.e.drive.account.setup.RootFolderSetupWorker	 2	 SUCCEEDED	 	 foundation.e.drive.account.setup.RootFolderSetupWorker,eDrive,eDrive-init	
04-16 15:06:17.915 19905 19971 I WM-DiagnosticsWrkr: 8446e678-f4c2-4cda-975e-8d14435495bc	 foundation.e.drive.account.AccountUserInfoWorker	 0	 SUCCEEDED	 	 foundation.e.drive.account.AccountUserInfoWorker,eDrive,eDrive-init	
04-16 15:06:17.915 19905 19971 I WM-DiagnosticsWrkr: Running work:
04-16 15:06:17.915 19905 19971 I WM-DiagnosticsWrkr: 
04-16 15:06:17.916 19905 19971 I WM-DiagnosticsWrkr:  Id 	 Class Name	 Job Id	 State	 Unique Name	 Tags	
04-16 15:06:17.916 19905 19971 I WM-DiagnosticsWrkr: 5fe7735d-2546-40ee-ac7a-5faaedf2da90	 androidx.work.impl.workers.DiagnosticsWorker	 166	 RUNNING	 	 androidx.work.impl.workers.DiagnosticsWorker	
04-16 15:06:17.916 19905 19971 I WM-DiagnosticsWrkr: Enqueued work:
04-16 15:06:17.916 19905 19971 I WM-DiagnosticsWrkr: 
04-16 15:06:17.917 19905 19971 I WM-DiagnosticsWrkr:  Id 	 Class Name	 Job Id	 State	 Unique Name	 Tags	
04-16 15:06:17.917 19905 19971 I WM-DiagnosticsWrkr: cecfd9bc-5a90-4b92-aaa7-e428492ae861	 foundation.e.drive.periodicScan.PeriodicScanWorker	 160	 ENQUEUED	 periodicScanWork	 foundation.e.drive.periodicScan.PeriodicScanWorker,eDrive	
04-16 15:06:17.917 19905 19971 I WM-DiagnosticsWrkr: d9b78c73-469f-4de3-860a-c51de9d0f118	 foundation.e.drive.account.AccountUserInfoWorker	 161	 ENQUEUED	 AccountUserInfoWorker	 foundation.e.drive.account.AccountUserInfoWorker,eDrive

And, earlier:

04-16 15:02:26.056 19905 19939 I WM-WorkerWrapper: Work [ id=e4cba338-a6e0-4cf0-9595-7c821885ebc4, tags={ foundation.e.drive.periodicScan.FullScanWorker, eDrive } ] was cancelled
04-16 15:02:26.056 19905 19939 I WM-WorkerWrapper: java.util.concurrent.CancellationException: Task was cancelled.
04-16 15:02:26.056 19905 19939 I WM-WorkerWrapper: 	at androidx.work.impl.utils.futures.AbstractFuture.cancellationExceptionWithCause(AbstractFuture.java:1183)
04-16 15:02:26.056 19905 19939 I WM-WorkerWrapper: 	at androidx.work.impl.utils.futures.AbstractFuture.getDoneValue(AbstractFuture.java:513)
04-16 15:02:26.056 19905 19939 I WM-WorkerWrapper: 	at androidx.work.impl.utils.futures.AbstractFuture.get(AbstractFuture.java:474)
04-16 15:02:26.056 19905 19939 I WM-WorkerWrapper: 	at androidx.work.impl.WorkerWrapper$2.run(WorkerWrapper.java:316)
04-16 15:02:26.056 19905 19939 I WM-WorkerWrapper: 	at androidx.work.impl.utils.SerialExecutorImpl$Task.run(SerialExecutorImpl.java:96)
04-16 15:02:26.056 19905 19939 I WM-WorkerWrapper: 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1137)
04-16 15:02:26.056 19905 19939 I WM-WorkerWrapper: 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:637)
04-16 15:02:26.056 19905 19939 I WM-WorkerWrapper: 	at java.lang.Thread.run(Thread.java:1012)

and:

04-16 15:05:41.323 19905 19970 W FullScanWorker: Periodic scan start is not allowed
04-16 15:05:41.325 19905 19939 I WM-WorkerWrapper: Worker result FAILURE for Work [ id=e4cba338-a6e0-4cf0-9595-7c821885ebc4, tags={ foundation.e.drive.periodicScan.FullScanWorker, eDrive } ]
10
  • what happens in logcat if you force the sync as in adb shell am broadcast -a foundation.e.drive.action.FORCE_SCAN --receiver-include-background
  • have you looked at the sqlite db if there’s anything curious in terms of cutoff of what files are synced, which aren’t? there’s a dump db command for (see Readme)
11

Many thanks for the pointer to the valuable README

04-16 17:42:01.017 31676 31747 I WM-WorkerWrapper: Work [ id=83088173-1c32-457e-92f8-ecd48c8126c7, tags={ foundation.e.drive.periodicScan.FullScanWorker, eDrive } ] was cancelled
04-16 17:42:01.017 31676 31747 I WM-WorkerWrapper: java.util.concurrent.CancellationException: Task was cancelled.
04-16 17:42:01.017 31676 31747 I WM-WorkerWrapper:      at androidx.work.impl.utils.futures.AbstractFuture.cancellationExceptionWithCause(AbstractFuture.java:1183)
04-16 17:42:01.017 31676 31747 I WM-WorkerWrapper:      at androidx.work.impl.utils.futures.AbstractFuture.getDoneValue(AbstractFuture.java:513)
04-16 17:42:01.017 31676 31747 I WM-WorkerWrapper:      at androidx.work.impl.utils.futures.AbstractFuture.get(AbstractFuture.java:474)
04-16 17:42:01.017 31676 31747 I WM-WorkerWrapper:      at androidx.work.impl.WorkerWrapper$2.run(WorkerWrapper.java:316)
04-16 17:42:01.017 31676 31747 I WM-WorkerWrapper:      at androidx.work.impl.utils.SerialExecutorImpl$Task.run(SerialExecutorImpl.java:96)
04-16 17:42:01.017 31676 31747 I WM-WorkerWrapper:      at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1137)
04-16 17:42:01.017 31676 31747 I WM-WorkerWrapper:      at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:637)
04-16 17:42:01.017 31676 31747 I WM-WorkerWrapper:      at java.lang.Thread.run(Thread.java:1012)
04-16 17:42:01.032 31676 31865 W FullScanWorker: Periodic scan start is not allowed
04-16 17:42:01.032  1574  8617 D ConnectivityService: requestNetwork for uid/pid:10106/31676 activeRequest: null callbackRequest: 1830 [NetworkRequest [ REQUEST id=1831, [ Capabilities: INTERNET&NOT_RESTRICTED&TRUSTED&NOT_VCN_MANAGED Uid: 10106 RequestorUid: 10106 RequestorPkg: foundation.e.drive UnderlyingNetworks: Null] ]] callback flags: 0 order: 2147483647
04-16 17:42:01.033  1574  2197 D ConnectivityService: NetReassign [1831 : null → 116]
04-16 17:42:01.035  2562  2562 D PhoneSwitcherNetworkRequstListener: got request NetworkRequest [ REQUEST id=1831, [ Capabilities: INTERNET&NOT_RESTRICTED&TRUSTED&NOT_VCN_MANAGED Uid: 10106 RequestorUid: 10106 RequestorPkg: foundation.e.drive UnderlyingNetworks: Null] ]
04-16 17:42:01.035  1574  2187 D WifiNetworkFactory: got request NetworkRequest [ REQUEST id=1831, [ Capabilities: INTERNET&NOT_RESTRICTED&TRUSTED&NOT_VCN_MANAGED Uid: 10106 RequestorUid: 10106 RequestorPkg: foundation.e.drive UnderlyingNetworks: Null] ]
04-16 17:42:01.035  1574  2187 D UntrustedWifiNetworkFactory: got request NetworkRequest [ REQUEST id=1831, [ Capabilities: INTERNET&NOT_RESTRICTED&TRUSTED&NOT_VCN_MANAGED Uid: 10106 RequestorUid: 10106 RequestorPkg: foundation.e.drive UnderlyingNetworks: Null] ]
04-16 17:42:01.036  1574  2187 D OemPaidWifiNetworkFactory: got request NetworkRequest [ REQUEST id=1831, [ Capabilities: INTERNET&NOT_RESTRICTED&TRUSTED&NOT_VCN_MANAGED Uid: 10106 RequestorUid: 10106 RequestorPkg: foundation.e.drive UnderlyingNetworks: Null] ]
04-16 17:42:01.036  1574  2187 D MultiInternetWifiNetworkFactory: got request NetworkRequest [ REQUEST id=1831, [ Capabilities: INTERNET&NOT_RESTRICTED&TRUSTED&NOT_VCN_MANAGED Uid: 10106 RequestorUid: 10106 RequestorPkg: foundation.e.drive UnderlyingNetworks: Null] ]
04-16 17:42:01.037 31676 31750 I WM-WorkerWrapper: Worker result FAILURE for Work [ id=a5cf708d-3f44-4db0-841e-7a0d14d28088, tags={ foundation.e.drive.periodicScan.FullScanWorker, eDrive } ]

I’ve downloaded the sqlite file, and browsed it. I have 200 files that are not in sync in synced_file_state table. They all have empty last_etag and zero value for local_last_modified column.
I’ve seen a few files that have a size of zero bytes. I removed them on the device but it did not help (using adb to launch a FORCE_SCAN)

image
image1754Ă—853 217 KB

In the synced_folder table, I have a few folders in Documents that have an empty last_etag column, probably because they were moved or deleted on nextcloud side.
I also have a folder with zero as the last_modified column, where all the other ones have a much higher value. This folder is empty, which might be the reason of this zero value

12

empty etag / no last-modified: these files never saw a nextcloud remote reponse (that would fill them in)

W FullScanWorker: Periodic scan start is not allowed

this happens within checkStartConditions() at FullScanWorker.kt. I wonder if the FullScanWorker is cancelled because a PeriodicScanWorker is enqueued, need to read androidx.work docs.

Do you ever see requests by eDrive to your nextcloud instance? there’s also the FileObserver service that you could enable if its inactive (readme again) and check its function by making a few new photos if it reacts to the events (in the logcat, then accesslog).

13

The SQLite file still referenced files that I had deleted on my device.
So I’ve reset again the storage of eDrive app on the device, and restarted the device, which triggered a full sync.
I clearly see in nextcloud logs all the GET requests to download all files (with “eOS (Android) Owncloud-android” as the User-Agent, and sometimes “eOS (Android) Nextcloud-android”). All requests seem to to succeed with HTTP 200. It takes a while to download all of them.
And that’s all for server logs. I see no error in nextcloud access log with keyword “eOS”

Regarding the FullScan not allowed (previously mentioned), maybe it’s because I ran them too frequently in a short period of time.

14

last I remember the reason it logs deletions is to avoid a back-sync from the remote when deleted device-side

1 Like
15

Today I tried the TEST_SYNC command, and it seems to work well:

$ adb shell am broadcast -a foundation.e.drive.action.TEST_SYNC --receiver-include-background
Broadcasting: Intent { act=foundation.e.drive.action.TEST_SYNC flg=0x1400000 }
Broadcast completed: result=0

Whith following log on the device:

04-20 15:45:29.329 17848 17897 I WM-Processor: Moving WorkSpec (06c5fbec-e9e2-48a4-ba74-d3bab1040db6) to the foreground
04-20 15:45:29.334  1621 12555 I ActivityManager: Background started FGS: Allowed [callingPackage: foundation.e.drive; callingUid: 10106; uidState: TRNB; intent: Intent { act=ACTION_START_FOREGROUND cmp=foundation.e.drive/androidx.work.impl.foreground.SystemForegroundService (has extras) }; code:BACKGROUND_FGS_PERMISSION; tempAllowListReason:<null>; targetSdkVersion:34; callerTargetSdkVersion:34; startForegroundCount:0; bindFromPackage:null]
04-20 15:45:29.339 17848 17848 I WM-SystemFgDispatcher: Started foreground service Intent { act=ACTION_START_FOREGROUND cmp=foundation.e.drive/androidx.work.impl.foreground.SystemForegroundService (has extras) }
04-20 15:45:29.340  1621  3815 W ActivityManager: Foreground service started from background can not have location/camera/microphone access: service foundation.e.drive/androidx.work.impl.foreground.SystemForegroundService
04-20 15:45:29.344  1621 20013 W ActivityManager: Foreground service started from background can not have location/camera/microphone access: service foundation.e.drive/androidx.work.impl.foreground.SystemForegroundService

(…)

04-20 15:45:30.701 17848 17901 I StateMachine: Change Sync state to LISTENING_FILES from SYNCHRONIZING
04-20 15:45:30.711 17848 17897 I WM-WorkerWrapper: Worker result SUCCESS for Work [ id=06c5fbec-e9e2-48a4-ba74-d3bab1040db6, tags={ foundation.e.drive.synchronization.SyncWorker, eDrive } ]
04-20 15:45:30.720 17848 17848 I WM-SystemFgDispatcher: Stopping foreground service

And following log on nextcloud side:

[20/Apr/2025:13:45:28 +0000] "GET /ocs/v2.php/cloud/user?format=json HTTP/1.1" 200 1250 "-" "eOS (Android) Nextcloud-android"                            
[20/Apr/2025:13:45:28 +0000] "GET /ocs/v2.php/cloud/user?format=json HTTP/1.1" 200 1250 "-" "eOS (Android) Nextcloud-android"                            
[20/Apr/2025:13:45:29 +0000] "GET /ocs/v2.php/cloud/user?format=json HTTP/1.1" 200 1250 "-" "eOS (Android) Nextcloud-android"                            
[20/Apr/2025:13:45:29 +0000] "GET /ocs/v2.php/cloud/user?format=json HTTP/1.1" 200 1250 "-" "eOS (Android) Nextcloud-android"                            
[20/Apr/2025:13:45:29 +0000] "GET /ocs/v2.php/cloud/user?format=json HTTP/1.1" 200 1250 "-" "eOS (Android) Nextcloud-android"                            
[20/Apr/2025:13:45:29 +0000] "GET /ocs/v2.php/cloud/user?format=json HTTP/1.1" 200 1250 "-" "eOS (Android) Nextcloud-android"                            
[20/Apr/2025:13:45:29 +0000] "GET /ocs/v2.php/cloud/user?format=json HTTP/1.1" 200 1250 "-" "eOS (Android) Nextcloud-android"                            
[20/Apr/2025:13:45:29 +0000] "GET /ocs/v2.php/cloud/user?format=json HTTP/1.1" 200 1250 "-" "eOS (Android) Nextcloud-android"                            
[20/Apr/2025:13:45:29 +0000] "GET /ocs/v2.php/cloud/user?format=json HTTP/1.1" 200 1250 "-" "eOS (Android) Nextcloud-android"                            
[20/Apr/2025:13:45:29 +0000] "GET /ocs/v2.php/cloud/user?format=json HTTP/1.1" 200 1250 "-" "eOS (Android) Nextcloud-android"

Just a bit surprised that testing upload of 10 files results only in “GET” requests, no PUT or POST

16

I also managed to capture nextcloud logs when there is the rapid countdown notification on my device. There’s around 50 lines identical to:

[20/Apr/2025:15:44:57 +0000] "GET /ocs/v2.php/cloud/user?format=json HTTP/1.1" 200 1249 "-" "eOS (Android) Nextcloud-android"

So I queried this URL (with the same account), and saw something interesting about quotas:

{
    "ocs": {
        "meta": {
            "status": "ok",
            "statuscode": 200,
            "message": "OK"
        },
        "data": {
            "enabled": true,
(...)
            "firstLoginTimestamp": -1,
            "lastLoginTimestamp": 1745164376,
            "lastLogin": 1745164376000,
            "backend": "Database",
            "subadmin": [],
            "quota": {
                "free": -3,
                "used": 16992121481,
                "total": -3,
                "relative": 0,
                "quota": -3
            },
            "manager": "",
            "avatarScope": "v2-federated",
            "emailScope": "v2-federated",
            "additional_mail": [],
            "additional_mailScope": [],
            "phone": "",
            "phoneScope": "v2-local",
            "address": "",
            "addressScope": "v2-local",
            "website": "",
            "websiteScope": "v2-local",
            "twitter": "",
            "twitterScope": "v2-local",
            "fediverse": "",
            "fediverseScope": "v2-local",
            "organisation": "",
            "organisationScope": "v2-local",
            "role": "",
            "roleScope": "v2-local",
            "headline": "",
            "headlineScope": "v2-local",
            "biography": "",
            "biographyScope": "v2-local",
            "profile_enabled": "1",
            "profile_enabledScope": "v2-local",
            "pronouns": "",
            "pronounsScope": "v2-federated",
            "groups": [
(...)
            ],
            "language": "fr",
            "locale": "fr_FR",
            "notify_email": null,
            "backendCapabilities": {
                "setDisplayName": true,
                "setPassword": true
            }
        }
    }
}

In nextcloud UI, my account (which is the admin account of this nextcloud instance) has no quota:
image

Maybe the JSON value “-3” is used as is by eDrive, with the consequence of thinking there is no more storage space allowed for the user?
This would explain the behavior: it first checks for free space before uploading the files, and does not send them if storage is full.

Could the JSON value “-3” be a bug on nextcloud side? It’s currently a version 31.0.2 (I’m waiting for the docker image of 31.0.4 to be available to do the upgrade). I don’t see anything related in the changelog of 31.0.3 or 31.0.4

1 Like
17

I’ve changed the settings of my nextcloud user to set a quota (instead of unlimited).

And it worked! My photos were finally uploaded properly on nextcloud.

I’m very happy to finally have this workaround. Thanks @tcecyk for you help.

However, there’s a bug somewhere. Either on nextcloud side, that should not return this “-3” value or on eDrive side, that does not interpret this value properly? If I set back my user to “unlimited” quota, I again have this “-3” value in JSON payload.

2 Likes
18

According to Bogus value in quota-available-bytes · Issue #23058 · nextcloud/server · GitHub and Basic APIs — Nextcloud latest Developer Manual latest documentation , “-3” indeed means “Unlimited free space” in some webdav properties (but it’s another API).

I don’t see it documented in OCS APIs overview — Nextcloud latest Developer Manual latest documentation (but it’s still not exactly the same API as the one used by eDrive)

19

I don’t think unlimited(-3) is expected by eDrive. Should be a bugreport then after checking the code

20

I’ve just created eDrive does not upload any more when nextcloud user quota is set to unlimited (#8635) · Issues · e / Backlog · GitLab