AuFS (another union file system) allows us to merge two trees into one, even when those trees overlap. We can then direct writes to the merged tree towards one of the branches and reads to another.

The classic use of this is with a flash file system and a ram disk, like this (ref 1) to create a read-only root file system that does not break Linux. All file writes go to ram. After a reboot the system restore itself to the as-shipped configuration.

  • /dir1 = read only
  • /dir2 = read/write
  • /aufs = merge of /dir1 and /dir2

/aufs is then re-mounted with --move to make it / (root)

Simplified, the example in (ref 1) just does this

mount -t aufs br=/dir2:/dir1 /aufs
mount --move /aufs /

However, I want to use it such that the writable (/dir2) is on a real disk, not a ramdisk. That way after a reboot it will retain it's data.

But I need to ensure certain files in dir2 are not preserved and are restored to their (/dir1) defaults. This ensures future boots always use the as-shipped files. Without loosing user and logging data.

e.g. Changed files in /etc, /bin, /boot, /usr should not survive a reboot.

The AUFS web page (ref 2) has very few examples.

So to the question: What is the correct way to do this using AuFS?

I can think of the following:

  1. Modify the first mount command in some way
  2. Add more mount commands using the aufs add/del before second mount
  3. Simply delete the trees that should not be preserved from /dir2 at boot time
  4. Partial tree (etc, bin, boot, lib, etc) in tmpfs

Ref 1: https://help.ubuntu.com/community/aufsRootFileSystemOnUsbFlash
Ref 2: http://aufs.sourceforge.net/aufs.html


Option #1: auFS by itself dosen't support such a mount option, so option #1 is dead. You have to work around that.

Option #3: Of course, you can simply delete at each bootup those directories. It may be the simplest way I see here.

Option #2: You could work with a tmpfs. So first create a tmpfs, let's say of size 500 MB:

mount -t tmpfs -o rw,size=500M tmpfs /tmpfs

We have now:

  • /dir1: read only
  • /dir2: read/write
  • /tmpfs: read/write in RAM
  • /aufs: the overlay of /dir1 and /dir2

Inside /tmpfs, we create those dirs you want to preserve:

mkdir -p /tmpfs/{etc,usr,boot,bin}

Notice, we do that when we already merge the two dirs. So when the directory tree in /aufs already exists. However, now we do one aufs mount per directory that should be preserved:

mount -t aufs -o dirs=/tmpfs/etc=rw:/dir2/etc=ro none /aufs/etc
mount -t aufs -o dirs=/tmpfs/usr=rw:/dir2/usr=ro none /aufs/usr
mount -t aufs -o dirs=/tmpfs/boot=rw:/dir2/boot=ro none /aufs/boot
mount -t aufs -o dirs=/tmpfs/bin=rw:/dir2/bin=ro none /aufs/bin

You have now a directory tree in /aufs wehre you can write files everywhere, but when you write into /etc for example, it will be written into /tmpfs/etc, which is in RAM, therefore doesn't survive a reboot. Other files in /home for example are written to /dir2/home, which is a read-writeable filesystem and therefore survives a reboot.

Another solution: I also use client system that use an overlay filesystem and preserved user data. Here is how I solved it: Simply a read only filesystem and a tmpfs that is mounted over it. Later when the user logs in I mount his home directory from a samba server read-writable. So all his user data is stored and preserved in /home, and the rest doesn't survive a reboot. In your case you could just put /home into another physical partition that is read-writable and mount that later to /aufs/home.

| improve this answer | |
  • Thanks chaos, very helpful. I can't use remote mounts as this is an isolated system. Looks like a text file with a list of dirs to remove at boot will be the best option. I'll implement that and report back. Edited question to include partial tmpfs, though I probably can't use this as there is limited RAM. – Jason Morgan May 22 '15 at 12:31
  • @JasonMorgan It must not be a tmpfs, just a place where you can write. – chaos May 22 '15 at 12:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.