当你有多台机器——一台主要跑服务的服务器、一台存放媒体/大文件的 NAS、几台需要共享数据的机器——很快会遇到一个默认但未必舒服的动作：在 A 机看文件，得先拷到 B 机；要改一个文件，得先下载、改完再传回去。这种"文件在机器之间用拷贝跑来跑去"的方式笨拙又容易出岔子。NFS（Network File System）解决的是另一件事：让一台机器上的目录能被网络上的其它机器"像本地目录一样直接读写"，省去手动拷贝、让大家看到同一份数据。这篇讲清 NFS 解决什么、怎么在一台"服务器/存储机"上提供共享、客户端怎么挂载，以及权限、性能与安全的边界。
一、NFS 解决什么：把"拷贝同步"换成"直接共享同一份数据"
NFS 的核心价值在于"共享"而非"拷贝"：你在服务器上导出一个目录，客户端通过挂载把这个目录当成自己的本地目录来读写——不需要每次手动同步或复制，改动即见、所有人看同一份。它和两个相邻方案做个区分能帮上判断：一是"直接拷贝/rsync 同步"，那是"多份副本"，适合断断续续给别处送数据、或异地备份，但不解决"多机实时一致地看一份"；二是"对象存储/网盘"，那是"通过层协议/App 访问"，而 NFS 是"像本地文件系统一样，通过内核/系统层直接读写"。
自托管里 NFS 最典型的用场是把"存储集中"：一个 NAS/服务器承载大目录（媒体、备份、共享文档），其它机器用 NFS 挂上，即可像看本地盘一样访问同一份数据。它天然属于"把数据收拢、多机共享"这条主线。要注意 NFS 传统上更适合"局域网/可信网络 + 它共享的是裸目录权限模型"，跨公网用它则要把安全想周全（见后文）。
二、服务端落地：导出目录、配好人/网络白名单
服务端（提供共享的那台机器）要做的核心是两件事：一是在 `/etc/exports` 里声明"哪个目录共享给谁、怎么共享"；二是启动 NFS 服务让它生效。`/etc/exports` 的每行格式是"共享目录 + 允许的客户端 + 选项"，重点是"别默认给整个世界"——显式写明允许哪些网络/主机，且想清楚是否只读。
# /etc/exports 示意（服务端）
/srv/share 192.168.1.0/24(rw,sync,no_subtree_check) # 内网可读写
/srv/readonly 192.168.1.0/24(ro,sync,no_subtree_check) # 只读共享，安全
# 配置后用 exportfs 使其生效
sudo exportfs -ra
# 查看当前共享：exportfs -v
配置时的几条要点。一是"白名单到网络/主机"，别写 `*` 全球可挂那种裸权；二是"按需决定 rw/ro"，只读的（如只读媒体库）就设 `ro`，减少被误改/破坏面；三是"subtree_check 相关选项"按发行版默认调好，避免复杂导出的坑；四是"不要把你的根目录/整个主目录裸导出去"，只导出真正要共享、且权限已收紧的子目录。把这些在服务端立好，共享层既好用又不太"敞门"。
三、客户端挂载：像本地盘一样用，也别忘了"网络盘会断"
客户端侧，用 `mount` 把服务端共享挂到本地目录即可，加了 `_netdev` 可以避免开机时网络未就绪就硬挂。挂上去后，它就是一个普通目录——所有依赖文件路径的应用几乎不用改就能访问这台 NFS 上的数据，这正是"像本地盘一样用"的价值。
# 客户端挂载（网络未就绪也不要阻断启动）
sudo mount -t nfs 192.168.1.100:/srv/share /mnt/share -o rw
# 把 /etc/fstab 加上 _netdev 让它开机随网络就绪而挂载，避免开机卡住
# 192.168.1.100:/srv/share /mnt/share nfs defaults,_netdev 0 0
客户端侧最重要的心智是"这是一块网络盘，不是本地盘"：网络抖动或服务端暂不可达时，读写会变慢、卡住或报错，NFS 默认重试可能导致客户端阻塞在不响应上。所以对"必须可用、不容忍 NFS 故障拖垮"的关键数据，别只在 NFS 上放唯一副本；对普通的共享/媒体目录，理解"网络盘特性"即可——它优先解决了"多机看同一份"，但不等于本地 SSD 那样随时可期的响应。把"它是网络盘、要接受它的网络特性"记住，用起来才不会惊。
四、性能与权限：挂载要快、权限要清
NFS 一旦多机共享，两个反复遇到的问题是"性能"和"权限"。性能上，NFS 走网络，局域网内体验通常不错，但别指望它和本地盘一样快：大文件、大量小文件、高并发都要看网络与存储底子；优化方向是确保局域网链路够、避免跨公网用 NFS 扛大数据（那通常又慢又吃带宽）。权限上，NFS 的麻烦在于"它默认共享的是文件系统权限（基于 uid/gid）"——如果多机用户 uid 不一致、或你用了 root_squash 与否，会出现"明明能访问却 Permission denied"或"权限比预期更大的"的问题。
# 权限相关的 exports 常用选项（服务端）：
# root_squash # 把客户端的 root 压制成 nobody，防远端root乱改——默认应开
# all_squash # 把所有客户端用户都映射成单个uid，方便统一，但可能过度统一
# 排查"能挂上却无权限"：先确认客户端 uid/gid 与目录属主是否匹配
落地建议：权限上优先"用 root_squash 收紧、并让多机的 uid/gid 尽量对齐或用 all_squash 明确统一"，再验证实际读写是否如愿；性能上先确认"它在局域网、链路够、存储底子正常"，再谈进一步调优。把这两件事在初期就讲清（而不是等"为什么挂上了却写不了 / 怎么这么慢"才排查），NFS 的日常使用会省很多折腾。
五、边界与安全：NFS 面向可信内网、公网要慎重
最后认清 NFS 的边界。第一是安全模型：NFS 早期权限模型更适合"可信局域网"——即使有 root_squash，它也并非面向公网的强信任边界，跨公网裸各 NFS 端口会带来被滥挂、权限越界、数据暴露的风险；真想跨公网共享，更稳的路子是把它放进私网（Tailscale/WireGuard）或改用带鉴权加密的方式。第二是"它不是备份"：NFS 解决"多机一致地看一份"，不保证数据不损坏不丢失——你仍要为它共享的那份数据做备份与磁盘防坏，别因"大家都能看到"错觉以为保险。第三是"它是网络依赖"：服务端不稳定或不响应时，客户端会"感觉像卡死"，要有这种预期管理。
# 安全与务实提醒：
# - 只在可信内网/私网使用，必要时套 VPN/Tailscale 再跨网络共享
# - 服务端设置的必做项：no_subtree 合理、root_squash、别导私有/系统目录
# - 别把"大家都能看到"当成"数据已安全/已备份"；仍要防坏盘 + 异地备份
把这些边界当成"使用 NFS 的门口告示"：面向可信内网、权限用 root_squash 收紧、公网套私网再共享、数据仍要按用途备份。把"共享一份"与"安全/备份"这两件事分开看，NFS 才会是你"多机直接读写同一份共享数据"的好工具，而不是一个"图方便却把数据和安全都放松"的小隐患。
结语
NFS 的价值，是让一台机器的共享目录能被其它机器"像本地一样直接读写"，把"多机拷贝同步"换成"多机看同一份数据"。落地要点：服务端用 `/etc/exports` 声明共享目录并以"网络白名单 + 按需 rw/ro + root_squash"收紧，客户端用 `mount/_netdev` 挂上当作本地目录；性能与权限在初期讲清（局域网链路够、uid/gid 对齐、用 root_squash）。边界是"NFS 面向可信内网、公网要套私网，且它不是备份"——数据仍需防坏盘与异地备份，对关键数据也别只在 NFS 上放唯一副本。把"共享"与"安全/备份"分开看，NFS 就是多机共享数据时那份配套的、像本地盘一样好用的基础。
