Recently there has been a big fuss about Chromebooks and how the Chrome OS will be folded into android. That is great news for users and even better news for hackers who can get a Linux laptop for as little as 135$. Well, almost Linux. It turns out that one needs to jump through quite a few hoops to get to the core of the OS where you can actually use your computer like the baws that you are.

So one of the issues that the the Unix fan will encounter is the strange way local storage is handled. Actually in normal mode there is no obvious and direct way one can affect their filesystem. I will try to provide an introduction to some technical aspects of the Chrome OS while mounting a remote filesystem to your device the traditional way.

Be safe rather than sorry

Before we go on we need to make sure we are safe. Google has implemented a nice way of resetting your Chromebook device to a working state, no matter how hard you have screwed up (almost). To be able to do that you need a USB stick of 4G. In theory you could use 2G but that didn’t work for me. Plug your USB into your Chromebook and go to chrome://imageburner. Follow the instructions to turn your flash drive into a reset media.
Now, if worse comes to worst, plug in your USB, press Esc+Refresh+Power and keep Esc+Refresh down until something happens. For details on how the whole boot process works see the boot flowchart.

Developer mode

The normal mode, that is the default for a Chromebook, is quite restrictive when it comes to hacking your Chromebook. You can do all sorts of stuff like browse Facebook or program arduinos, but no non-cloud stuff. That’s what developer mode is for. Skipping the details of what is going on, in practice the developer mode basically allows you to run a bash shell and also root access.

To boot in developer mode, hit Esc+Refresh+Power and keep Esc+Refresh down. Then hit Ctrl+D and confirm that you want to turn off OS verification. You will be presented with a screen warning you that OS verification is off. Hit Ctrl+D again and wait a while for the system to boot. The delay is not your system being slow but rather a security feature.

Black screen of bliss

To most Linux powerusers the mouse is evil and the command line is the normal way of doing stuff. You may be able to get to a tty by typing Ctrl+Alt+Right Arrow (left arrow is actually F1 and right arrow is actually F2) to which you can login as chronos without a password. That didn’t work on my device so I used the graphical terminal emulator that can be fired up with Ctrl+Alt+T. The shell here is called crosh with the command shell to get to a the bash shell you know and love.

A small tour of the filesystem

Poking around the filesystem you will find that the Chrome OS is pretty much like one would expect a Linux system to look like. That is until we check the mounted partitions:

$ sudo mount -l
/dev/dm-0 on / type ext2 (ro,relatime)
[...]
/dev/sda1 on /home type ext4 (rw,nosuid,nodev,noexec,relatime,commit=600,data=ordered)
/dev/mapper/encstateful on /home/chronos type ext4 (rw,nosuid,nodev,noexec,relatime,discard,commit=600,data=ordered)
/dev/sda1 on /usr/local type ext4 (rw,nodev,relatime,commit=600,data=ordered)
[...]

There are tons of interesting stuff to poke around in here but for the scope of this article the following points are:

  • The root of the filesystem / is read only.
  • You can run no executables from /home
  • You can run executables from /usr/local

Also interesting is the usage of each partition:

$ df -h
Filesystem                                                    Size  Used Avail Use% Mounted on
/dev/root                                                     1.2G  1.1G  175M  86% /
devtmpfs                                                      938M     0  938M   0% /dev
tmp                                                           939M  8.9M  931M   1% /tmp
run                                                           939M  396K  939M   1% /run
shmfs                                                         939M   16M  924M   2% /dev/shm
/dev/sda1                                                      11G  157M  9.8G   2% /home
/dev/sda8                                                      12M   24K   12M   1% /usr/share/oem
/dev/mapper/encstateful                                       3.1G   17M  3.1G   1% /var
media                                                         939M     0  939M   0% /media
none                                                          939M     0  939M   0% /sys/fs/cgroup
/home/.shadow/11a9adac1a11571863bc506a4ff71356bcaf7d8a/vault   11G  157M  9.8G   2% /home/chronos/user

You are probably expected to store your data in /home/chronos/user but take my word that Chrome OS swallows up that space before you realize what’s happened. It would be nice to have a network filesystem to work with.

Network filesystems

So let’s see what filesystems we can go for. Let’s first try nfs:

$ sudo mount -t nfs test@test.cc:/ ~/public
mount: unknown filesystem type 'nfs'

That’s a shame but I didn’t have my hopes too high for that anyway. nfs is not the cloud and the cool kids only use the cloud it seems. Let’s see what modules the kernel provides.

$ sudo lsmod
[...]
fuse                   63981  0 
[...]

Bingo! For the uninitiated, fuse is a way to have user-space applications, like archive managers or network protocol implementations, provide filesystem implementations. And that means in our case SSHFS, the way to mount filesystems over SSH. SSH itself is available on Chromebook so there is no reason that this can’t work.

Getting SSHFS

There is no proper package manager for the Chrome OS so we are better off installing SSHFS by hand. I could find no built binaries online so I got it from an archlinux repo:

$ wget http://mirror.rackspace.com/archlinux/community/os/x86_64/sshfs-2.5-1-x86_64.pkg.tar.xz $ tar xvf sshfs-2.5-1-x86_64.pkg.tar.xz 
$ sudo mkdir /usr/local/bin
$ sudo cp ./usr/bin/sshfs /usr/local/bin/ 
$ export PATH=$PATH:/usr/local/bin/

And that is all you need! Now you can just mount your remote partition.

$ mkdir ~/Remote
$ sshfs drninjabatman@192.168.11.73:Users/drninjabatman/Projects $HOME/remote
$ sudo mount -l
[...]
drninjabatman@192.168.11.73:/Users/drninjabatman/Projects on /home/chronos/user/remote type fuse.sshfs (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)

And you are in! Read/write and execute access to anything on your remote.

The good, bad and the ugly

The most obvious limitation of this procedure is that you have to mount your network shares manually each time. Since the rest of the system (eg the “Load unpacked extension” dialog) will just ignore your mount you will only be using it with bash. So in ~/.bashrc you can put something like:

if ! sudo mount -l | grep "/Users/drninjabatman/Projects"; then
    /usr/local/bin/sshfs drninjabatman@192.168.11.73:Users/drninjabatman/Projects $HOME/remote
fi

And you will probably never know the difference.

Now one cool thing you might actually be able to do is mount a remote share on /nix and then install the nix package manager there, and then the sky is the limit! (and probably Unix sockets playing well with SSHFS)

One thought on “[Developer Says] Remote filesystem in chrome OS

  1. Thanks for taking the time to explain more about the Chrome OS filesystem, much appreciated. I’ve been planning to get a Chromebook myself as well and after reading this post that idea got a little stronger. I still have my doubts though about the future of the OS and if they won’t make it even harder to adjust the system after several updates, it seems they want to create these limitations on purpose.

    Reply

Leave a reply

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> 

required