为什么个人站长也需要一台「文件服务器」

很多人以为文件共享是公司 IT 的事，个人站长用不到。但只要你同时管着几台机器，很快就会发现自己在重复做同一件事：把一份备份从 VPS 下载到本地、把一份代码从本地传到另一台机器、把几张素材图在几台电脑之间来回拷。U 盘来回复制、微信传文件、网盘限速，这些凑合方案的成本远比想象中高。

Samba 解决的正是这个问题：它在一台 Linux 服务器上实现 SMB/CIFS 协议，让 Windows、macOS、Linux 以及手机都能像访问本地硬盘一样访问服务器上的目录。搭好之后，你的备份目录、素材库、共享文档就是一个网络盘符，双击即用。

但 Samba 也是个人服务器上最容易配出安全问题的一个服务：默认配置过于宽松、匿名访问没关、权限设错导致写不进去或者上不封顶、以及最经典的「Windows 提示无法访问网络共享但看不出原因」。这篇文章从头走一遍：安装、最小权限配置、以及一套系统的排错方法。

先分清：Samba 和 NFS 该选哪个

Linux 原生的文件共享方案是 NFS，Samba 走的是微软的 SMB 协议。选择标准其实很清晰：

• 客户端里有 Windows 或 macOS：选 Samba。Windows 对 NFS 的支持要额外装「NFS 客户端」功能，配置麻烦；而 SMB 是 Windows 的原生协议，macOS 也原生支持，连手机文件管理器基本都能连。
• 纯 Linux 之间共享，且只在内网：可以选 NFS。它更轻、性能略好、权限模型跟 Linux 原生一致，但遇到 UID 映射问题同样头疼（这也是 NFS 的经典坑——两个机器上同一个 UID 变成不同用户）。
• 要共享给非技术用户：选 Samba。用户只要在资源管理器里输入地址、输账号密码就能用，不需要懂挂载。

本文聚焦 Samba，因为它覆盖面最广。顺带说一句：Samba 和 SSHFS 不是一类东西。SSHFS 是「通过 SSH 协议把远端目录挂到本地」，适合你自己在几台机器间临时访问；Samba 是「服务器主动提供共享」，适合长期、多人、多平台访问。两者的适用场景不重叠。

安装与最小化的初始配置

Debian / Ubuntu 下安装：

apt update
apt install samba -y

# 查看版本，确认装上了
smbd -V
# 服务管理
systemctl enable --now smbd

安装完成后，配置文件在 /etc/samba/smb.conf。不要直接在原有的长配置里改，那份默认文件有大段注释，改起来容易出错。最清晰的做法是：把原文件备份，然后写一份精简配置只保留你需要的部分。

cp /etc/samba/smb.conf /etc/samba/smb.conf.orig

然后在 smb.conf 末尾追加你的共享定义（下面的内容可以整段加在文件最后，它会覆盖前面相同项的值）：

[global]
   workgroup = WORKGROUP
   server string = Fileserver
   # 关键安全项：关掉对老协议 SMB1 的支持
   server min protocol = SMB2
   # 不允许匿名访问，一切都要账号密码
   map to guest = never
   # 关闭打印共享相关（个人站用不到，减少攻击面）
   load printers = no
   printing = bsd
   printcap name = /dev/null
   disable spoolss = yes
   # 日志，排错必看
   log file = /var/log/samba/log.%m
   log level = 1

[share]
   comment = 共享资料
   path = /srv/share
   browseable = yes
   read only = no
   valid users = webmaster
   # 只允许这个网段访问（按你的内网改）
   hosts allow = 192.168.1.0/24 10.0.0.0/8
   hosts deny = 0.0.0.0/0
   # 文件权限掩码：新建文件 664、目录 775
   create mask = 0664
   directory mask = 0775
   force group = webmaster

逐项说明这些设置的用意，它们不是可选项而是必选项：

• server min protocol = SMB2：SMB1 协议有著名的漏洞（永恒之蓝就是打它），现代 Windows 也已默认禁用。服务器端显式设成最低 SMB2，直接从协议层面堵住。
• map to guest = never：这是最容易被漏掉的安全项。Samba 的默认行为是「认证失败时按访客处理」，配合 guest ok = yes 就变成匿名可访问。设成 never 后，认证失败就是失败，不给访客身份。
• hosts allow / hosts deny：即使密码泄露，也限制只有内网能连。如果你的服务器有公网 IP，这一项尤其重要——Samba 绝不应该直接暴露在公网 445 端口。远程访问请用 VPN（WireGuard）或 SSH 隧道。
• create mask / directory mask：决定客户端新建文件/目录时的默认权限。0664 表示「属主和属组可读写，其他人只读」；0775 是目录对应值。如果不设，Samba 会用系统的 umask，可能生成 0600 的文件导致其他人读不了。
• force group：强制新建文件的属组。多个用户共享同一目录时，不设这个会出现「A 建的文件 B 改不了」——因为属组不对。强制统一属组是让共享目录真正「共享」的关键。

