Otter logo image
Valid HTML 4.01 Transitional

Asus Transformer Pad Infinity
My Home Directory

Jim Carter, 2013-06-15

In the world of personal computing, each machine typically has a separate home directory for each relevant user, and software is installed separately on each host. This is how I have operated so far on my home network. However, with the new tablet I expect to face several issues involving my home directory:

Network Filesystems

In around 1985 Sun Microsystems introduced their Sun-2 and Sun-3 line of workstations based on the Motorola MC68010 and MC68020. Their slogan was the network is the computer. Their then-new Network File System (NFS) was the heart of the strategy. A user's home directory, plus much of the shared software, resided on a file server and was sent via NFS to any of the workstations, so whichever one the user was at, the same content was available. UCLA-Mathnet adopted this strategy at that time and continues to use it to this day (2013).

The obvious solution to my requirements is a network filesystem, except for the last one. The requirements in my case for a network filesystem are:

Credible network filesystems include:

I would really like the Dropbox model: the network mounted directory is available on each client locally, and is synced automatically to and from each participating client. When there is no network connection the syncing has to wait until the network returns. If two clients change the same file before syncing, this should be detected but automatic resolution is too much work to be promised.

It looks like the surviving contenders are NFS, CIFS and SSHFS. AFS is too obsolete and its authentication cannot be supported. Intermezzo is not widely deployed and has no Android client. iSCSI is for a SAN, not for multiple clients sharing the same filesystem. GFS is intriguing but there is no Android client (though the kernel modules could be built). Dropbox is politically unacceptable.

Client Side Caching

There is a thing called CacheFS.

The main benefit of CacheFS is speed on the client for repeatedly read files. While this may be useful to me when I run over a slow network link, I think I should defer CacheFS until the remote filesystem is nailed down.

Where to find CacheFS:

Problems with Authentication and Authorization

If I use NFS, there is an ugly fly in the ointment: authentication and authorization, specifically whether the client is permitted to read or write the files on the server. Here are some of the issues for NFS:

Picking the Network Filesystem

Here is a summary of the characteristics of the three network filesystems.

Style Block overlayer Block overlayer File overlayer File overlayer
Authentication Honor system LoginID+PW SSH RSA key or password Normal SSH
Android Client CIFSManager CIFSManager SSHFSDroid DebianKit
Maturity Well liked Well liked Alpha level, €2 Mature
Complaints No authentication: unacceptable. Stored password: stealable. File level; alpha client is the kiss of death. Entire OS just for mounting?

NFS is not going to fly, but I'm going to seriously investigate CIFS and SSHFS in Debian.

Making CIFS Work

Follow the link for details of my experience with CIFS. To summarize:

I will be very happy if I can use SSHFS and junk CIFS.

SSHFS for Mounting the Homedir

I already decided that SSHFSDroid was unacceptable, but in a forum post I spotted a suggestion to install Debian using DebianKit by Sven-Ola Tuecke, and use Debian's sshfs. Follow the link for the results of the Debian experiment including working command lines and procedures. To summarize:

So far, with limited experience, it looks like I will be able to make SSHFS on Debian my normal mode of mounting my home directory on Android.

Home Directory for Non-Android Clients

It's a solved problem to export my home directory via NFS to real UNIX clients. There are, however, a number of issues that need to be dealt with.

Otter logo image