Read fs(5) and /proc/filesystems Before You Mount

The fs(5) manual explains what /proc/filesystems can and cannot tell you about mounting a disk. Spend about ten minutes checking what the running kernel actually supports, confirming what is already mounted, and building a mount command instead of guessing the type. The reference is the local fs(5) manual from the Debian manpages package, version 6.7-2: it describes this machine's installed documentation, not a promise that every kernel exposes the same list.

• You need: a shell on a readable Linux system. The inspection steps do not need sudo.
• What changes: nothing, until the final mount example, which is deliberately left as a placeholder until you have verified the device, type and mountpoint.

1. Read what the kernel actually supports

Start with /proc/filesystems. The manual says it lists filesystem types the kernel currently supports. A nodev marker means the type does not need a block device, which is common for virtual filesystems such as proc and tmpfs.

$ cat /proc/filesystems
nodev   proc
nodev   tmpfs
        ext4
        vfat
        overlay

Your output will differ. Keep three things straight:

• No nodev usually means a block device. A type without the marker is normally tied to a disk.
• nodev does not rule out mounting. It just means there is no evidence a disk partition of that type exists.
• The list is a snapshot, not a catalogue. Treat it as the kernel's current capability report, not a history of every filesystem Linux has ever supported.

2. Tell virtual filesystems from disk filesystems

Some entries are kernel interfaces, not stored data. The manual describes proc as a pseudo filesystem whose files expose kernel data and take no disk space, and tmpfs as living in virtual memory, so its contents are not the same thing as persistent files on a disk.

$ findmnt -T /proc
TARGET SOURCE FSTYPE OPTIONS
/proc  proc   proc   rw,relatime

$ findmnt -T /
TARGET SOURCE   FSTYPE OPTIONS
/      /dev/ROOT ext4   rw,relatime

findmnt -T PATH reports the mounted filesystem that contains a path. It is a useful cross-check: /proc/filesystems reports types the kernel can support, findmnt reports the live mount table, and a type can appear in the first without being mounted anywhere.

Do not infer persistence from a familiar name. A successful mount of tmpfs does not make its contents survive a reboot. Mounting an existing disk filesystem, on the other hand, attaches data that may already matter to a service or another user.

3. Check the device before writing a mount command

For a disk or partition, identify the device and its detected type first. This is read-only inspection:

$ lsblk -f
$ findmnt --source /dev/EXAMPLE_PARTITION

• Replace the placeholder from real output. Use /dev/EXAMPLE_PARTITION only after checking what lsblk actually showed, never a guess based on device number or disk order.
• Mounting is not formatting. mount attaches an existing filesystem; mkfs creates a new one and can destroy existing data. This guide never runs mkfs.
• An empty findmnt result is not a green light. If findmnt --source prints nothing, the source is simply not mounted, not safe to format or overwrite.

$ mkdir -p "$HOME/mnt/example"
$ mountpoint "$HOME/mnt/example" || true

If the directory is already a mountpoint, stop and inspect it with findmnt -T "$HOME/mnt/example". Mounting another filesystem over a non-empty directory hides its existing contents until you unmount the new one. Nothing is deleted, but it is an easy source of confusion.

4. Mount the existing filesystem explicitly

The standard form documented by mount(8) is mount -t type device dir. Use the detected type and verified source, never the placeholders literally:

$ sudo mount -t TYPE /dev/EXAMPLE_PARTITION "$HOME/mnt/example"

This is the first command in the guide that normally needs elevated privileges. It changes the live mount namespace and may make data available to any process that can read the directory. Do not run it on a production device or an untrusted filesystem without understanding the permissions and mount options you need. If you only wanted to test support, stop after step 1: there is no reason to mount anything.

Verify the result immediately:

$ findmnt -T "$HOME/mnt/example"
$ df -T "$HOME/mnt/example"

Both should identify the expected mountpoint and filesystem type, though the exact columns and device name will vary. If mount reports an unknown filesystem type, compare the spelling with /proc/filesystems. If the type is listed but the mount still fails, read the complete error, check the device again with lsblk -f, and inspect kernel messages through your normal process. Do not respond to an uncertain error by formatting the device.

5. Undo the temporary mount

Leave the filesystem mounted only if that is the intended configuration. Otherwise detach it from the same mountpoint:

$ sudo umount "$HOME/mnt/example"
$ findmnt -T "$HOME/mnt/example"

• A clean umount is silent. The second command should no longer report the temporary filesystem.
• Busy means something is using it. Find processes with an open file or working directory beneath the mountpoint, close them, then retry. Do not force an unmount just to silence the error; a busy mount may be serving active work.
• Unmounting is not deleting. It only removes the attachment from the directory tree. The directory itself remains, so remove it later only if you created it and no longer need it.

Common traps

• Supported does not mean mounted. Read /proc/filesystems for kernel capability and findmnt for current attachments.
• nodev does not mean broken. It describes how a filesystem is mounted, not whether the type works.
• A missing type is not fixed by sudo. Privilege solves access problems; it cannot add a filesystem implementation to the running kernel.
• Mounting is not formatting. Never substitute mkfs for mount while diagnosing an unknown device.