FreeBSD ext2fs Interoperability: Mount Linux Volumes Without Guesswork

FreeBSD’s ext2fs filesystem driver can access ext2 and derivatives including ext3 and ext4. That is useful when importing a data disk from Linux, retrieving files from a removable drive, or inspecting an image without booting another operating system. It is not a promise that every Linux filesystem feature is supported.

The ext2fs(4) manual says the driver implements most features required by ext3 and ext4, but specifically notes that ext4 extended attributes are experimental and journaling and encryption are not supported. Those limitations should shape the workflow: identify the device, confirm it was cleanly unmounted by its prior operating system, and prefer a read-only mount until the required data is copied and verified.

Inventory the provider before mounting

Do not guess the device node from an old Linux name such as /dev/sdb1. FreeBSD’s device naming and GEOM layers differ. Capture the current disk and partition inventory:

camcontrol devlist -v
gpart show
geom disk list
mount -p

Use serial numbers, capacity, transport, and partition layout to identify the intended disk. A device may already be consumed by a mount, swap device, ZFS pool, mirror, or VM image. Inspect these consumers before mounting or changing anything. If a removable disk is attached while a system is running, compare before-and-after inventory rather than assuming the newest ada or da unit is the target.

Check whether ext2fs is compiled into the kernel or available as a loadable module:

kldstat -v | grep -i ext2fs
kldload ext2fs

If kldload reports that the module is unavailable, verify the exact kernel configuration and release instead of repeatedly retrying. A module may already be compiled into the kernel, and the absence of a separate module listing is not conclusive evidence that the filesystem is unsupported.

Mount conservatively for data extraction

Create a dedicated mountpoint, then mount the identified partition read-only:

install -d -m 0700 /mnt/linux-data
mount -t ext2fs -o ro /dev/ada1p1 /mnt/linux-data
mount -p | grep linux-data
df -h /mnt/linux-data

Replace /dev/ada1p1 only after checking the live partition map. The FreeBSD manual demonstrates the ext2fs mount type; the read-only flag is a conservative operational choice for inspection and copy-out. Confirm the mount options in mount output before opening or copying files.

Use a distinct destination filesystem with sufficient capacity. Preserve metadata only when the destination supports the metadata model being copied; Unix mode bits, ACLs, ownership IDs, extended attributes, case sensitivity, symbolic links, sparse files, and hard links may not map identically to every target. Compare checksums for important files and retain a manifest of source and destination paths.

Check the destination’s free space and inode capacity before starting a large copy. A filesystem can have bytes available but still run out of inodes or hit a file-count limit. If the copy includes a directory tree with millions of small files, estimate both dimensions and monitor them during the transfer. Keep the source read-only and avoid streaming a migration directly into a production service’s live data directory.

For high-value transfers, stage into a newly created directory, compare manifests, and switch the service to the staged tree only after validation. This keeps a partial copy from looking like a complete dataset. If the copy stops due to I/O or media errors, retain the error list, identify the affected source paths, and rerun only after determining whether the problem is transient or indicates source corruption.

Never mount the same filesystem read-write from FreeBSD and Linux at the same time. Concurrent writers can corrupt metadata even if each operating system believes it owns the filesystem. Likewise, a dirty filesystem that still needs journal replay should be repaired by its native Linux tools on Linux, not by guessing at FreeBSD mount options.

Understand ext4 and journal limitations

The FreeBSD manual explicitly says journaling and encryption are not supported by the ext2fs driver. A read-only mount does not replay a Linux ext3 or ext4 journal. If the source was not cleanly unmounted, or if the Linux system reports filesystem errors, stop and use the filesystem’s native check and recovery tools in an appropriate Linux environment before attaching it to FreeBSD.

Ext4 feature flags continue to evolve. A volume created with an unsupported incompat feature may fail to mount or may expose incomplete behavior. The manual’s general statement that most features are implemented is not a compatibility matrix for every ext4 feature. Check the actual filesystem feature flags with tools from the source OS and compare them with current FreeBSD documentation before relying on writes.