创建目录和用户：权限这一步做错后面全白搭

配置写完之后，要准备两样东西：一个目录、一个 Samba 账号。顺序很重要，先目录后用户，因为用户要加入目录的属组。

# 1. 建目录
mkdir -p /srv/share
chown -R webmaster:webmaster /srv/share
chmod 2775 /srv/share

注意 chmod 2775 里那个前导的 2，它是 SGID 位。含义是：在这个目录下新建的任何文件/子目录，都会自动继承该目录的属组，而不是继承创建者的主属组。这一位是多人共享目录的必需品——没有它，每次都要靠 force group 兜底，而且子目录深层还是会出问题，有了它才彻底。

# 2. 创建系统用户（不给 shell 登录，仅用于文件服务）
useradd -M -s /usr/sbin/nologin webmaster

# 3. 设置 Samba 密码（注意：不是系统密码）
smbpasswd -a webmaster
smbpasswd -e webmaster

这里有一个新手最常踩的坑：Samba 有独立的密码库，和 Linux 系统密码是两回事。你用 useradd 建了用户，但没跑 smbpasswd -a 的话，这个用户根本不能登录 Samba，症状是「密码怎么输都不对」。smbpasswd -a 是「添加并设置 Samba 密码」，-e 是启用该账号。

配置改完要检查语法并重载：

testparm -s          # 检查配置语法，会打印最终生效的配置
systemctl reload smbd

testparm 是必跑的一步。它会告诉你哪些参数拼错了、哪些参数已废弃。Samba 对拼错的参数只会静默忽略并记一条 warning，不会启动失败——这意味着你写错了 hosts allow 也可能毫无察觉，直到安全审计时才发现限制没生效。

客户端怎么连：三个平台的地址写法

服务端配好后，客户端的连接方式各平台不同，记一下能省很多时间：

• Windows：资源管理器地址栏输入 \\192.168.1.10\share（用服务器的内网 IP 和共享名）。首次连接会弹账号密码框，输入 Samba 账号 webmaster 和刚才设的 Samba 密码。要长期使用可以右键「映射网络驱动器」。
• macOS：Finder 里按 Cmd+K，输入 smb://192.168.1.10/share，然后选「注册用户」填账号密码。
• Linux：可以直接挂载，或先装 smbclient 测试连接：

# 列出服务器上所有共享（测试连通性和认证）
smbclient -L //192.168.1.10 -U webmaster

# 挂载到本地目录
mount -t cifs //192.168.1.10/share /mnt/share \
  -o username=webmaster,uid=1000,gid=1000,iocharset=utf8

smbclient -L 是最好的第一步——如果它能列出共享，说明网络通、协议协商成功、认证通过；如果它失败，问题一定在服务端或网络，不用去折腾客户端。这个「先分层面验证」的习惯能砍掉一半的排错时间。

Linux 挂载时的 iocharset=utf8 一定要加，否则中文文件名会显示成乱码。如果要开机自动挂载并写入 /etc/fstab，注意密码不能明文写在 fstab 里（全世界可读），应该用一个 0600 权限的凭据文件：

# /etc/samba/cred 权限必须是 600，里面写：
username=webmaster
password=你的密码

# fstab 里这样引用
//192.168.1.10/share /mnt/share cifs credentials=/etc/samba/cred,uid=1000,gid=1000,iocharset=utf8 0 0

防火墙：445 和 139 端口

Samba 用的是 TCP 445（现代 SMB）和 139（老式 NetBIOS）。是否要放行取决于你的网络拓扑：

# 如果客户端和服务器在同一个内网，最简单：只放行内网网段
ufw allow from 192.168.1.0/24 to any port 445 proto tcp
ufw allow from 192.168.1.0/24 to any port 139 proto tcp

# 查看当前规则
ufw status verbose

再次强调：不要把 445 开放给 0.0.0.0/0。公网上的 445 端口每天都有人在扫，历史上多个蠕虫（包括 WannaCry）就是靠这个端口传播的。远程访问的正确姿势是 VPN：先在服务器上搭 WireGuard，把客户端拉进内网，再访问内网 IP 上的 Samba。这样 445 根本不需要对公网开放。

系统化排错：Windows 提示「无法访问」时怎么办

「Windows 无法访问 \\\\192.168.1.10\\share」是 Samba 最常见的报错，而 Windows 给的提示信息少得可怜。正确的排查方法是从服务端往客户端推，一层层确认，而不是在 Windows 上瞎点。

第 1 层：服务在跑吗？

