Mount Disks and Flash Drives in Linux

Mounting connects the file system of a disk, a partition or a flash drive to a folder: after the mount, the files of the drive appear in that folder. This page collects the commands that work on any Linux distribution, from the first mount of a flash drive to saving the data of a drive that keeps disconnecting and an /etc/fstab line that mounts a partition at every boot.

The outputs come from one real case: a laptop with Ubuntu 24.04 and a 495 GB USB stick that started to disconnect every 25 seconds while files were being moved to it. The outputs are shortened, the host name is removed and month names are shown in English. How the case went step by step, and the desktop tools of Ubuntu (the Files app, udisksctl, the Disks app), are in Mount disks and USB drives in Ubuntu.

Tools used here: awk, grep, man, systemctl, vi.

Quick start: mount a flash drive

A desktop distribution mounts a flash drive by itself as soon as you plug it in. On a server, in a console, or when the automatic mount does not happen, it takes four steps.

Step 1. Before you plug the drive in, list the drives:

ls /dev/sd*

Step 2. Plug the drive in and run the same command again. The names that were not there before belong to the flash drive: /dev/sdb is the whole drive, /dev/sdb1 the first partition on it. You mount the partition, not the drive.

/dev holds a file for every device the kernel knows. sd comes from SCSI disk; SATA and USB drives get the same names. An NVMe disk is called nvme0n1 with partitions nvme0n1p1, and an SD card in a built-in reader mmcblk0 with mmcblk0p1.

Step 3. Create a folder to mount into. Any empty folder works; /mnt is the traditional place:

sudo mkdir -p /mnt/flashcard

Step 4. Mount the partition:

sudo mount /dev/sdb1 /mnt/flashcard

mount detects the file system itself. To name it, add -t: vfat for FAT32, exfat, ntfs3 or ntfs for NTFS, ext4:

sudo mount -t vfat /dev/sdb1 /mnt/flashcard

Check where it went. The old way, mount | grep sd, still works too.

findmnt /mnt/flashcard

On FAT32, exFAT and NTFS every file mounted with sudo belongs to root, and your user cannot write. These file systems store no Linux owners, so tell mount whose files they are:

sudo mount -o uid=$(id -u),gid=$(id -g) /dev/sdb1 /mnt/flashcard

When you are done:

sudo umount /mnt/flashcard

The command is umount, without the n. Pull the drive out only after it returns; Unmount shows what to do when it says target is busy.

Find the drive: lsblk

lsblk shows every disk with its partitions as a tree. -e7 hides the loop devices that snap packages create by the dozen, and -o picks the columns:

lsblk -e7 -o NAME,SIZE,TYPE,FSTYPE,LABEL,MOUNTPOINTS,MODEL,TRAN,RM,RO

NAME SIZE TYPE FSTYPE LABEL MOUNTPOINTS MODEL TRAN RM RO sda 931,5G disk TOSHIBA MQ01ABD100 sata 0 0 ├─sda1 260M part vfat SYSTEM_DRV /boot/efi 0 0 ├─sda2 16M part 0 0 ├─sda3 466,1G part ntfs Windows 0 0 ├─sda4 187,2G part ext4 /var/snap/firefox/common/host-hunspell 0 0 │ / ├─sda5 11,7G part swap [SWAP] 0 0 ├─sda6 240,2G part ntfs Free 0 0 ├─sda7 25G part ntfs LENOVO 0 0 └─sda8 1000M part ntfs 0 0 sdb 461,3G disk DataTraveler 3.0 usb 1 0 └─sdb1 461G part vfat IMG /media/andrei/IMG 1 0 sr0 1024M rom PLDS DVD-RW DA8AESH sata 1 0

Column	What it tells
NAME	sdb is the drive, sdb1 the partition on it
SIZE	in binary units: 461.3 GiB is the stick sold as about 495 GB. The decimal comma comes from the locale
TYPE	disk, part (partition), rom (optical drive), loop
FSTYPE	the file system: vfat is FAT32, then ntfs, ext4, exfat, swap
LABEL	the name given when the partition was formatted; desktops use it as the folder name
MOUNTPOINTS	where it is mounted; empty means not mounted
MODEL, TRAN	the model and the bus: usb, sata, nvme
RM	1 means removable
RO	1 means read-only at the device level, for example the lock switch of an SD card

