How to Mount Dirty EXT4 File Systems

As some of you may remember, I've previously written about a technique for mounting EXT3 file system images with the read-only option, even when power was abruptly removed from the system- as is typical during forensic seizure- and the file system is still "dirty". In these cases, my technique involves using an alternate superblock, which will not have the "needs journal recovery" flag set, and using the "-t ext2" option to ignore any entries in the EXT3 file system's journal.

In the last year, however, I've been starting to see cases where I've had to analyze the newer EXT4 file system (hence my recent series of articles on EXT4 internals). It turns out that the technique I developed for mounting EXT3 file systems does not work with EXT4:

# mount -t ext2 -o loop,ro,noexec,sb=131072 ext4-test.img /mnt/test/
mount: wrong fs type, bad option, bad superblock on /dev/loop0,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so
# dmesg | tail -1
[124897.443002] EXT2-fs: loop0: couldn't mount because of unsupported optional features (240).

So, unfortunately, our trick of using "-t ext2" to get the file system drivers to ignore the journal is not going to work for us here, because the EXT2 drivers don't recognize many of the new file system options in EXT4.

So what can we do to mount our EXT4 file systems? When in doubt, refer to the man page:

# man mount
[...]
       -r, --read-only
              Mount the filesystem read-only. A synonym is -o ro.

              Note that, depending on the filesystem type,  state  and  kernel
              behavior, the system may still write to the device. For example,
              Ext3 or ext4 will replay its journal if the filesystem is dirty.
              To prevent this kind of write access, you may want to mount ext3
              or ext4 filesystem with "ro,noload" mount  options  or  set  the
              block device to read-only mode, see command blockdev(8).
[...]
       noload Do not load the ext3 filesystem's journal on mounting.
[...]

The "noload" option looks promising. Let's give it a try:

# file ext4-test.img 
ext4-test.img: Linux rev 1.0 ext4 filesystem data, UUID=... (needs journal recovery) ...
# mount -o loop,ro,noexec,noload ext4-test.img /mnt/test/
# ls /mnt/test
backups  crash  lib    lock  lost+found  opt  spool
cache    games  local  log   mail        run  tmp

You can see the "needs journal recovery" flag in the output of the file command, so our file system is definitely dirty. But happily the "noload" option does indeed allow us to mount the EXT4 file system.

But what about EXT3? The manual page suggests that "noload" will work there as well. Unfortunately, this doesn't appear to be correct:

# file ext3-test.img
ext3-test.img: Linux rev 1.0 ext3 filesystem data, UUID=... (needs journal recovery)
# mount -o loop,ro,noexec,noload ext3-test.img /mnt/test/
mount: wrong fs type, bad option, bad superblock on /dev/loop0,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

# dmesg | tail -1
[126955.823010] ext3: No journal on filesystem on loop0

It appears that the "noload" option does in fact cause the journal not to be loaded. But the EXT3 drivers apparently regard this as an error condition and refuse to do the mount. And before you ask, adding "-t ext2" to the command line above doesn't work either.

So at this point I was stuck with having one method for mounting EXT4 and a different, painful method for mounting EXT3. But then I got an email from Gebhard Zocher, which pointed out a clever solution:

# mount -t ext4 -o loop,ro,noexec,noload ext3-test.img /mnt/test/
# ls /mnt/test
bin   dev  home    lib       mnt  proc  sbinusr
boot  etc  initrd  lost+found  opt  root  tmpvar

Since the EXT4 drivers are backwards compatible with EXT3 file systems, you can just specify "-t ext4" and then use "noload" to mount your EXT3 file systems without mucking around with alternate superblocks. And that means we now have a consistent solution for mounting both EXT3 and EXT4 file systems. Thanks Gebhard!

Hal Pomeranz is an Independent IT/Security Consultant, a SANS Institute Faculty Fellow, and a GCFA. File systems fear him. Hal will be teaching For508: Advanced Computer Forensic Analysis and Incident Response in Baltimore, Oct 9-14.