挂载前须确认设备节点与文件系统类型，用lsblk -f或blkid查真实TYPE；挂载点目录需存在且无占用；fstab错误会导致启动卡死；bind mount和overlayfs受命名空间隔离影响。
挂载前必须确认设备节点和文件系统类型
linux 不会自动识别未声明类型的块设备，mount 命令若不指定 -t 参数，会去读 /etc/Filesystems 或 fallback 到 auto，但很多发行版已禁用 auto 探测。实际中常见错误是直接运行 mount /dev/sdb1 /mnt 却报 unknown filesystem type。
正确做法是先用 lsblk -f 或 blkid /dev/sdb1 查看实际类型（如 ext4、xfs、vfat），再显式挂载：
mount -t ext4 /dev/sdb1 /mnt- NTFS 分区需安装
ntfs-3g，否则内核原生 ntfs 只读且不支持写入 - exFAT 需装
fuse-exfat或较新内核（≥5.4）+exfat-utils -
blkid输出中的TYPE字段才是真实类型，别只看分区表标记
挂载点目录必须存在且为空（或至少无活跃进程占用）
mount 不会自动创建挂载点目录，也不会清空已有内容。如果执行 mount /dev/sdb1 /mnt 时 /mnt 下已有文件，那些文件会被临时隐藏——卸载后恢复可见，但这常导致误判“数据丢失”。
更隐蔽的问题是：若当前 shell 工作目录在 /mnt 内，或某进程正打开 /mnt 下的文件，umount 会失败并提示 target is busy。
- 检查占用：
lsof +D /mnt或fuser -v /mnt - 强制卸载风险高，仅限调试：
umount -l /mnt（lazy unmount），但挂载点仍不可重用，需等内核清理完 - 脚本中建议加判断：
[ -d /mnt ] || mkdir -p /mnt
/etc/fstab 条目写错会导致开机卡住或降级到 emergency mode
系统启动时按 /etc/fstab 顺序挂载，任一非 noauto 条目失败（如设备不存在、类型错误、UUID 变更），systemd 默认阻塞启动并进入紧急模式。这不是 bug，是设计行为。
关键字段顺序不能错：device mount_point fstype options dump pass。其中 dump（0/1）和 pass（0/1/2）填错不会报错，但会影响 dump 备份和 fsck 顺序。
- 优先用 UUID 而非
/dev/sdX：设备名在热插拔或多盘时不稳定，blkid输出的UUID=...才可靠 - 测试 fstab 条目是否合法：
mount -a（注意它会真正挂载，别对根或关键分区乱试） - 临时跳过某行：在行首加
#，别删掉或留空行——空行可能被某些工具误解析
bind mount 和 overlayfs 等高级挂载容易忽略命名空间隔离
mount --bind 是常用技巧，但它的作用域受 mount Namespace 影响。在容器或 systemd –scope 启动的环境中，bind mount 默认只在当前 namespace 生效，宿主机看不到；反过来，宿主机做的 bind mount 也不会自动透传进容器。
overlayfs 更复杂：它依赖 lowerdir、upperdir、workdir 三个目录，且 upperdir 和 workdir 必须在同一个文件系统上，否则报 Invalid argument。
- 查 mount namespace：
ls -l /proc/self/ns/mnt，不同 PID 的该值不同说明隔离存在 - 让 bind mount 全局可见（需 root）：
mount --make-shared /path再 bind，否则子 namespace 无法继承 - overlayfs 的
workdir若被删除，下次挂载会失败，且无法通过简单 recreate 恢复，必须清空upperdir的work子目录
实际挂载不是“执行一条命令就完事”的操作，设备识别、路径状态、fstab 语义、namespace 边界这四层任何一层出偏差，都会表现为挂载失败或行为异常。尤其在自动化部署或容器场景下，靠肉眼检查 df -h 输出远远不够。