Error "Couldn't open file from storage"

[hiqua]

Like #34, but as of today. Feel free to merge if appropriate.

It's broken again for me, maybe because of the last Android update?

I can select the file, and I think it does synchronize the first time. But afterwards, it never updates and I get the "Couldn't open file from storage" within the ICSx5 UI.

The file is synchronized via syncthing.

Pixel 6 pro, Android 13 with December 5th security update. Build number TQ1A.221205.011.

[88-percent]

I'm getting the same behavior, but I'm thinking I must be doing something wrong as the above post appears to be the only other complaint of this behavior in the past year.

Would anyone who's successfully syncing a local ics file be able to share their setup?

[88-percent]

For anyone else experiencing this issue, for me this was caused by a permissions issue.

Granting group read write permissions on the desktop ics file solved this for me.

edit: after recently trying to set this up again it doesn't look like permissions were the issue - or at least not the only issue. See mcdamo's answer below for a workaround that works.

[hiqua]

Yes, I don't remember how I fixed it last time I installed it, but I might have had to grant permissions manually. Once that's done it works flawlessly, now on Android 14.

[mcdamo]

Same issue with ICSx5 v2.4.0

• Subscribed to local File in ICSx5
• Initial calendar sync worked
• Updated File using Syncthing
• ICSx5 fails to sync Error: Couldn't open file from storage
• ICSx5 will no longer sync the File until the subscription is deleted and recreated with File picker
• Problem repeats every time Syncthing updates the File

[java.io](http://java.io/).IOException: Couldn't open file from storage
	at at.bitfire.icsdroid.CalendarFetcher.fetchLocal$icsx5_89_2_4_0_gplayRelease(SourceFile:124)
	at at.bitfire.icsdroid.CalendarFetcher.fetch(SourceFile:51)
	at at.bitfire.icsdroid.ProcessEventsTask.processEvents(SourceFile:211)
	at at.bitfire.icsdroid.ProcessEventsTask.sync(SourceFile:74)
	at at.bitfire.icsdroid.BaseSyncWorker.doWork$suspendImpl(SourceFile:74)
	at at.bitfire.icsdroid.BaseSyncWorker$doWork$1.invokeSuspend(Unknown Source:11)
	at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(SourceFile:33)
	at kotlinx.coroutines.DispatchedTask.run(SourceFile:100)
	at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(SourceFile:586)
	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(SourceFile:829)
	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(SourceFile:717)
	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(SourceFile:704)
Caused by: java.lang.SecurityException: Permission Denial: opening provider com.android.providers.downloads.DownloadStorageProvider from ProcessRecord{f7a28db 7518:at.bitfire.icsdroid/u0a368} (pid=7518, uid=10368) requires that you obtain access using ACTION_OPEN_DOCUMENT or related APIs
	at [android.os](http://android.os/).Parcel.createExceptionOrNull(Parcel.java:3340)
	at [android.os](http://android.os/).Parcel.createException(Parcel.java:3324)
	at [android.os](http://android.os/).Parcel.readException(Parcel.java:3307)
	at [android.os](http://android.os/).Parcel.readException(Parcel.java:3249)
	at android.app.IActivityManager$Stub$Proxy.getContentProvider(IActivityManager.java:6397)
	at android.app.ActivityThread.acquireProvider(ActivityThread.java:8191)
	at android.app.ContextImpl$ApplicationContentResolver.acquireUnstableProvider(ContextImpl.java:3866)
	at android.content.ContentResolver.acquireUnstableProvider(ContentResolver.java:2544)
	at android.content.ContentResolver.query(ContentResolver.java:1215)
	at android.content.ContentResolver.query(ContentResolver.java:1163)
	at at.bitfire.icsdroid.CalendarFetcher.fetchLocal$icsx5_89_2_4_0_gplayRelease(SourceFile:106)
	... 11 more
Caused by: [android.os](http://android.os/).RemoteException: Remote stack trace:
	at [com.android.server.am](http://com.android.server.am/).ContentProviderHelper.checkAssociationAndPermissionLocked(ContentProviderHelper.java:726)
	at [com.android.server.am](http://com.android.server.am/).ContentProviderHelper.getContentProviderImpl(ContentProviderHelper.java:310)
	at [com.android.server.am](http://com.android.server.am/).ContentProviderHelper.getContentProvider(ContentProviderHelper.java:150)
	at [com.android.server.am](http://com.android.server.am/).ActivityManagerService.getContentProvider(ActivityManagerService.java:7079)
	at android.app.IActivityManager$Stub.onTransact(IActivityManager.java:2998)

[mcdamo]

I think the important detail is ICSx5 will only work if it is subscribed BEFORE using syncthing.

1. Manually copy calendar.ics to downloads folder
2. Subscribe to ICSx5, source should have a path like content://com.android.providers.downloads.documents/document/raw%3A%2Fstorage%2Femulated%2F0%2FDownload%2Fcalendar.ics
3. Then setup syncthing as required to update the calendar.ics.

After using syncthing to update the calendar on the device, if you then subscribe to the calendar.ics it will use a source with an ID instead of a path like content://com.android.providers.downloads.documents/document/msf%3A1000012345

This type of subscription will break anytime syncthing updates the calendar file and ICSx5 will give the Couldn't open file from storage error

[ArnyminerZ]

Hi, which syncthing client are you using?

[mcdamo]

Hi, which syncthing client are you using?

https://github.com/Catfriend1/syncthing-android

[sunkup]

Works well with syncthing-fork too here. Can you try with 2.4.2 and latest syncthing-fork release?

[88-percent]

I think the important detail is ICSx5 will only work if it is subscribed BEFORE using syncthing.

1. Manually copy calendar.ics to downloads folder

2. Subscribe to ICSx5, source should have a path like `content://com.android.providers.downloads.documents/document/raw%3A%2Fstorage%2Femulated%2F0%2FDownload%2Fcalendar.ics`

3. Then setup syncthing as required to update the calendar.ics.

After using syncthing to update the calendar on the device, if you then subscribe to the calendar.ics it will use a source with an ID instead of a path like content://com.android.providers.downloads.documents/document/msf%3A1000012345

This type of subscription will break anytime syncthing updates the calendar file and ICSx5 will give the Couldn't open file from storage error

After recently trying to set this up again I believe that mcdamo's answer is in fact the correct one. Even after adjusting the permissions I continued to get the error couldn't open file from storage on subsequent sync operations. Shutting down Syncthing, clearing ICSx5's storage & cache, adding the file manually, ensuring that the path ended in .ics and then enabling the Syncthing seems to be working now.

[whorled]

we have also encountered this couldn't open file from storage error, and tried mcdamo's solution to no avail. we had ICSx5 v2.4.3-standard setup and working on two phones, a rooted moto g and an unrootable zte, using syncthing-fork v2.0.12 to bring the *.ics files from the main KOrganizer calendar on a linux pc. the zte was old with tired flash and battery, and we had an identical unused one, so we used adb backup/restore to put the working setup from the old phone into the new one. after restore, we found this new behavior, ICSx5 couldn't access the files after a reboot. the files were showing as content://com.android... but it still didn't keep working. grok suggested that adb silently 'upgraded' SAF on the new phone during the restore. lacking any fix, we did a factory reset on the phone and started over, but the results were unchanged. grok claimed the SAF 'upgrade' was persistent thru the factory reset.

so here is our solution, if it can help anyone else struggling with this: we installed termux & termux-boot on the new zte, then 'pkg install nginx' in termux, set the nginx document root to the syncthing folder, then added the *.ics files into ICSx5 as weburls with their localhost addresses. works perfectly, no SAF nonsense. hth