The UUID of each file system, which /etc/fstab needs:

lsblk -f -o NAME,FSTYPE,LABEL,UUID /dev/sda

NAME FSTYPE LABEL UUID sda ├─sda1 vfat SYSTEM_DRV C860-DFDC ├─sda2 ├─sda3 ntfs Windows 54FC621CFC61F91E ├─sda4 ext4 b7814b04-33f5-442a-9587-a0fbc6ba12d4 ├─sda5 swap 59ca2341-c177-4785-b213-03098da967eb ├─sda6 ntfs Free 847CC7A37CC78E7C ├─sda7 ntfs LENOVO 82CAB9FECAB9EF13 └─sda8 ntfs 8A5079EF5079E27D

Device names follow the order in which the kernel sees the devices, and they can change. In the case on this page the stick was sdb, dropped out, and for half a minute came back as sdc, because the old sdb was still held by the system: the kernel log shows FAT-fs (sdc1) for those seconds. A UUID belongs to the file system and stays the same, so /etc/fstab uses UUIDs, not names.

Where and how it is mounted: findmnt, df

findmnt /media/andrei/IMG

TARGET SOURCE FSTYPE OPTIONS /media/andrei/IMG /dev/sdb1 vfat rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro

The options column tells the most:

rw: writable; ro would mean read-only.
uid=1000,gid=1000: every file belongs to user 1000, because FAT stores no owners.
fmask=0022,dmask=0022: files are rw-r--r--, folders rwxr-xr-x.
flush: vfat writes the cache to the drive sooner than usual.
errors=remount-ro: on a file system error the kernel switches the mount to read-only.

Only the first option, rw or ro:

findmnt -no OPTIONS /media/andrei/IMG | cut -d, -f1

Size and free space:

df -h /media/andrei/IMG

Filesystem Size Used Avail Use% Mounted on /dev/sdb1 461G 345G 117G 75% /media/andrei/IMG

findmnt without arguments prints the whole tree of mounts. More on free space in Free disk space in Linux.

Useful mount options

Options go after -o, separated by commas without spaces.

Option	Meaning	For
ro, rw	read-only, read-write	all
uid=, gid=	the owner and group of every file	vfat, exfat, ntfs3, ntfs-3g
umask=, fmask=, dmask=	permissions taken away: from files and folders, from files only, from folders only	vfat, exfat, ntfs3, ntfs-3g
noexec	programs on the drive cannot be started	all
nosuid, nodev	ignore set-user-id bits and device files: a safe default for drives you did not format yourself	all
noatime	do not record the time of the last read: fewer writes	all
sync	write at once instead of caching: safer if the drive is pulled out, much slower, and it wears flash memory	all
iocharset=utf8	how file names are decoded, for example Cyrillic names	vfat, ntfs3

A drive you only want to read:

sudo mount -o ro /dev/sdb1 /mnt/flashcard

An NTFS partition with the kernel driver ntfs3, owned by user 1000:

sudo mount -t ntfs3 -o uid=1000,gid=1000,noatime /dev/sda6 /mnt/Free

NTFS has two drivers: ntfs3 in the kernel since 5.15, and the older ntfs-3g, which runs as a FUSE program and is used for -t ntfs. Both read and write. exFAT has a kernel driver since 5.7.

Unmount, target is busy, power off

Linux keeps writes in memory and sends them to the drive later (why that matters). umount writes everything out before it returns, so the rule is simple: pull the drive out only after umount has finished without an error.

sudo umount /mnt/flashcard

umount takes the folder or the device (/dev/sdb1). If a program still has a file open there, or a terminal sits in that folder, it refuses with target is busy. Find out who holds it:

lsof +f -- /mnt/flashcard

fuser -vm /mnt/flashcard

Close that program or leave the folder, then run umount again. umount -l (lazy) detaches the folder at once and finishes when the last file is closed; do not use it before pulling a drive out, writes may still be pending.

After umount a USB drive still has power. This switches it off, like the eject button of a desktop:

udisksctl power-off -b /dev/sdb

udisksctl belongs to udisks2, which most desktop distributions use; see the Ubuntu article.

sync writes everything out without unmounting. How much data is still waiting:

grep -E "^(Dirty|Writeback):" /proc/meminfo