Extended attributes in ext4 are called experimental in the FreeBSD manual. Do not use the FreeBSD driver as the authoritative way to update Linux security labels, ACL metadata, or application-specific xattrs. If xattrs matter, preserve the original filesystem and perform metadata-sensitive work through the system and tools that own those semantics.

Encryption is a separate boundary. If the filesystem is encrypted, FreeBSD’s ext2fs driver does not decrypt it for you. Use the correct Linux encryption layer and keys in a controlled environment, unlock the volume through the supported mechanism, and only then inspect the filesystem. Do not format, repair, or overwrite the encrypted provider while diagnosing a missing mount.

Copy data and verify the result

For a simple file transfer to a destination filesystem, use a copy method that preserves required metadata and reports errors. Example:

rsync -aH --numeric-ids /mnt/linux-data/ /srv/import/linux-data/
find /mnt/linux-data -type f -print | wc -l
find /srv/import/linux-data -type f -print | wc -l

Rsync options vary by platform and version; verify the installed rsync manual and destination filesystem capabilities. Numeric ownership preservation may be useful for a forensic or archival copy, but can create numeric owners that have no local account. It is not automatically the right behavior for user-facing data migration.

For higher assurance, generate cryptographic hashes on the source mount and copied destination, normalize their paths, and compare exact entries. Record skipped unreadable files and filesystem errors as exceptions, not as successful migration. A successful command exit from one tool does not prove that ACLs, xattrs, sparse allocation, alternate streams, or application-level structure were retained.

If a directory tree will be used by a service, test a representative workload after copying. Confirm file ownership, permissions, symlink targets, case-sensitive filename collisions, hard-link expectations, and application configuration. Keep the original volume unchanged until the recipient system has passed its own integrity checks and backup process.

Unmount cleanly and preserve evidence

Before unmounting, stop readers and leave the directory:

fstat | grep /mnt/linux-data
umount /mnt/linux-data
mount -p | grep linux-data || true

If unmount reports busy, identify open files, current working directories, and service mounts. Do not force an unmount while a process is reading or writing. After a successful unmount, detach removable hardware through its supported device procedure and compare inventory again.

If the mount fails, save the exact error, kernel messages, release version, partition layout, and filesystem feature information. Do not alternate random mount flags or start a repair utility against a source that may be the only copy. A failed mount can indicate unsupported features, a dirty journal, a wrong partition, encryption, or physical I/O trouble; each requires a different next step.

When a mount appears successful but directories or file names differ from Linux, stop before writing. Verify the mountpoint did not resolve to a different filesystem, confirm the partition number and filesystem type, and compare a small known sample with its original host or image. Do not infer that the driver silently corrected a filesystem from a readable directory listing. Preserve the source and switch to the native Linux tools if directory metadata or journal state is uncertain.

When to use another path

Use Linux as the recovery environment when the filesystem is dirty, depends on ext4 journaling, uses unsupported or uncertain features, or requires metadata preservation beyond the documented FreeBSD implementation. Use a read-only forensic image if chain of custody or repeated analysis matters. For ongoing cross-platform exchange, consider a filesystem or network protocol with explicitly supported semantics on both operating systems rather than repeatedly moving a live Linux data volume.

Before production use, validate representative files from the actual source feature set. Test large files, sparse files, Unicode and case-colliding names, hard links, symbolic links, and expected ownership metadata. Confirm that the mount stays read-only if that is the safety requirement and that the copy manifest matches source and destination.

Acceptance criteria

A safe import is complete when the intended provider was identified by stable hardware and partition evidence, the source was cleanly unmounted, FreeBSD’s supported ext2fs mode was used, all required files were copied and verified, and the original remained untouched until application validation passed. Record unsupported filesystem features and any metadata not preserved.

FreeBSD ext2fs is an interoperability tool, not a guarantee of full Linux ext4 semantics. Treat the installed manual as the support boundary, use Linux for journal-dependent repair, and prefer read-only access for one-time extraction.

Related:

Sources: