Linux把NAS挂载到已有文件的目录上，原来的文件去哪了
服务器上有个目录一直在用，里面堆着业务文件；后来新上了 NAS，有人图省事直接把 NAS 的共享挂到了这个目录上。挂完一打开——旧文件全没了，只剩 NAS 里的内容。第一反应多半是"数据被覆盖删了"，其实大概率没有：这只是挂载的"遮蔽"效应在吓人。
原因分析
挂载（mount）的本质是把一个存储"接"到目录树的某个位置上。挂到哪个目录，访问时看到的就是被挂设备里的内容——这个目录原来的文件不会被删除，只是被"盖"在底下，从访问入口上看不见了。卸载（umount）之后再看，原文件原封不动。真正的风险反而是反过来的那种：NAS 没挂载成功的时段里，有人往这个目录写入了新文件，等挂载成功后新文件又被盖住，业务以为存进 NAS 了，实际落在服务器本地盘上，两边数据悄悄分家。所以这类问题要按"先验真假、再走规范"的顺序处理。
分步解决
- 先验"丢"的真假：执行
df -h或mount | grep 目录路径，确认这个目录当前是否挂着设备；再执行umount 挂载点，回头ls一遍目录——旧文件回来了就是遮蔽，数据安然无恙，千万别急着上数据恢复软件折腾。 - 排查反向遮蔽：问一下挂载前后有没有人往这个目录写过文件、跑过脚本。NAS 未挂载期间写入的内容会在挂载后被盖住；同样用 umount 验证能否看见。两台机器各看到不同文件、互相"丢"文件的怪象，根子多半在这里。
- 挂载点改用专门的空目录：规范做法是在 /mnt/ 或 /media/ 下新建一个空目录专门做挂载点，绝不复用有数据的业务目录。要把旧数据迁进 NAS，就开一个迁移窗口：空挂载点挂上 NAS，用
rsync把旧数据拷入并抽样比对，确认无误后再通知业务把访问路径切过去。 - 堵住"写到遮蔽层"的口子：开机自动挂载写进 /etc/fstab 时加上
nofail参数，避免 NAS 掉线时系统卡在启动；要求更严的场景改用 systemd 的 automount 单元——挂载失败时目录保持空置，一眼可见没挂上，程序也写不进"没挂 NAS 的目录"。 - 收尾三项验证：挂载后
df -h看该目录容量应等于 NAS 的容量而不是本地盘；写一个测试文件，从另一台机器访问确认互见；umount 再 mount 一个来回，确认文件仍在。三项全过，这次挂载才算立住。
预防
给每台服务器维护一张"挂载点表"：谁挂哪、挂到哪个目录、写在 fstab 第几行，交接和排障都有据可查。再立一条铁规矩：任何 mount 操作前先 ls 一遍目标目录——非空目录当挂载点，就是把地雷埋给下一个人。