FreeBSD msdosfs Operations: Mount and Recover FAT Removable Media

FreeBSD’s msdosfs filesystem driver reads and writes FAT volumes commonly found on removable cards, USB storage, firmware update media, and devices exchanged with other operating systems. A mount can expose files successfully while still mapping ownership, permissions, timestamps, or filenames differently from a native Unix filesystem. Treat discovery, partition identification, mount policy, filename conversion, and filesystem repair as separate steps.

The safest first access to unfamiliar media is read-only. This limits accidental changes while the operator verifies the correct partition and copies important data. It does not protect against a failing device, controller, or pre-existing filesystem damage; for valuable evidence or irreplaceable files, image the media with an approved recovery workflow before repeated reads or repairs.

Identify the disk and partition before mounting

Connect the device and record the storage inventory before relying on a name such as da0:

dmesg | tail -80
geom disk list
gpart show -p
camcontrol devlist

The available commands depend on the transport and driver. Compare device model, serial, size, bus, and kernel attach messages. Device names can be reassigned after reconnect or reboot. Never run a formatting or partition command against a guessed disk identifier.

FreeBSD may show an MBR slice using an s-style suffix and a GPT partition with a p-style suffix. The exact path comes from gpart show -p and geom disk list, not from memory. If the disk contains a partition table, mount the specific FAT partition rather than the entire disk. The msdosfs manual documents file -s as one way to inspect a candidate FAT volume:

file -s /dev/da0s1

Replace the example with the actual provider. A file-type probe is useful evidence but not a filesystem health check. If the device has no partition table, determine from the source system or device documentation whether it intentionally contains a filesystem directly on the whole disk.

Create a dedicated mount point and begin read-only:

install -d -m 0755 /mnt/removable
mount -t msdosfs -o ro /dev/da0s1 /mnt/removable
mount
ls -la /mnt/removable

Use the actual partition path. The ro option avoids writes through this mount but does not fix errors on the media. If mounting fails, capture the exact error and kernel messages before retrying with different filesystem types or repair flags. Do not run newfs_msdos on a volume you are trying to recover; it creates a filesystem and can destroy existing metadata.

A passing read-only mount confirms that the kernel could interpret enough of the volume to expose its directory tree. It does not validate every cluster chain or prove that all file contents are intact. Copy critical files to a known-good destination, calculate checksums when appropriate, and compare the copy with its source or manifest. If a file read fails, stop broad traversal and preserve the exact error and device logs rather than retrying all data repeatedly.

When writing is approved, mount the volume read-write only for the work window and unmount cleanly as soon as the transfer completes:

umount /mnt/removable
mount -t msdosfs -o rw /dev/da0s1 /mnt/removable
cp -p /path/to/approved-file /mnt/removable/
sync
umount /mnt/removable

The example is a controlled sequence, not a generic script. Use the exact destination, understand how cp handles metadata that FAT cannot preserve, and confirm the filesystem is not already mounted elsewhere. sync asks the system to flush pending writes but does not replace a successful unmount or a read-back verification. After unmounting, remove and reconnect media only according to the device’s normal procedure, then re-read the copied file or compare a checksum from the mounted volume.

If the workflow needs recurring access, store the policy in an fstab entry with a carefully chosen mount point and noauto when the media is optional. Keep the mount read-only by default when the service only needs to inspect files. For removable disks whose names are unstable, identify a persistent provider through the supported device and GEOM labels, and test that the label resolves after disconnect/reconnect before automating a mount.

Understand permission and ownership mapping

FAT does not store the Unix ownership and permission model of UFS or ZFS. FreeBSD presents files using mount-time owner, group, and mode settings rather than reading per-file POSIX ownership from the volume. This affects what a process can access locally, but it does not create equivalent access controls on the FAT media itself.

For a single-user removable volume, use mount_msdosfs options to choose a local uid, gid, and permission masks only after confirming the command syntax in the installed manual. On an unattended host, do not make a broadly writable mount the default simply for convenience. Removable-media ownership should fit the accounts and service process that need it. A file copied from FAT may also lose metadata such as Unix permissions, ownership, ACLs, extended attributes, and flags.

Use a temporary mount with explicit options to test display behavior, then unmount it before changing the permanent mount configuration. If a persistent device must be mounted at boot, fstab can describe it, but removable hardware may be absent or enumerated under a different device number. Prefer a stable device identity supported by the installed GEOM and device stack; verify that label against the physical device. Add noauto when the volume should not block boot:

/dev/da0s1  /mnt/removable  msdosfs  ro,noauto  0  0