Dirty: 10068 kB Writeback: 0 kB

Dirty is data in memory that no disk has received yet, Writeback is data being written right now. After a large copy to a slow stick, Dirty can stay at hundreds of megabytes for a while.

Protect a drive: remount read-only

When a drive behaves strangely, first stop every write to it. A file manager emptying its trash, a thumbnail generator, a search indexer or a half-finished copy can each make the damage worse. Switch the mount to read-only without unmounting it:

sudo mount -o remount,ro /media/andrei/IMG

Check:

findmnt -no OPTIONS /media/andrei/IMG | cut -d, -f1

Every file can still be opened and copied; nothing can be written or deleted. If a program has a file open for writing, the remount fails with mount point is busy: find the program with lsof as in Unmount. Back to read-write:

sudo mount -o remount,rw /media/andrei/IMG

A drive you do not trust can be mounted read-only from the start with the ro option.

Read the kernel log

Everything the kernel notices about drives goes to the kernel log: a device that appears, disappears, or fails a read or a write. To watch it live, run this and then plug the drive in:

sudo dmesg -w

On a system with systemd the same log is in the journal, with clock times: -k selects the kernel, -b the current boot. Members of the adm group can read it without sudo.

journalctl -k -b | grep -iE "usb|sdb|FAT-fs|I/O error"

Every connect and disconnect of the stick from the case; its USB port is 1-5:

journalctl -k -b | grep -E "usb 1-5: (USB disconnect|new high-speed)"

Oct 24 00:15:21 kernel: usb 1-5: new high-speed USB device number 7 using xhci_hcd Oct 24 00:15:35 kernel: usb 1-5: USB disconnect, device number 7 Oct 24 00:15:41 kernel: usb 1-5: new high-speed USB device number 8 using xhci_hcd Oct 24 01:41:58 kernel: usb 1-5: USB disconnect, device number 8 Oct 24 01:41:59 kernel: usb 1-5: new high-speed USB device number 9 using xhci_hcd Oct 24 01:42:26 kernel: usb 1-5: USB disconnect, device number 9 Oct 24 01:42:27 kernel: usb 1-5: new high-speed USB device number 10 using xhci_hcd Oct 24 01:42:52 kernel: usb 1-5: USB disconnect, device number 10 Oct 24 01:42:53 kernel: usb 1-5: new high-speed USB device number 11 using xhci_hcd Oct 24 01:43:17 kernel: usb 1-5: USB disconnect, device number 11 Oct 24 01:43:17 kernel: usb 1-5: new high-speed USB device number 12 using xhci_hcd

At 00:15 the stick was plugged in, pulled out and plugged in again by hand. From 01:41:58 it dropped out by itself four times in 80 seconds and came back within a second each time, faster than a person could replug it. That points at a loose contact or at the stick resetting itself.

What happened in one of those seconds:

