Mounting SD card content read/write in Android on Chrome OS






One way to mount SD card content r/w in Android on Chrome OS is to edit the Chrome OS system file arc-sdcard.conto pass a custom mount argument to minijail0 at boot.

As this does involve modifying a system file, rootfs verification needs to be off. Chrome OS will likely undo the modifications when it auto-updates*. 
Modifying system files can potentially lead to a forced powerwash and/ or USB recovery situation. It would be best to ensure any important files have been backed up. 

In any case, here's what's working for me:

Create a folder on the SD card named android-shared.

Backup the Chrome OS system file /etc/init/arc-sdcard.conf.

Add the following lines to
etc/init/arc-sdcard.conf at line 69, (line 67 in some versions) - the blank space directly after the line 
args="$args -k none,/,none,0x44000" # rec,private 

If the SD card is formatted vfat (Chromebook file browser default):
if [ -d /media/*/*/android-shared ]
  then
  mkdir -p /home/chronos/user/Downloads/sd-android
  mkdir -p /home/chronos/user/Downloads/.tmpsdmount

  mount /dev/mmcblk1 /home/chronos/user/Downloads/.tmpsdmount -o umask=0000
  mount -o remount --make-rshared /home/chronos/user/Downloads/.tmpsdmount

  # Mount shared mount points.
  args="$args -b /home/chronos/user/Downloads/.tmpsdmount/android-shared,/Downloads/sd-android,1"
  # Remount to make it writable.
  args="$args -k none,/Downloads/sd-android,none,0x2e"  # remount,nosuid,nodev,noexec
fi 
e.g. SD card formatted vfat in file browser, folder "android-shared" on SD card created in file browser.
Lines added to arc-sdcard.conf at line 69directly after the line 
args="$args -k none,/,none,0x44000"  # rec,private



If the SD card is formatted ext*:
if [ -d /media/*/*/android-shared ]
  then
  mkdir -p /home/chronos/user/Downloads/sd-android
  mkdir -p /home/chronos/user/Downloads/.tmpsdmount

  mount /dev/mmcblk1 /home/chronos/user/Downloads/.tmpsdmount -o user,rw
  mount -o remount --make-rshared /home/chronos/user/Downloads/.tmpsdmount

  # Mount shared mount points.

  args="$args -b /home/chronos/user/Downloads/.tmpsdmount/android-shared,/Downloads/sd-android,1"
  # Remount to make it writable.
  args="$args -k none,/Downloads/sd-android,none,0x2e"  # remount,nosuid,nodev,noexec
fi
e.g. SD card formatted ext2 in shell, folder "android-shared" on SD card created either in browser or in shell (if in shell chmod 777).
Lines  added to arc-sdcard.conf at line 69directly after the line 
args="$args -k none,/,none,0x44000"  # rec,private


After a reboot, Android apps should be able to save files to /Downloads/sd-android, which should actually point to android-shared on the SD card.

Tested with various Android apps, including tTorrent and Excel.

Android apps still cannot be moved/installed to the SD card with this method. One method to gain space for Android apps is to clone the whole of Chrome OS to the SD card and run it from there with Ctrl+U in the BIOS. This seemed to run incredibly slowly on a 64GB Kingston. Somewhat faster on a 32GB Sandisk but still laggy, especially when gaming.


Note:
If any part of a command is entered incorrectly, or there otherwise is a problem with the mount -  the SD card might become unavailable and/or Android apps might fail to load  - until the card is removed, and and the device rebooted.  In addition, if you need to remove the SD card, it would be prudent to first shut down the device (or restore the original arc-sdcard.conf & reboot) before doing so.

Further Note:
For this method to work, and not crash the OS, the removable device name MUST be entered correctly, in accordance with your own personal setup.

For example, if your SD card is partitioned, you would need to substitute /dev/mmcblk1px for /dev/mmcblk1, where x is the mounted partition holding the folder to share with Android. 

Or you might have a USB drive mounted at, for instance, /dev/sda1, in which case you would need to substitute /dev/sda1 for /dev/mmcblk1

