Android environment programs cannot create any files on external storage (SD Card)

OS VERSION: (with Android App Support 11)


After debugging for several hours why AntennaPod stopped being able to download any feed updates after the SFOS 4.5 / Android 11 update (also see their issue tracker), I realized that the underlying issue appears to be that all programs inside the Android LXC container (not just apps) are unable to create regular files on external storage – this issue only affects the regular file inode type and only if the files are newly created (opening existing files for writing is file, as is creating directories and named pipes at least).


SailfishOS with up-to-date Android App Support on a device with an inserted microSD card.


While it also affects Android apps the Android environment as a whole is affected, so these steps use the terminal:

  1. Make sure Android App support is installed and running
  2. Open terminal app
  3. Run devel-su appsupport-attach to enter the Android environment as root
  4. Use ls /storage to find the mount directory of the inserted microSD card
  5. Try to create a file there: touch /storage/<UUID>/somefile.txt


A file is created on the filesystem of the inserted microSD card.


The touch command (and any other system API for that matte) reports a misleading error message:

touch: ‘/storage/<UUID>/somefile.txt’: No such file or directory


Some stuff, but none that affect the Android environment.


Note that doing the exact same thing on internal storage works just file:

touch /storage/emulated/0/somefile.txt

Also creating a directory works without issue:

mkdir /storage/<UUID>/somedir

9/10 it’s some dumb bug in the fuse driver providing the overlay for that mountpoint:

/dev/fuse on /storage/<UUID> type fuse (rw,lazytime,nosuid,nodev,noexec,noatime,user_id=0,group_id=0,allow_other)


Thanks a lot for writing this bug !!!
It explains (i think and i’m not a dev, just an user) why it is impossible to use OsmAnd and Magic Earth with files on the µSD card.

Oooh, great timing. Is this why I discovered today Google Photos is unable to save any edited photos? :thinking:

In hindsight I also remembered that OsmAnd~ complained about requiring a storage migration on every start, but otherwise appeared to work fine. In the context of this issue that would make total sense though, since it can still read all the existing map data but creating a test file to check if the storage is writable (I don’t if it actually does that, but it would be the most obvious way to test if the storage is indeed writable or not) would fail – albeit with the wrong error code (ENOENT instead of EROFS).

Is this why some Android apps may not be configured to use the sd card as memory for maps or music (Here Wgo, Spotify) or fail to store new maps on sd card (Komoot)? If that is true, all these storage related issues in Android apps could be solved by one (hopefully not too complex) bugfix.
Any response from Jolla on this?

Ok, before we all get too carried away by my wonderful bug report, could some of you perhaps reproduce this specific issue using the Steps to reproduce I’ve posted?

I just want to make sure we’re all talking about the same issue here. And yes, it could potentially explain all the other issues people have mentioned so far – if we’re all indeed affected by this issue and if that’s the only Android external storage related bug at play here. :slightly_smiling_face:

1 Like

I can confirm that while it is possible to create directories, it’s not possible to create files in the storage directory that represents the sd card within Andoid app support.
This is in line with the behaviour of Android apps I tested. All those apps fail to store files, such as maps or music, on the external sd card, but at least some of them are able to create directories. This is in contrast to former Sailfish OS versions where Android apps were able to store files on sd card.

I can also confirm that. Are you still able to backup to your sd card?

Is there any reaction from Jolla on this topic? Any internal bug filed, or at least some sign it is tracked at all?

Hi everyone,

I also can confirm this behavior with ghost commander and here maps (herewego).

With ‘regular’ files you can do two steps. I.e. copy files from nas via ghost commander to android storage. Afterwards use sfos file manager to copy files from android storage to sd card. Pretty annoying but working out.

With map files (like here, osmand or magoc earth) as mentionend by @mips_tux and @ziellos you hardly can call it work around :wink:

I’d too really appreciate jolla presenting solution.

Thanks in advance!

I was able to reproduce this on 4.5.0. However, I was not able to reproduce on our current development version. This leads me to believe that this has been fixed, even though I’m not able to find a corresponding bug in our internal tracker.

1 Like

This is just to confirm that the issue is still present after updating to Sauna. Android apps are able to see sd card storage, but are unable to create contents on sd card. Tested with Komoot (offline map storage) and Spotify (offline music storage).

@ziellos: It had been fixed in Android 11 AppSupport for SailfishOS 4.5. If it’s broken again it’s a regression.