Termux-App sieht seit Update auf ShiftOS 5.x die SD-Karte nicht mehr

[moormaster]

Hallo,

ich habe mein Shiftphone 6mq kürzlich geupdated von ShitfOS 3 auf 5 und kann seitdem mit der Termux-App die SD-Karte nicht mehr erreichen.

Normaler Weise sollte innerhalb von termux der Befehl setup-termux-storage symlinks anlegen, um auf den internen Speicher und auf externe SD Karten zugreifen zu können.
Der zur sd-card gehörige symlink ~/storage/external-1 wird jedoch nicht erzeugt.

Unter Einstellungen/Speicher im ShiftOS kann ich sie jedoch sehen und darüber auch in einen Dateimanager wechseln, der mir den Inhalt anzeigt.

Ich habe dazu claude code per adb analysieren lassen und die KI ist der Meinung, das Problem kommt daher, weil die SD-Karte im Android-System unter /storage/xxxx-yyyy nicht auftaucht:

adb shell ls -la /storage

total 7
drwx--x---  4 shell everybody   80 1970-01-01 01:00 .
drwxr-xr-x 27 root  root      4096 2009-01-01 01:00 ..
drwx--x--x  4 root  everybody 3464 2024-08-20 09:46 emulated
drwxr-xr-x  2 root  root        60 2026-07-25 11:36 self

Beim Einhängen der SD-Karte kommt in adb logcat eine Meldung, die damit vermutlich zusammenhängt.

MediaStore: Examining volume public:179,1 with name 3636-3464 and state mounted
MediaStore: skipping unreliable volume : 3636-3464

Die (vermutete) Ursache ist wohl, dass die sdcard per vold und sdcardfs eingehangen wird - die aktuellste Version des MediaStores jedoch eine per FUSE gemountete Karte erwartet.

Ist das ein Fehler, der in ShiftOS 5 behoben werden kann/sollte oder ist das eine gewollte Einschränkung und die KI hat sich mit der Analyse nur verlaufen?

Ab hier folgt nun die Beschreibung des Issues, wie Claude Code es selbst zusammengefasst hat:

---

SD card mounts at OS level but is never given a raw filesystem path (breaks Termux storage setup) (ShiftOS 5 / Android 13, SHIFT6mq)​

Device / build info​

• Device: SHIFT6mq (codename axolotl)
• ShiftOS version: ShiftOS 5 (Android 13)
• Build ID: TQ3A.230901.001
• Build incremental: 20240820
• Build date: 2024-08-20
• Android security patch: 2024-07-05
• LineageOS base version: 20.0

Summary​

After updating from ShiftOS 3 (Android 10) to ShiftOS 5 (Android 13), Termux can no longer access the SD card. Specifically, termux-setup-storage fails to create the ~/storage/external-1 symlink for it.

I dug into this over adb and found that the SD card never becomes "visible" storage at the OS level (see diagnostics below) — Android never assigns it a /storage/<uuid> raw filesystem path, which is what termux-setup-storage needs. This is not a Termux permissions problem.

Note that the Google Files app can browse the card's contents fine, which is consistent with what I found: the card does show up as a Storage Access Framework (SAF) root, it's specifically the raw/direct filesystem path that's missing. I have not verified whether other apps that expect a raw filesystem path (rather than SAF) are similarly affected — Termux is the only one I've tested.

Steps to reproduce​

1. Insert an SD card (tested with two different cards: one exFAT, one freshly formatted FAT32/vfat — both via Android's own Settings → Storage formatter).
2. Card mounts successfully — visible in Settings → Storage, readable at the raw/vold level, and browsable in the Google Files app.
3. In Termux, run termux-setup-storage.
4. No ~/storage/external-1 symlink is created for the SD card, because Android never creates a /storage/<uuid> path for it (see diagnostics below).

Expected behavior​

The SD card should get a /storage/<uuid> mount point and be visible/writable to apps with storage permission, as it did on ShiftOS 3 (Android 10).

Actual behavior / diagnostic findings​

Diagnosed over adb (dumpsys mount, sm list-volumes, logcat). Findings:

• The card does mount correctly at the vold/kernel level:
  
  

  VolumeInfo{public:179,1}:
      type=PUBLIC diskId=disk:179,0 partGuid= mountFlags=0 mountUserId=0 state=MOUNTED
      fsType=exfat fsUuid=3636-3464 fsLabel=disk
      path=/mnt/media_rw/3636-3464 internalPath=/mnt/media_rw/3636-3464

  
  Note mountFlags=0 — compare to the internal/emulated storage volume, which correctly shows mountFlags=PRIMARY|VISIBLE_FOR_WRITE. The SD card is never marked visible, regardless of card or filesystem used.
• logcat shows the MediaProvider module explicitly rejecting the volume on every mount:
  
  

  MediaStore: Examining volume public:179,1 with name 3636-3464 and state mounted
  MediaStore: skipping unreliable volume : 3636-3464

  This happened identically for both test cards (different UUIDs, different filesystems), so it is not specific to one card or one filesystem — it's systemic.
• At boot, vold logs that it is still using the legacy sdcardfs kernel-level storage emulation for the primary/internal volume:
  
  

  vold: Executing sdcardfs
  vold: Waiting for sdcardfs to spin up...

  
  
  This is the pre-Android-11 storage emulation approach. Since Android 11, the FUSE-based storage bridge (hosted inside the MediaProvider Mainline module, com.google.android.providers.media.module, which auto-updates via Play Store independently of the ROM) is the expected mechanism. My working theory is that this ROM's vold/kernel storage stack is a hybrid that still relies on sdcardfs, while the Play-Store-updated MediaProvider module (observed as versionCode 37 / versionName 17, targetSdk 37 — clearly a build newer than what shipped with this ROM) expects the newer pure-FUSE handshake for public volumes. The mismatch results in MediaProvider refusing to trust/expose the SD card at all.

What I've ruled out​

• Not a Termux permissions issue. Termux has all relevant storage permissions granted (READ_EXTERNAL_STORAGE, WRITE_EXTERNAL_STORAGE). The diagnostics below show the volume is never marked "visible" at the OS level, which is a prerequisite for any app to get a raw path to it, regardless of that app's own permissions.
• Not a bad/incompatible SD card. Reproduced identically with a different physical card, freshly formatted through Android's own Settings → Storage formatter.
• Not a stuck/stale mount state. Cycling the volume with sm unmount / sm mount (adb) reproduces the exact same mountFlags=0 / "unreliable volume" result every time — it's not a one-off glitch that a remount fixes.
• Not a user restriction. dumpsys user shows no active restrictions (DISALLOW_MOUNT_PHYSICAL_MEDIA or otherwise); device is unmanaged (Device managed: false).

Notes​

• The card shows up as a Storage Access Framework (SAF) root (ExternalStorage: After updating volumes, found 2 active roots), which is presumably why the Google Files app can browse it fine — SAF access doesn't require the /storage/<uuid> raw path. It's specifically that raw path that's missing, which is what breaks termux-setup-storage.