This line is only a template. Replace the provider with the verified persistent device identifier and confirm fstab field semantics for the installed system. Test the entry with a controlled mount and unmount before relying on it during startup. Do not add a guessed USB disk path to fstab on a host whose device enumeration changes.

Handle long filenames and code pages carefully

FAT volumes can contain short DOS names and Windows long filenames. The mounted representation depends on the volume contents, locale, and code-page settings. If names appear with replacement characters, incorrect case, or inconsistent accents, capture the current mount options and inspect the volume from its source system before renaming anything.

mount_msdosfs has locale and DOS code-page options. These are conversion controls, not repair tools. A test mount can specify the correct locale and code page when the data’s origin is known:

mount_msdosfs -L en_US.UTF-8 -D CP437 -o ro /dev/da0s1 /mnt/removable

Do not assume CP437 is correct for every FAT volume; the code page used on the original system must be identified. Avoid the legacy -W table option because the manual retains it only for backward compatibility. The -9 option has a documented risk of filesystem damage in certain cases and should not be used as a casual filename workaround.

Case-insensitivity and name normalization can also differ from applications’ expectations. Two names that are distinct on a native Unix filesystem may not be representable as distinct FAT names. Before copying a large directory tree onto FAT, test filenames for collisions, unsupported characters, length constraints, reserved names, and timestamp precision. Preserve a manifest and compare file counts and checksums after transfer.

FAT timestamps have limited semantics compared with modern Unix filesystems. A copied file’s modification time may have coarser precision or different time-zone interpretation than the source. Do not use FAT metadata alone as a forensic chronology or as a basis for exact incremental-backup decisions. Preserve external manifests or checksums if the transfer must be auditable.

Diagnose mount and write failures in layers

The device does not appear. Check USB enumeration, power, cable, controller, and kernel attach messages. A mounted filesystem cannot be debugged until the device and partition provider exist. Do not repeatedly unplug storage while writes may be in progress.

The disk exists but the partition is missing. Compare the actual partition table with the expected layout. Confirm whether the volume is whole-disk or partitioned and whether the source operating system created an unusual scheme. Do not create a new partition table to make the expected path appear.

The filesystem type is rejected. Verify the provider path and FAT signature, inspect gpart output, and distinguish a corrupted volume from an unsupported or encrypted format. File recognition does not prove safe consistency. Preserve a copy before attempting repair.

Files are visible but cannot be modified. Confirm that the mount is read-write, the mount-point permissions permit access, and the device is not physically write-protected. Then inspect the local uid/gid/mask mapping and filesystem errors. Do not change to rw merely to see whether a failed read-only mount was caused by another issue.

Writes fail or appear truncated. Check free space, device error logs, the receiving device’s format limits, filename compatibility, and whether the application completed and flushed its writes. Unmount cleanly before unplugging, and verify the copied output on a second read or with a checksum.

Check and repair only with a recovery plan

FreeBSD provides fsck_msdosfs to check and repair FAT filesystems. The -n option answers no to repair questions, except the documented continue prompt; it is not a substitute for preserving an image. The -p preen form can repair common inconsistencies non-interactively when invoked through fsck, so do not run it on the only copy of important data without an approved recovery decision. A no-write answer to repair prompts is a useful conservative check, but imaging remains the better first step when the media is valuable or physically suspect.

Before a repair, unmount the filesystem and verify that no process has an open file beneath its mount point:

fstat -f /mnt/removable
umount /mnt/removable
fsck_msdosfs -n /dev/da0s1

Review the installed manual’s behavior and exit status. If repairs are necessary, work on a disk image or duplicate when feasible, record the output, and let the data owner decide which changes to accept. A clean checker exit does not validate every file’s content; compare important files with source checksums or application-level validation.

Avoid forced unmounts, raw writes, newfs_msdos, or repeated repair passes to clear a device-busy condition. Identify the process holding the mount, stop it normally, and unmount. If the media is failing, further scans can worsen recoverability; prioritize imaging and specialist recovery rather than exploratory repair.

Operational acceptance

An accepted removable-media workflow records device identity, partition provider, filesystem type, mount point, access mode, owner/group mapping, code page, and the exact copy or verification test. Start read-only, preserve important data, then allow writes only when the destination and intended changes are approved. Unmount cleanly and verify transfer results before removal.

Include the FreeBSD release, kernel driver, USB transport, volume layout, source-system format, mount options, error messages, and checksums in the change record. FAT interoperability is useful precisely because many systems can read it, but its metadata and durability guarantees differ from FreeBSD-native filesystems. Keep the scope of the volume explicit and do not mistake successful mounting for a complete backup or integrity check.

Related:

Sources: