Contents

Linux 掛載硬碟另類方法

在 Linux 系統管理裡,掛載硬碟看起來像是基本功,但真的遇到外接硬碟、USB、SD 卡、NAS 或 NFS 時,選錯方法很容易把自己搞到開機變慢、服務卡住,甚至一拔裝置就滿地錯誤。

我以前比較常直接用 /etc/fstab,後來在不同情境下才慢慢發現,其實 systemdudeviludev,甚至 autofs 都各有適合的使用場景。這篇就把幾種常見做法整理成一篇,順便補上我自己覺得比較實用的踩雷心得。

先講結論
固定接在機器上的本機硬碟,優先考慮 /etc/fstabsystemd 掛載;可移動裝置偏向 udeviludev;如果是 NFS 這類網路檔案系統,我反而更推薦 autofs 這種按需掛載做法,會穩很多。

文章重點心智圖

mindmap root((Linux 掛載硬碟方法)) fstab 最傳統 開機自動掛載 固定硬碟最好用 設錯可能卡開機 systemd 依賴管理清楚 支援 automount 適合服務型主機 udevil 一般使用者可操作 devmon 可自動掛載 適合桌面與 USB udev 事件驅動 可客製規則 適合熱插拔裝置 autofs 按需掛載 適合 NFS 可避免系統卡死

為什麼要分情境選掛載方法

同樣是「把硬碟掛上去」,背後情境其實差很多:

  1. 固定掛在主機裡的資料碟,通常追求穩定與開機即用。
  2. USB 隨身碟或 SD 卡這類熱插拔裝置,比較在意插上就能用、拔掉也別出事。
  3. NFS、CIFS 這類網路磁碟,最大風險不是設定麻煩,而是遠端主機失聯時會拖垮本機 I/O。

所以與其問哪一種最好,不如先問自己要解決哪一種場景。

我自己的快速選擇

情境 建議方法 原因
固定本機硬碟 /etc/fstab 最直觀、最常見、維護成本低
需要依賴網路或服務順序 systemd mount 相依關係與日誌比較清楚
桌面環境 USB 自動掛載 udevil + devmon 使用者層級比較方便
想依裝置事件自動處理 udev 客製化能力高
NFS 或不穩定網路磁碟 autofs 按需掛載,較不容易拖垮系統

方法一:/etc/fstab

實戰

我之前在另一篇 2023 年樹莓派重裝 Flexget 其實就有用過 fstab 來做自動掛載。對固定接在機器上的資料碟來說,這招真的夠用。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
# 建立掛載點
sudo mkdir -p /media/extHDD

# 先手動掛載一次確認裝置沒問題
sudo mount /dev/sda1 /media/extHDD

# 查詢 UUID
sudo blkid
# /dev/sda1: UUID="4411c5bb-2392-45d8-a7ba-7b40275a84fd" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="42f5e0d3-01"

# 編輯 /etc/fstab
sudo nano /etc/fstab

/etc/fstab 裡加上:

1
UUID=4411c5bb-2392-45d8-a7ba-7b40275a84fd /media/extHDD ext4 rw,defaults,nofail 0 0

最後記得測試:

1
2
sudo mount -a
df -h

這個方法在做什麼

/etc/fstab 是 Linux 傳統的檔案系統表,系統開機時會依照這份清單決定哪些檔案系統要掛載到哪裡。

標準格式是:

1
<file system> <dir> <fs-type> <options> <dump> <pass>

常見欄位意義如下:

  • <file system>:裝置路徑、UUID 或 LABEL。
  • <dir>:掛載點。
  • <fs-type>:檔案系統類型,例如 ext4xfsntfs
  • <options>:掛載選項。
  • <dump>:是否提供給 dump 備份工具使用。
  • <pass>:開機時 fsck 檢查順序。

常用掛載選項

  • defaults:預設選項組合。
  • rw:可讀寫。
  • ro:唯讀。
  • auto:開機或 mount -a 時自動掛載。
  • noauto:不自動掛載。
  • nofail:掛載失敗也不要影響系統啟動。
  • _netdev:宣告這是網路檔案系統。
  • x-systemd.automount:首次存取時才真正掛載。
  • x-systemd.device-timeout=15s:等待裝置時間上限。

設定步驟

  1. 先用 lsblksudo fdisk -l 找到裝置名稱。
  2. sudo blkid /dev/sdXN 取得 UUID 與檔案系統類型。
  3. 建立掛載點,例如 sudo mkdir -p /mnt/mydata
  4. 編輯 /etc/fstab,新增一行掛載設定。
  5. sudo mount -a 測試設定是否正確。
  6. df -hTlsblkfindmnt /mnt/mydata 驗證結果。

優點與缺點

優點:

  • 設定簡單,是最常見也最好維護的方式。
  • 很適合固定長期存在的本機硬碟。
  • 搭配 x-systemd.automount 也能做出類似按需掛載效果。

缺點:

  • 設定錯了真的有機會讓系統卡在開機流程。
  • 對常插拔的裝置不夠彈性。
  • 網路磁碟若沒配好 _netdevnofail 等選項,開機時很容易卡很久。
這裡最常踩雷
fstab 最怕的不是語法難,而是太相信自己沒有打錯 UUID。寫完一定要先跑一次 sudo mount -a,不要等到重開機才驗證。

方法二:systemd 掛載

如果你希望掛載動作能和其他服務有明確依賴關係,例如要等網路好了才掛 NFS,或要做 automount,那 systemd 通常會比單純寫 fstab 更清楚。

實戰

以下示範把 /dev/sdb1 掛到 /mnt/mydata

先建立 .mount 單元:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
# /etc/systemd/system/mnt-mydata.mount
[Unit]
Description=Mount MyData Partition

[Mount]
What=/dev/disk/by-uuid/YOUR_DEVICE_UUID
Where=/mnt/mydata
Type=ext4
Options=defaults,nofail

[Install]
WantedBy=multi-user.target

如果想要按需掛載,再建立 .automount

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
# /etc/systemd/system/mnt-mydata.automount
[Unit]
Description=Automount MyData Partition

[Automount]
Where=/mnt/mydata
# TimeoutIdleSec=300

[Install]
WantedBy=multi-user.target

重新整理設定並啟用:

1
2
3
4
5
6
7
8
9
sudo systemctl daemon-reload

# 開機即掛載
sudo systemctl enable mnt-mydata.mount
sudo systemctl start mnt-mydata.mount

# 或者改用按需掛載
sudo systemctl enable mnt-mydata.automount
sudo systemctl start mnt-mydata.automount

驗證狀態:

1
2
3
systemctl status mnt-mydata.mount
systemctl status mnt-mydata.automount
df -hT /mnt/mydata

優點與缺點

優點:

  • 相依關係好管理,特別適合服務型主機。
  • 日誌可直接看 journalctl,問題比較好追。
  • automount 對不常用的磁區或網路磁碟很實用。

缺點:

  • 設定比 fstab 稍微長一點。
  • 如果 What= 直接寫 /dev/sdX,重開後裝置名稱改掉就麻煩了。
  • 對沒碰過 systemd 單元的人來說,學習成本稍高。

方法三:udevil

如果你的需求是「一般使用者方便掛載 USB 或光碟」,udevil 會比直接碰系統層設定來得輕鬆。

udevildevmon 的分工

  • udevil:讓一般使用者也能依規則掛載或卸載裝置。
  • devmon:常駐監聽裝置變化,偵測到插入時自動呼叫 udevil

安裝與基本用法

1
2
sudo apt-get update
sudo apt-get install udevil

手動掛載:

1
2
udevil mount /dev/sdb1
udevil mount /dev/sdb1 /media/myusb

卸載:

1
2
udevil umount /dev/sdb1
udevil umount /media/myusb

啟動 devmon

在使用者登入後自動啟動:

1
devmon &

如果要改成 systemd 方式啟用:

1
systemctl enable devmon@$(whoami)

常見附加選項:

1
2
devmon --exec-on-mount "thunar %d" &
devmon --mount-options "noatime,nodiratime" &

udevil.conf 常看欄位

  • allowed_devices:允許掛載哪些裝置。
  • allowed_internal_devices:是否允許內部磁碟被一般使用者掛載。
  • allowed_types:允許哪些檔案系統類型。
  • allowed_media_dirs:掛載點允許建立在哪些目錄。
  • default_options_FILESYSTEMTYPE:針對指定檔案系統給預設掛載選項。

優點與缺點

優點:

  • 對桌面使用者很方便。
  • 不用每次都 sudo
  • 可移動裝置的使用體驗通常不錯。

缺點:

  • 大多綁定在使用者會話,沒登入就不一定會自動處理。
  • 可能和桌面環境內建自動掛載機制重疊。
  • 若牽涉 SUID 設定,安全上要多看一眼。
我的看法
如果你本來就在 GNOME 或 KDE 上,很多時候其實桌面環境已經幫你處理得不錯。udevil 比較適合輕量桌面、純視窗管理器,或你想要自己掌控規則的情境。

方法四:udev

如果想要在裝置插入或移除時直接觸發指定動作,udev 就是更底層、更硬派的做法。

實戰

先建立規則檔:

1
sudo nano /etc/udev/rules.d/99-usb-automount.rules

範例規則如下:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
# add USB
ACTION=="add", SUBSYSTEM=="block", ENV{DEVTYPE}=="partition", SUBSYSTEMS=="usb", \
	ENV{MOUNT_PATH}="/media/$env{ID_FS_LABEL_ENC}-$env{ID_PART_TABLE_UUID}", \
	RUN+="/bin/mkdir -p '$env{MOUNT_PATH}'", \
	RUN+="/bin/systemd-mount -o relatime,sync,umask=022 --no-block --collect $env{DEVNAME} '$env{MOUNT_PATH}'"