Especial caution is advised if using this method with a USB drive, as removing the external storage while it is still mounted in this manner may result in an OS crash.

You can check your removable device setup with the shell command:
 mount | grep media/removable

*The frequency of auto-updates, and thus, how often the procedure may need to be repeated, will depend on what release channel you are running. If you are on the Dev or Canary channel and find yourself having to regularly repeat this (or any other) modification, it might be worth considering switching to the stable or beta release channel where auto-updates are less frequent.

UPDATE: I should also note that I have a previous post on this subject, with a 'safer' shell command method (now also supports writing to ext4). If you are new to this sort of thing, it might be better to try the shell command method, as it is unlikely to crash your computer, even if you get it wrong. 

In fact, it might be worth first trying the shell command method in the previous post anyway, as the chief advantage of the method on this page was R/W access. The other difference is that this is automated at boot, for which a new upstart job could easily be created, in any case.

19 comments:

  1. Does this work even after waking up or doing have to do it again if you put your chromebook to sleep?

    ReplyDelete
  2. It works even after waking up, doing it this way there doesn't seem to be a problem with losing the mount after sleep/wake.

    ReplyDelete
  3. Hello!
    I did exactly as you said but whenever my Chromebook launches a Android app, it crashes

    ReplyDelete
  4. Hello,

    Oh dear! That's not supposed to happen.
    I have revised the method slightly, perhaps you could give it another try?

    If you view /var/log/arc-sdcard.log, does something like the following show up (about halfway down)?

    + [ -e /media/removable/SD Card/android-shared ]
    + mkdir -p /home/chronos/user/Downloads/sd-android
    + mkdir -p /home/chronos/user/Downloads/.tmpsdmount
    + mount /dev/mmcblk1 /home/chronos/user/Downloads/.tmpsdmount -o user,rw
    + mount -o remount --make-rshared /home/chronos/user/Downloads/.tmpsdmount
    + args= -P /opt/google/containers/arc-sdcard/mountpoints/container-root -e -p -v -l -K -a android -f /run/arc/sdcard.pid -k proc,/proc,proc,0xe -b /opt/google/containers/android/rootfs/root/system/bin/sdcard,/system/bin/sdcard -b /opt/google/containers/android/rootfs/android-data/data,/data,1 -b /home/chronos/user/Downloads,/Downloads,1 -b /home/chronos/user/Downloads/.tmpsdmount/android-shared,/Downloads/sd-android,1

    ReplyDelete
  5. I think I have this working correctly. Unfortunately, I think ChromeOS includes the data stored there as storage used up without including capacity added there. In other words, I think I'll run out of space without running out of space.

    If that turns out to be the case, I'll see about only mounting a part of the SD Card, something I'll only use to share stuff.

    Thanks for this!

    ReplyDelete
  6. Yes, it gives a scary warning about drive space being critically low, but in my experience that's all it does, you can just power through filling on up the space on the SD card and (after a reboot, ISTR), everything's back to normal and nothing has been deleted. Of course, if you have any files stored in 'Downloads', it's probably safe to keep them backed up, just in case.

    ReplyDelete
  7. Any suggestions on troubleshooting? This worked for a day or so, providing a place for my video podcasts. When I went to check it this evening, the SD card was not visible from ChromeOS (or from Android). After reboot, it's back, but the sharing between systems isn't up.

    ReplyDelete
  8. Is the modified conf. file still there? (Chrome OS keeps two copies of the rootfs and alternates between them for updates)...

    Is your SD card formatted vfat or ext?

    Also, if you have a USB drive inserted in addition to the SD card, the first line seems to need to either contain two wildcards (e.g. if [ -d /media/*/*/android-shared ]
    ) or refer to the SD card/drive you want to use specifically...

    ReplyDelete
  9. SD Card is gone again. Gone, as in the ChromeOS "Files" app doesn't see it. If I pop it out, the OS will complain. I may have to go back to the original conf file to see if my issues are separate from anything to do with making the card visible to Android apps.

    Modifed conf file still there. VFat. No USB.

    ReplyDelete
  10. Are you using the exact same snippet of code as above or is yours slightly different?

    When I was testing things out I tried quite a few different variations and I did encounter issues with the SD card in Chrome OS at a few junctures - initially I had the code unmounting the card then mounting it as shared, which caused an issue.

    I haven't had an issue with it as it is at the moment though, it seems totally solid for me. Perhaps you could paste the modified part of the .conf in here, just to compare?

    You could also check /var/log/arc-sdcard.log for any errors...

    ReplyDelete
  11. if [ -e /media/removable/*/android-shared ]
    then
    mkdir -p /home/chronos/user/Downloads/sd-android
    mkdir -p /home/chronos/user/Downloads/.tmpsdmount

    mount /dev/mmcblk1p1 /home/chronos/user/Downloads/.tmpsdmount -o umask=0000
    mount -o remount --make-rshared /home/chronos/user/Downloads/.tmpsdmount

    # Mount shared mount points.
    args="$args -b /home/chronos/user/Downloads/.tmpsdmount/android-shared,/Downloads/sd-android,1"
    # Remount to make it writable.
    args="$args -k none,/Downloads/sd-android,none,0x2e" # remount,nosuid,nodev,noexec
    fi

    Does that log file overwrite itself each boot? I looks like it only has standard stuff, and that only after the reboot when I reset to the original conf file. Perhaps I need to check the log when the problem arises.

    Thanks for the help!

    ReplyDelete
  12. No problem, yeah, the log files get overwritten each time Android boots - it's basically just a line-by-line log of the .conf file. If the sharing between systems isn't happening (or if - as a previous commenter experienced - crashes occur), the log could shed some light.

    When the card disappeared from Chrome OS, had the system been running for some time? My original method to mount the SD card (read-only) in Android seemed to necessitate switching off the power manager/idle suspend to avoid issues. Personally, I haven't found it necessary at all to do this with the current method but if you continue to experience issues with the SD card disappearing, I suppose it wouldn't do any harm to also try switching off idle suspend as mentioned in my previous post.

    sudo su
    echo 1 >/var/lib/power_manager/disable_idle_suspend
    chown power:power /var/lib/power_manager/disable_idle_suspend
    restart powerd
    exit

    (to switch idle suspend back on):
    rm -f /var/lib/power_manager/disable_idle_suspend

    ReplyDelete
  13. That fixed the card disappearing from Chrome OS. Android did lose access towards the end of yesterday. No errors in the log, which is expected, I think, since the log is from when the successful connection was first made. What might make Android lose connection?

    ReplyDelete
  14. Not sure, but I wouldn't be surprised if its related...

    I've experienced the disappearing SD card, too, lately. I did find a couple of recent threads on Reddit in which people are complaining about similar issues with the power management & external storage, suggesting something changed in the OS recently, but I don't know, really. I tried out
    echo -1 > /sys/class/mmc_host/mmc1/mmc1\:e624/power/autosuspend_delay_ms
    but that only seems to keep the card working in Android, and not the Chrome OS Files app. If I get time I'll try out a few other things...

    https://www.reddit.com/r/chromeos/comments/63t3fv/usb_flash_stick_goes_away_after_suspending/
    https://www.reddit.com/r/Crouton/comments/5yv6hq/crouton_installed_to_usb_unmounts_shutting_lid/

    ReplyDelete
  15. Is there a way to get it to work with NTFS ?

    ReplyDelete
  16. I kind of doubt it, though I haven't tried... Linux support for NTFS seems a bit hit and miss since it's all reverse engineered.

    If you have a spare NTFS drive that you can test it out with first, and are prepared to potentially recover your system via USB if something goes wrong, you could try it, but I don't think I'd recommend doing so..

    ReplyDelete
    Replies
    1. And is there a file system that I could read on my Windows machine while not having the limitations of FAT32 ?

      Delete