systemctl status smbd
ss -tlnp | grep -E '445|139'

如果 445 没有监听，说明服务没起来或配置有致命错误，看 journalctl -u smbd -n 50。

第 2 层：认证能过吗？用 smbclient 从服务器自己连自己：

smbclient //127.0.0.1/share -U webmaster

能进到 smb: \> 提示符说明认证和共享定义都没问题。smb: \> 里可以 ls、put、get 测试读写。

第 3 层：网络能通吗？从客户端 ping 服务器 IP，再用 telnet 192.168.1.10 445（或 Windows 的 Test-NetConnection）测端口。如果 ping 通但端口不通，是防火墙问题，回去看第 4 层之前的 ufw 规则。

第 4 层：客户端缓存问题。Windows 有个坑：它会在第一次连接失败后缓存凭据。你之后在服务端修好了、密码也改对了，Windows 还是拿旧凭据去连，一直报错。这时候要清缓存：

# Windows 命令行，清除已保存的共享凭据
net use * /delete /y
cmdkey /list
# 然后重新访问，会重新弹认证框

第 5 层：看服务端日志。Samba 的日志在 /var/log/samba/log.<客户端主机名>。log level = 1 时记录基本信息；把等级调到 3 能看到认证失败的具体原因：

# 临时把日志级别调到 3（排错完记得改回来）
# smb.conf 里：log level = 3
tail -f /var/log/samba/log.WIN-PC

一次真实的排查：能连上但一写就报「拒绝访问」

有个站长的场景很典型：共享目录挂好了，Windows 能看到里面的文件，也能打开、下载。但一新建文件 or 一保存就报「拒绝访问」，粘贴文件也失败。他反复检查 read only = no（确认写了）、Samba 密码（确认对），依然不行。

排查动作分三步，很快定位：

第一步，确认是「读可以、写不行」。他试了「下载文件」成功、「上传文件」失败。这个现象把范围缩小到写权限，而不是认证问题——因为认证如果是错的，连读都读不了。

第二步，看服务端日志。tail /var/log/samba/log.WIN-PC 里出现了 Permission denied 和 unix_mode 相关的行，说明操作系统层拒绝了写入。

第三步，检查目录属主和权限。ls -ld /srv/share 显示目录属主是 root:root，而 Samba 里配的 valid users = webmaster，也就是说 webmaster 这个用户对目录没有写权限，所以读（对 others 开放）可以、写不行。

根因很清楚了：他建目录时用了 mkdir 但忘了 chown，目录默认归 root。Samba 的 read only = no 只是说「这个共享允许写」，但最终能不能写取决于操作系统层的文件权限。两者是两道独立的关卡，Samba 这一关过了，文件系统那一关没过。

修复与验证。

chown -R webmaster:webmaster /srv/share
chmod 2775 /srv/share
systemctl reload smbd

修复后无需重启 Windows，重新上传即成功。前后对比很清晰：同一个操作，修复前报「拒绝访问」，修复后正常写入，新建文件属组是 webmaster（force group 和 SGID 都生效了）。

这个案例的启发是：Samba 的权限是「两层叠加」的。一层是 smb.conf 里的 read only、valid users，决定「这个共享允许谁做什么」；另一层是 Linux 文件系统的属主属组和权限位，决定「进程实际能不能写盘」。排错时如果只盯着 smb.conf 看，会永远找不到答案——一定要用 ls -l 去确认目录的真实属主。

小结与落地清单

• 多平台（含 Windows/macOS/手机）共享选 Samba，纯 Linux 内网可以选 NFS，两者用途不重叠。
• 配置写在 /etc/samba/smb.conf，但先备份原文件，用精简配置覆盖，改完必跑 testparm -s 检查语法。
• 安全三件套：server min protocol = SMB2、map to guest = never、hosts allow 限内网。Samba 绝不要直接暴露在公网 445。
• Samba 密码和系统密码是两套，用户建好必须 smbpasswd -a，否则密码怎么输都不对。
• 共享目录要 chown 给对应用户并设 chmod 2775（SGID 让新文件继承属组），配合 smb.conf 里的 force group。
• 排错四层法：ss -tlnp 看服务 → smbclient 测认证 → telnet 445 测网络 → Windows 清凭据缓存。
• 「能读不能写」几乎总是文件系统权限问题，用 ls -ld 看目录属主，不要只检查 smb.conf。

对个人站长来说，Samba 属于那种「搭一次、很多年都在用」的基础设施。它的配置量不大，但每一行都跟安全或权限有关，写错一行要么打不开、要么对外敞开。按上面的最小化配置走一遍，用 smbclient 做端到端验证，再配一份内网 IP 限制，你就得到一个既好用又不会成为安全隐患的文件服务器。