I wanted to play my PSP games on the go, but the built-in storage on the Asus Flip C100PA is rather meagre (16GB). So, as a temporary workaround I did the following:
- Created a new folder named "Bound" in "Downloads".
- Created a folder named "PSP_Backups" on my 64 GB SD card (named "UNTITLED").
- Plugged in a USB HD and copied all my PSP backup games (.cso files) to the folder on the SD card.
- Opened a root shell and entered:
mount -o bind /media/removable/UNTITLED/PSP_Backups /run/arc/sdcard/default/emulated/0/Download/Bound && mount -o bind /media/removable/UNTITLED/PSP_Backups /run/arc/sdcard/read/emulated/0/Download/Bound && mount -o bind /media/removable/UNTITLED/PSP_Backups /run/arc/sdcard/write/emulated/0/Download/Bound
(Which is the following three commands strung into one with &&):
mount -o bind /media/removable/UNTITLED/PSP_Backups /run/arc/sdcard/default/emulated/0/Download/Bound
mount -o bind /media/removable/UNTITLED/PSP_Backups /run/arc/sdcard/read/emulated/0/Download/Bound
mount -o bind /media/removable/UNTITLED/PSP_Backups /run/arc/sdcard/write/emulated/0/Download/Bound
This gave Android apps read access to the folder. (at least, those I've tried).
mount -o bind /media/removable/UNTITLED/PSP_Backups /run/arc/sdcard/default/emulated/0/Download/Bound
mount -o bind /media/removable/UNTITLED/PSP_Backups /run/arc/sdcard/read/emulated/0/Download/Bound
mount -o bind /media/removable/UNTITLED/PSP_Backups /run/arc/sdcard/write/emulated/0/Download/Bound
This gave Android apps read access to the folder. (at least, those I've tried).
An potential issue with bind mounting the card like this is that Chrome OS by default apparently seems to unmount the SD card during deep sleep. So the mounted folders might stop working necessitating a reboot and repeat of the procedure.
This seems to have been fixed by switching off idle suspend as per the following (from https://github.com/dnschneid/crouton/wiki/Power-manager-overrides).
This seems to have been fixed by switching off idle suspend as per the following (from https://github.com/dnschneid/crouton/wiki/Power-manager-overrides).
sudo su #cant sudo next command
echo 1 >/var/lib/power_manager/disable_idle_suspend #change the action to do nothing
chown power:power /var/lib/power_manager/disable_idle_suspend #it belongs to power
restart powerd #let the change take effect
exit
Perhaps more complete SD card access integration will be added with an update to Chrome OS soon, rendering this unnecessary.
A different method of mounting the SD card to make it available for Android apps is detailed here. It enables write access, and is automated at boot, but does involve modifying a Chrome OS system file - which could potentially crash your computer. Only for the brave (or foolhardy).
UPDATE: I've also found another, similar method which seems to work on all devices tested. If you have already tried the bind mount method, without success, with an ext* formatted card - please see my most recent comment at the bottom of this page for an alternative.
A different method of mounting the SD card to make it available for Android apps is detailed here. It enables write access, and is automated at boot, but does involve modifying a Chrome OS system file - which could potentially crash your computer. Only for the brave (or foolhardy).
UPDATE: I've also found another, similar method which seems to work on all devices tested. If you have already tried the bind mount method, without success, with an ext* formatted card - please see my most recent comment at the bottom of this page for an alternative.
Hello,
ReplyDeletedid you ever find out a way to have read access ?
is it possible to automate this on wake up ?
Hi,
ReplyDeleteYes, I found another way to get full read/write access. I'll try to update the post in the next day or so.
RE: automating the bind mount - When I used this method, I ended up putting a script in /etc/init/ to automate it at boot. If you want to automate it on wake up, a script in /usr/lib/pm-utils/sleep.d/ might work.
Wow thanks! I sure hope you share how to get write access!
DeleteIf I can get write access, I might reconsider my purchase and the Samsung Chromebook Plus instead of the Asus C302
DeleteUpdated with a new post
DeleteMost likely there are quite a number of ways to do this, also I understand that Chrome OS developers recently estimated an ETA of within roughly a couple of milestones (versions) or so for Android r/w SD card support, so I imagine that, within a couple of months at most, there will likely be no need for these mount workarounds.
Does getting write access involves rooting ?
ReplyDeleteThis solution works for android apps running from arc, however do you know a solution that would work running apps from the play store on google Chrome using the new container system? The sdcard directory seems to /run/containers/android_rZkFqS/root/sdcard however this is symlinked to /storage/self/primary. I can't see where to point the mount to
ReplyDeleteYou have probably read all this elsewhere by now, (apologies for the delayed response) but anyway, not to leave a question hanging...
DeleteNo, it works for Play Store arc++. Marshmallow 6.1 and Nougat 7.1.1 containers both tested and working on my device. I haven't tried it on the old App Runtime for Chrome.
The android_alphanumeric directory is a bit of a red herring, as it seems to be a temp dir, created dynamically from the files in /opt/google/containers/android/rootfs/root/, which is by default read only at the moment, as it is mounted from a squashfs container two directories above it.
It's quite a complex system going on in there so it is understandable that SD card support has taken a while to implement fully, reworking the code and so on and so forth.
Try my new method, if you haven't already? (posted below). That one definitely works for ext*, at least on my device. Note that I haven't yet had the device fall into deep sleep, so I don't yet know if the power manager/idle suspend needs to be dealt with. I'm assuming it *might*
Will this work for EXT4 file systems or just FAT32
ReplyDeleteHmm... It's been a while now since I posted this... it looks like I might need to update the post...
DeleteI seem to remember I had this working for both vfat and ext4, but can only replicate it for vfat now. Testing with ext4, and the folder mysteriously disappears.
However, while I couldn't get the bind mounts working with an ext4 file system as per my post above, I found that by mounting the external media *directly* to the three run/arc/folders, the files were *viewable* in Android apps (read-only access) and, additionally, after setting the SELinux contexts for the three sub-folders to match their neighboring folders, I was then able to *create* files, and *write* to files, directly on the external media (rw access!).
My successful procedure for ext4 was as follows:
(each command on a new line, blank line left between commands for readability)
sudo su
mkdir -p /home/chronos/user/Downloads/SD-EXT
mount /dev/sda /run/arc/sdcard/read/emulated/0/Download/SD-EXT
mount /dev/sda /run/arc/sdcard/write/emulated/0/Download/SD-EXT
mount /dev/sda /run/arc/sdcard/default/emulated/0/Download/SD-EXT
setenforce 0
chcon u:object_r:fuse:s0 /run/arc/sdcard/default/emulated/0/Download/SD-EXT
chcon u:object_r:fuse:s0 /run/arc/sdcard/read/emulated/0/Download/SD-EXT
chcon u:object_r:fuse:s0 /run/arc/sdcard/write/emulated/0/Download/SD-EXT
setenforce 1
Thanks for this post--extremely useful stuff. The chcon command doesn't work for me. I get "chcon: failed to change context .... Operation not supported".
ReplyDeleteIs that because I'm using /dev/mmcblk1p1 instead of /dev/sda?
Not sure why you are getting that error (assuming your SD card is ext*). I don't think it's because it's /dev/mmcmlbk1p1, though...
ReplyDeleteThere's a variation on this method that you could try which avoids the need to chcon, instead setting up a loop device and mounting it with -o fscontext. The following works for me:
#Setup loop device
losetup -f /dev/mmcblk1p1
#Mount the loop device.
mount -o fscontext=u:object_r:fuse:s0 "$(ls -t /dev/loop* | head -1)" /run/arc/sdcard/default/emulated/0/Download/SD-EXT
mount -o fscontext=u:object_r:fuse:s0 "$(ls -t /dev/loop* | head -1)" /run/arc/sdcard/read/emulated/0/Download/SD-EXT
mount -o fscontext=u:object_r:fuse:s0 "$(ls -t /dev/loop* | head -1)" /run/arc/sdcard/write/emulated/0/Download/SD-EXT
If the above commands fail, you could also try taking out the part in quotes and selecting the loop device manually (i.e. run losetup again without any arguments and check which /dev/loop to use, then substitute it for the part in quotes).
I should note also that, by doing it this way, even after mounting the card/USB, Android apps may not have access to folders therein unless the permissions are set accordingly. Setting the permissions to 777 (in CrOS), on the folders you wish to access in Android should do it.
In addition, and especially since the native Android SD/USB storage support seems now to be somewhat nearer to functioning as expected (but still not quite there), your mileage may vary with these mount workarounds, depending on your OS version, use case and which apps you are using.
I've found these workaround very useful for some tasks, especially working with large files (and playing my PSP games), but also frustrating at times e.g. (when an SD card mount flakes out after deep sleep, or when I've entered a command slightly wrong and confused Android, necessitating a reboot to get folders visible again).
Hi great post, I have gone through the steps above on my ext4 sd card but Kodi can 't see past the first parent directory. I have chmod 777 everything. Do you have any suggestions ?
DeleteThanks in advance
Hi! May I ask something completely different than what this great blog post is about? I already spent a whole day trying anything I could find online and I simply do not know what I am doing wrong.
ReplyDeleteDo you know if an external USB disk connected to a chrome book formatted with EXT4 filesystem is writable?
It is automatically mounted but I cannot write data on it. Not as root, not from within a xenial Crouton installation. Many blog posts about Google trying to remove EXT support in Oct 2014 but bringing it back a few days later... but I am not sure if it's read only by design?
Nevermind... Chrome OS does support EXT4 rw on any device (tested SD Card and USB SSD). I absolutely have no idea why but after a device reformat it worked fine.
Delete