# add SD
ACTION=="add", SUBSYSTEM=="block", ENV{DEVTYPE}=="partition", ATTRS{type}=="SD", \
	ENV{MOUNT_PATH}="/media/$env{ID_FS_LABEL_ENC}-$env{ID_PART_TABLE_UUID}", \
	RUN+="/bin/mkdir -p '$env{MOUNT_PATH}'", \
	RUN+="/bin/systemd-mount -o relatime,sync,umask=022 --no-block --collect $env{DEVNAME} '$env{MOUNT_PATH}'"

# remove
ACTION=="remove", SUBSYSTEM=="block", ENV{DEVTYPE}=="partition", \
	ENV{MOUNT_PATH}="/media/$env{ID_FS_LABEL_ENC}-$env{ID_PART_TABLE_UUID}", \
	RUN+="/bin/systemd-mount --umount '$env{MOUNT_PATH}'", \
	RUN+="/bin/rmdir $env{MOUNT_PATH}"

重載規則:

1
2
sudo udevadm control --reload-rules
sudo udevadm trigger

更完整的思路

撰寫 udev 規則前,建議先抓裝置屬性:

1
sudo udevadm info -a -p $(udevadm info -q path -n /dev/sdb1)

你通常會關注這幾個欄位:

  • ACTION
  • SUBSYSTEM
  • ENV{DEVTYPE}
  • ENV{ID_FS_UUID}
  • ATTRS{idVendor}
  • ATTRS{idProduct}

為什麼現在比較常搭配 systemd

在現代 Linux 上,直接在 udev 裡用 RUN+= 去做複雜掛載,不一定是最穩定的做法。比較實務的方式,通常是讓 udev 負責辨識事件,再交給 systemd 服務處理真正的掛載流程。

例如:

1
ACTION=="add", KERNEL=="sd[a-z][0-9]*", SUBSYSTEM=="block", ENV{ID_FS_UUID}=="YOUR-UUID", TAG+="systemd", ENV{SYSTEMD_WANTS}="usb-mount@%k.service"

這樣的好處是除錯比較清楚,也比較不容易踩到 udev 執行環境的限制。

優點與缺點

優點:

  • 事件驅動,客製化能力很高。
  • 很適合處理熱插拔裝置。
  • 可以依照裝置屬性做精準判斷。

缺點:

  • 規則不好寫時,除錯成本偏高。
  • 維護門檻比 fstabudevil 都高。
  • 若直接在規則裡塞太多邏輯,之後很容易忘記自己當初在幹嘛。

補充:為什麼 NFS 比較適合 autofs

原本我也會想說,既然 mount 可以掛 NFS,直接寫死不就好了?後來才慢慢理解,NFS 的真正問題不在「能不能掛」,而是在遠端主機出問題時,整台機器會一起被拖慢。

問題核心

NFS 是透過網路連線的遠端檔案系統。當你把它掛到本機目錄後,系統會把它當成一顆本機磁碟來操作。問題在於,這顆磁碟其實是靠網路活著的。

當 NFS Server 掛掉、網路中斷、名稱解析失敗或 IP 改了,本機對掛載點的存取就會卡在等待 RPC 回應。這種等待通常是阻塞式的,所以影響的不只是那個目錄:

  • lscatcp 可能卡住。
  • 開機中的某些服務也可能一起等。
  • 使用者登入後,shell 或桌面環境可能變慢。
  • 某些 daemon 會被拖累,整體系統體感很差。

autofs 為什麼比較穩

autofs 是按需掛載。只有真的進入某個目錄或存取檔案時,它才會去做掛載。

好處有兩個:

  1. 平常不會硬掛在那裡,不容易拖慢整體系統。
  2. 遠端主機不在時,通常是那次存取失敗,不會把整台主機一起卡住。

小實驗

你可以自己試試看:

  1. 先用一般 mount 掛一個 NFS 目錄。
  2. 把 NFS Server 關掉,或直接拔網路。
  3. 在 client 上執行 ls /mnt/nfs/centos7
  4. 通常你會看到它卡很久。
  5. 改成 autofs 後,再做一次相同操作,體感通常差很多。
NFS 的實務建議
如果你不是很確定遠端檔案系統的穩定度,寧可先選擇 autofsx-systemd.automount 這類按需掛載方案,也不要一開始就把它當本機固定硬碟硬掛上去。

總結

Linux 的掛載方式沒有唯一正解,只有適不適合你的情境。

如果你今天是在管理固定本機資料碟,/etc/fstab 依然是最務實的選擇;如果你需要更清楚的依賴管理,那就考慮 systemd;如果你是在桌面環境處理 USB 或 SD 卡,udeviludev 會更靈活;至於 NFS 這種網路檔案系統,我自己會優先考慮按需掛載,因為真的比較不容易把整台主機一起拖下水。

重點不是會不會掛,而是掛上去之後,出問題時你的系統還能不能好好活著。

參考資料