Oct 24 01:43:17 kernel: usb 1-5: USB disconnect, device number 11 Oct 24 01:43:17 kernel: device offline error, dev sdb, sector 241913376 op 0x1:(WRITE) flags 0x4800 phys_seg 2 prio class 2 Oct 24 01:43:17 kernel: Buffer I/O error on dev sdb1, logical block 201354368, lost async page write Oct 24 01:43:17 kernel: FAT-fs (sdb1): unable to read inode block for updating (i_pos 3221669899) Oct 24 01:43:17 kernel: FAT-fs (sdb1): Directory bread(block 241448064) failed Oct 24 01:43:17 kernel: FAT-fs (sdb1): bread failed in fat_clusters_flush Oct 24 01:43:20 kernel: sd 2:0:0:0: [sdb] 967311360 512-byte logical blocks: (495 GB/461 GiB) Oct 24 01:43:20 kernel: FAT-fs (sdb1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.

Line	Meaning
USB disconnect	the device left the bus: pulled out, a loose contact, too little power, or the drive reset itself
new high-speed USB device	it is back. high-speed means USB 2.0, about 30 MB/s in the case; USB 3 shows SuperSpeed
device offline error ... (WRITE)	a write was sent to a device that is gone
Buffer I/O error ... lost async page write	data that a program had already been told was written never reached the drive (why)
FAT-fs ... bread failed, FAT read failed	the file allocation table, the map of where each file lies, could not be read or written
Volume was not properly unmounted	the file system was in use when the drive vanished: check it with fsck after the backup

How many times a drive dropped out since boot:

journalctl -k -b | grep -c "USB disconnect"

Why a finished copy can still be lost

A program that writes a file hands the data to the kernel and goes on. The kernel keeps the data in memory, in the page cache, and writes it to the drive within seconds, or, for a slow USB stick, sometimes minutes later. A copy dialog that says done, or a cp that has returned, does not mean the data is on the drive. sync and umount wait until it is.

That makes a move risky. Moving a file to another file system is a copy followed by deleting the original. If the drive disappears after the copy has been reported done but before the data has been written, the original is gone and the copy is incomplete.

In the case, a file manager moved a folder of course videos from the laptop to the stick. The first video, 1.09 GB, was reported copied and deleted from the laptop; then the stick dropped out with lost async page write in the log. On the stick the file had its full size, but from about a third onward it held only zeros. The next chapter shows how that was found.

The safe way is to copy, compare and delete only then: Move files safely.

Check a file for lost writes

After lost writes a file usually keeps its full size; the blocks that never arrived read as zeros or as old data. Real photos, videos and archives never contain a whole megabyte of zeros, so a quick test is to read chunks spread across the file and count the ones that are all zeros. The Python script below reads 40 chunks of 1 MB, so it is fast even for big files and gentle on a weak drive.

vi zero_chunks.py

"""Count 1 MB chunks of a file that hold only zeros: writes that never arrived.""" import os import sys SAMPLES = 40 CHUNK = 1 << 20 def zero_chunks(path: str) -> int: """Read SAMPLES chunks spread over the file, return how many are zeros.""" size = os.path.getsize(path) zeros = 0 with open(path, "rb") as handle: for i in range(SAMPLES): handle.seek(size * i // SAMPLES) chunk = handle.read(CHUNK) if chunk and chunk.count(0) > len(chunk) * 0.98: zeros += 1 print(f" chunk at {i * 100 // SAMPLES}% is zeros") return zeros if __name__ == "__main__": found = zero_chunks(sys.argv[1]) print(f"{found}/{SAMPLES} sampled chunks are zero-filled")

The moved video from the case:

python3 zero_chunks.py "/media/andrei/IMG/Courses/Data Scientist/1. Базовые инструменты анализа данных в Python/DataScientist-2018-08 - 23.08.2018.mp4"

chunk at 32% is zeros chunk at 35% is zeros chunk at 37% is zeros ... chunk at 95% is zeros chunk at 97% is zeros 27/40 sampled chunks are zero-filled

Everything from about 32% on never reached the stick. A healthy video from the same course gives 0/40.

A zip archive has a full test: unzip -t reads every file inside and checks its CRC.

unzip -tq /media/andrei/Free/aredel_2026-10-24.zip

No errors detected in compressed data of /media/andrei/Free/aredel_2026-10-24.zip.

A video can be decoded from start to end with ffmpeg, which then prints only the errors:

ffmpeg -v error -i video.mp4 -f null -

And if the original still exists somewhere, cmp compares byte by byte: it prints the first difference, or nothing when the files are equal.

cmp original.mp4 /media/andrei/IMG/copy.mp4

Back up a drive with rsync

When a drive is unreliable, copy what matters off it before you try anything else: before fsck, before formatting, before a second attempt at the move. Copy from a read-only mount. rsync is better for this than cp or a file manager: it can be stopped and started again, continues where it stopped, and logs every file.

rsync -rt --partial --info=progress2 --log-file=card_backup.log /media/andrei/IMG/IMG /media/andrei/IMG/DCIM /media/andrei/Windows/Card_backup_2026-10-24/

Part	Why
-r	recursive: folders with everything in them
-t	keep modification times; needed for the quick comparison later
no -a	-a also copies owners and permissions. FAT, exFAT and NTFS mounts cannot store them, so the log would fill with errors
--partial	keep a half-copied file, so the next run continues it
--info=progress2	one line with the total progress
--log-file	every copied file and every error in a file
no slash after IMG	copies the folder IMG itself into the target; IMG/ would copy only its contents

If the drive drops out in the middle, rsync stops with an error. Wait until the drive is back, make it read-only again and run the same command: files already copied are skipped by their size and time.

In the case, 337 GB in about 58,000 files took three hours at about 31 MB/s, without a single disconnect. The last line of the log:

2026/10/24 04:56:14 [167168] sent 337531149267 bytes received 1112500 bytes total size 337445407735

Check 1: the same number of files and bytes.

find /media/andrei/IMG/DCIM -type f | wc -l

find /media/andrei/Windows/Card_backup_2026-10-24/DCIM -type f | wc -l

find /media/andrei/IMG/DCIM -type f -printf "%s\n" | awk '{s+=$1} END {print s}'

Do not compare with du: it counts whole clusters, and FAT and NTFS use different cluster sizes. For the same files du -sh showed 291G on the stick and 289G in the backup. The case gave:

Folder	On the stick	In the backup
IMG	56,560 files, 309,548,327,992 bytes	56,560 files, 309,548,327,992 bytes
DCIM	1,653 files, 27,897,079,743 bytes	1,653 files, 27,897,079,743 bytes

Check 2: no file differs in size or time. A dry run of rsync lists what it would still copy:

rsync -rtn --modify-window=1 --out-format=%n /media/andrei/IMG/IMG /media/andrei/IMG/DCIM /media/andrei/Windows/Card_backup_2026-10-24/ | grep -v "/$"

-n only shows and copies nothing, --modify-window=1 allows for FAT, which stores times in 2-second steps, and grep drops the lines of folders. No output means nothing is missing or different.

Check 3: the contents. rsync already checks a checksum of every file it transfers. A byte-by-byte comparison afterwards, with diff -rq as in the next chapter or with sha256sum, reads everything again; on a weak drive run it only once the copy is safe.

Move files safely: copy, compare, delete

Instead of a move in the file manager, or mv to another drive: copy, compare, delete. It takes longer, but the original is deleted only when the copy has been proven equal.

rsync -rt /home/andrei/Videos/Courses /media/andrei/Free/

diff -rq /home/andrei/Videos/Courses /media/andrei/Free/Courses

diff -rq prints one line for every file that differs or exists on one side only, and nothing when both trees are identical. In the case: 15 GB, no output. Only then:

rm -rf /home/andrei/Videos/Courses

rsync --remove-source-files deletes each original right after its transfer, before you have compared anything, and leaves the empty folders behind. For valuable data the three steps are safer.

Files over 4 GB on FAT32

FAT32, the format of most USB sticks and SD cards, cannot hold a file of 4 GiB or more: the largest file is 4,294,967,295 bytes. A copy of a bigger file stops with File too large. Either format the drive as exFAT, which erases it, or cut the file into pieces. In the case a 4.77 GB zip went to the stick in two pieces of at most 3900 MiB:

mkdir -p /media/andrei/IMG/aredel_backup_2026-10-24

split -b 3900M /media/andrei/Free/aredel_2026-10-24.zip /media/andrei/IMG/aredel_backup_2026-10-24/aredel_2026-10-24.zip.part-

ls -l /media/andrei/IMG/aredel_backup_2026-10-24

total 4662400 -rw-r--r-- 1 andrei andrei 4089446400 Oct 24 10:56 aredel_2026-10-24.zip.part-aa -rw-r--r-- 1 andrei andrei 684749786 Oct 24 11:01 aredel_2026-10-24.zip.part-ab -rw-r--r-- 1 andrei andrei 397 Oct 24 11:05 README.txt

README.txt next to the pieces says how to join them, for whoever finds the stick later. To rebuild the file, in the folder with the pieces:

cat aredel_2026-10-24.zip.part-* > aredel_2026-10-24.zip

Check that the pieces on the stick give exactly the original. Right after writing, a read may still come from the page cache in memory instead of from the stick, so unmount and mount the stick before the check:

sha256sum /media/andrei/Free/aredel_2026-10-24.zip

udisksctl unmount -b /dev/sdb1

udisksctl mount -b /dev/sdb1

cat /media/andrei/IMG/aredel_backup_2026-10-24/aredel_2026-10-24.zip.part-* | sha256sum

39bad97bd39905ecd8a29d93810b162d143caac9fb752c4599647c27911e0917 -

Both commands printed this sum: the copy on the stick is complete. Without udisks, use sudo umount and sudo mount, or drop the cache instead:

echo 3 | sudo tee /proc/sys/vm/drop_caches

zip can split by itself (zip -s 3g). Most programs open such an archive only after zip -s 0 has joined it, while cat works for any file.

Check and repair the file system

fsck checks the structure of a file system and repairs it. Two rules: run it only on an unmounted partition, and only after the backup, because a repair can delete what it cannot fix.

Check only, change nothing (-n):

sudo umount /dev/sdb1

sudo fsck.vfat -n /dev/sdb1

Repair:

sudo fsck.vfat -a /dev/sdb1

In this automatic mode fsck.vfat saves lost chains of data as FSCK0000.REC, FSCK0001.REC and so on in the root folder of the drive.

File system	Check only	Package
FAT32	sudo fsck.vfat -n /dev/sdb1	dosfstools
exFAT	sudo fsck.exfat -n /dev/sdb1	exfatprogs
ext4	sudo e2fsck -n /dev/sdb1	e2fsprogs
NTFS	sudo ntfsfix -n /dev/sda6	ntfs-3g; it fixes only basic problems and marks the volume for chkdsk at the next Windows start

A failing or fake drive

A drive that keeps failing. If even reading files fails, copy the whole drive block by block with GNU ddrescue: it reads the good areas first, skips the bad ones and returns to them later, and its map file lets you stop and continue. It needs free space for the entire drive, not only the used part: 495 GB for the stick from the case.

sudo ddrescue -n /dev/sdb /media/andrei/Free/stick.img /media/andrei/Free/stick.map

The second pass retries the bad areas three times:

sudo ddrescue -r3 /dev/sdb /media/andrei/Free/stick.img /media/andrei/Free/stick.map

Then work with the image, not with the drive. losetup -P turns the image into a loop device with partitions and prints its name:

sudo losetup -fP --show /media/andrei/Free/stick.img

If it prints /dev/loop30, the first partition is /dev/loop30p1:

sudo mount -o ro /dev/loop30p1 /mnt/flashcard

A fake drive. Some sticks report more capacity than they have, and writes beyond the real capacity overwrite earlier data or vanish. Signs: a famous brand at an unusual capacity and a low price, and files that are fine at first and damaged later. f3 tests it: f3write fills the free space with test files and f3read reads them back. Existing files stay untouched, but the whole free space gets written, so run it after the backup:

f3write /media/andrei/IMG

f3read /media/andrei/IMG

Remove the test files afterwards: 1.h2w, 2.h2w and so on. f3probe --destructive is faster but erases the drive.

Mount an ISO or a disk image

An ISO file mounts like a drive through a loop device:

sudo mkdir -p /mnt/iso

sudo mount -o loop,ro ubuntu-24.04.5-desktop-amd64.iso /mnt/iso

An ISO is read-only anyway; ro saves a warning. An image of a whole disk with a partition table needs losetup -P as in the previous chapter. Unmount it with sudo umount /mnt/iso.

Mount at boot: /etc/fstab

/etc/fstab lists the file systems to mount at boot, one per line. The example mounts the NTFS partition Free from the lsblk output at /mnt/Free. A desktop can write the same line for you: see the Disks app in the Ubuntu article.

Step 1: the UUID. From lsblk -f above, 847CC7A37CC78E7C for sda6, or:

sudo blkid /dev/sda6

Step 2: the folder.

sudo mkdir -p /mnt/Free

Step 3: a copy of the file, to go back to if anything fails:

sudo cp /etc/fstab /etc/fstab.bak

Step 4: the line. Open the file:

sudo vi /etc/fstab

and add at the end:

UUID=847CC7A37CC78E7C /mnt/Free ntfs3 nosuid,nodev,nofail,uid=1000,gid=1000 0 0

1000 is the user and group id of the first user; yours are printed by id -u and id -g. Each field is explained in fstab fields and options.

Step 5: check the file.

sudo findmnt --verify --verbose

findmnt checks every line: that the device exists, that the folder exists, and that the options parse. A line can be tested before it goes into /etc/fstab: put it alone into a file and pass the file with --tab-file; no sudo needed. Here the folder from step 2 did not exist yet:

findmnt --verify --verbose --tab-file fstab.test

0 parse errors, 1 error, 1 warning /mnt/Free [E] unreachable on boot required target: No such file or directory [ ] VFS options: nosuid,nodev [ ] FS options: uid=1000,gid=1000 [ ] userspace options: nofail,x-gvfs-show,x-gvfs-name=Free [ ] UUID=847CC7A37CC78E7C translated to /dev/sda6 [ ] source /dev/sda6 exists [W] cannot detect on-disk filesystem type (Permission denied)

[E] is an error to fix before you reboot: here the missing /mnt/Free. [W] is a warning: without sudo findmnt cannot read the disk to detect its type. The test line also had the two x-gvfs options of the Ubuntu version.

Step 6: tell systemd. systemd turns the lines of /etc/fstab into mount units. After an edit it needs a reload, otherwise mount warns that systemd still uses the old version:

sudo systemctl daemon-reload

Step 7: free the partition. If a desktop has already mounted it somewhere else, unmount it there:

sudo umount /dev/sda6

Step 8: mount everything from fstab that is not mounted yet. An error here would have been an error at boot.

sudo mount -a

findmnt /mnt/Free

Step 9: reboot and run findmnt /mnt/Free once more.

fstab fields and options

Field	Example	Meaning
1. device	UUID=847CC7A37CC78E7C	which file system; LABEL=Free also works, a /dev/sdX name can change
2. mount point	/mnt/Free	an existing folder
3. type	ntfs3	ext4, vfat, exfat, ntfs3, ntfs (ntfs-3g), auto
4. options	nosuid,nodev,nofail,uid=1000,gid=1000	comma separated, without spaces; defaults when there are none
5. dump	0	an old backup tool; always 0
6. pass	0	fsck order at boot: 1 for /, 2 for other ext4 partitions, 0 for NTFS and FAT

Options that matter in /etc/fstab, in addition to the mount options:

Option	Meaning
nofail	boot on if the device is missing or fails to mount. Put it on every line except the system partitions
noauto	do not mount at boot; mount /mnt/Free mounts it later with the options from the line
x-systemd.automount	mount at the first access to the folder instead of at boot
x-systemd.device-timeout=5s	how long boot waits for the device; the default is 90 seconds
x-systemd.idle-timeout=10min	with automount: unmount after ten minutes without use
user, users	a normal user may mount it: mount /mnt/Free without sudo
x-gvfs-show, x-gvfs-name=	for desktops with GVfs, such as GNOME: show it in the file manager under a name; see the Ubuntu article

An ext4 data disk. ext4 stores owners itself, so no uid=; give the mounted folder to your user once with sudo chown:

UUID=<uuid of the partition> /mnt/data ext4 defaults,nofail 0 2

A USB stick that is not always plugged in: mounted on first access, and boot waits at most five seconds for it:

UUID=<uuid of the stick> /mnt/stick vfat noauto,nofail,x-systemd.automount,x-systemd.device-timeout=5s,uid=1000,gid=1000 0 0

One partition for several users

uid= and gid= give every file to one user. For a second account to write too, create a group, put both users in it and give the files to the group:

sudo groupadd shared

sudo usermod -aG shared andrei

sudo usermod -aG shared user2

getent group shared

The third field of the output is the group id, for example 1002 in shared:x:1002:andrei,user2. Use it in the line:

UUID=847CC7A37CC78E7C /mnt/Free ntfs3 nosuid,nodev,nofail,uid=1000,gid=1002,fmask=0113,dmask=0002 0 0

fmask=0113 makes files rw-rw-r--, dmask=0002 makes folders rwxrwxr-x: the owner and the group write, everyone else reads. Group membership takes effect at the next login.

When fstab stops the boot

Without nofail, a disk from /etc/fstab that is missing or broken stops the boot: systemd waits for it and then shows You are in emergency mode. To fix it:

1. Enter the root password. On a system without one, such as Ubuntu, boot recovery mode and choose root.

2. Make the system partition writable:

mount -o remount,rw /

3. Put the copy from step 3 back, or put a # in front of the new line:

cp /etc/fstab.bak /etc/fstab

4. Restart:

reboot

Debian Manual	My first experience with Debian (RUS)	Debian_FAQ	How to use memorystick Linux	Virtual Windows 7 on Debian
How to use memorystick Linux	Virtual Windows 7 on Debian
Debian_FAQ