socket编程实现多人聊天室：TCP/UDP并发模型与消息边界实战解析
2026/10/5 3:44:36
两台 Ubuntu 机器之间想互传文件，很多人第一反应是 U 盘拷贝，或者直接起一个 scp / rsync 命令。但如果你的需求是"像访问本地目录一样随时读写对方文件"，Samba 其实是很多场景下被低估的选择。它不仅能解决 Ubuntu 到 Ubuntu 的共享，还能顺便把 Windows、macOS 客户端一起覆盖了，一套配置全家通用。这篇文章我把自己最近一次在两台 Ubuntu 之间用 Samba 共享文件夹的完整过程整理出来，包括为什么选它、配置文件每个参数的含义、踩过的权限坑、客户端挂载的细节，以及一套从日志到权限逐层定位的排错思路。不管你是第一次接触 Samba 还是配过但没配明白，照着走一遍基本都能跑通。
1. 先说结论：两台 Ubuntu 共享文件，为什么我会优先考虑 Samba
如果你只在两台 Ubuntu 之间传文件，最轻量的方案确实不是 Samba，而是rsync或者scp。这类工具按需传输、不用常驻服务，适合一次性同步。但如果你的目标是两台机器之间的目录持续互访、像操作本地文件夹一样操作对方文件，rsync 就不太合适了——它更接近"同步"而不是"共享"。
同一场景下，NFS 其实也是常被提到的方案。NFS 性能出色、配置直接，在两台 Linux 之间共享目录尤其高效。那为什么我最终选了 Samba？核心原因是兼容性。Samba 实现的是 SMB/CIFS 协议，这是 Windows 原生文件共享协议，Ubuntu、macOS、电视盒子、嵌入式开发板也都带客户端支持。我实际使用环境里，绝大多数时间确实是两台 Ubuntu 互访，但偶尔也会从 Windows 笔记本拷贝文件过去——这时候 NFS 就得装额外软件，Samba 则什么都不用装，打开文件管理器输入地址就行。
另一个现实因素是权限体系更好理解。Samba 的共享权限叠加逻辑（共享权限 + Linux 文件权限 + 用户认证）虽然繁琐，但排查思路是线性的，网络服务出现访问失败时更容易定位。NFS 的权限模型对新手更绕，root 压缩、匿名映射这些概念第一次接触很容易懵。
性能方面也别担心——现代 Samba 默认使用 SMB 3.0 以上的协议版本，在千兆局域网里大文件传输基本能吃到接近线速。小文件密集的场景（比如几万个源码文件）会弱一些，这个后面我会单独说明。简单说，Samba 在"多系统互访 + 配置可预期 + 长期常驻共享"这个组合需求下，是综合成本最低的方案。
2. 安装与基础准备：别跳过 smbd 状态检查这一步
2.1 安装包的选择和版本差异
两台 Ubuntu 上都安装 Samba 服务端。常见的安装命令是：
sudo apt update sudo apt install samba -y这里有个版本细节值得注意。Ubuntu 22.04 及以前，samba这个包会直接安装 smbd 和 nmbd 两个守护进程。到了 Ubuntu 24.04，系统开始推荐按需安装samba-server包，但经典的sudo apt install samba依旧有效，会自动拉起依赖。搜索热词里也能看到"ubuntu 24.04 lts配置教程"这类内容，实际操作时如果你发现安装后没有 smbd 服务，再补一个sudo apt install samba-server就行。
安装完成后，我建议立刻检查服务状态，而不是直接开改配置。很多"配置完连不上"的问题，其实在第一步服务就没起来：
systemctl status smbd --no-pager如果显示active (running)就正常。如果状态是 dead 或者 failed，先启动并设为开机自启：
sudo systemctl enable --now smbd sudo systemctl enable --now nmbd2.2 端口和防火墙：为什么你的客户端总说"连接不上"
Samba 依赖多个端口工作，理解它们的角色对排查很有帮助：
| 端口 | 协议 | 用途 |
|---|---|---|
| 137/138 | UDP | NetBIOS 名称解析和浏览 |
| 139 | TCP | 老版本 SMB（SMB1/2 时代） |
| 445 | TCP | 现代 SMB 协议主端口 |
现代 Ubuntu 之间的通信主要走 445 端口，另外两个是老设备的兼容通道。如果开了 UFW，哪怕服务正常运行，客户端也会出现"连接超时"或者"无法访问"的报错。放行规则建议按网段限制，而不是直接 allow 所有来源：
sudo ufw allow from 192.168.1.0/24 to any port 137,138 proto udp sudo ufw allow from 192.168.1.0/24 to any port 139 proto tcp sudo ufw allow from 192.168.1.0/24 to any port 445 proto tcp更省事的做法是 UFW 自带了一个Samba应用配置：
sudo ufw allow 'Samba'这个规则会自动覆盖上述三个端口，但它对所有来源开放，内网环境问题不大，公网环境下千万别这么干。我自己的习惯是改成明确网段，避免将来这台机器被放到其他网络环境下出现意外暴露。
2.3 网络层面的一个小提醒
如果两台机器处在同一个局域网，建议用静态 IP 或者 DHCP 保留地址，避免每次分配 IP 变了之后挂载失败。主机名访问（//ubuntu-host/share这种形式）在 Ubuntu 之间偶尔能用，但底层依赖 NetBIOS 或 mDNS 解析，不同网段、不同路由器环境下表现很不稳定。我在配置里只写 IP，这是最不容易出意外的做法。
3. 核心配置：smb.conf 里每行参数到底在干什么
Samba 的配置文件是/etc/samba/smb.conf。修改前一定要先备份原文件，然后逐段追加内容。下面是我这次用的配置片段，先整体展示，再逐行拆解：
[global] workgroup = WORKGROUP server role = standalone server server min protocol = SMB2_10 log file = /var/log/samba/log.%m max log size = 1000 [fileshare] comment = Shared folder between Ubuntu machines path = /srv/samba/share browseable = yes read only = no valid users = alice create mask = 0664 directory mask = 0775 force user = alice force group = alice3.1 [global] 段的三个关键参数
workgroup = WORKGROUP不是必须的，但保持默认工作组名称有助于和其他 Windows 客户端互联，不用特意改。
server role = standalone server明确告诉 Samba 这是独立服务器，不参与域环境。如果省略这行，Samba 会自己协商角色，在纯 Ubuntu 环境里一般没问题，但明确写出来能避免某些客户端协商异常。
server min protocol = SMB2_10是我强烈建议加的。Samba 默认允许 SMB1 协议（为了兼容极度古老的设备），但 SMB1 存在明显安全隐患，而且协议协商阶段容易出怪问题。限制最少支持 SMB2.10 之后，两台现代 Ubuntu 之间协商完全不成问题，还能杜绝老协议引发的兼容性顽疾。
log file和max log size这两行决定了日志路径和大小上限。逐主机日志（log.%m）在排错时非常有用，哪台机器访问出了问题，直接看以它主机名命名的日志文件就行。
3.2 共享段配置：从 [fileshare] 看 Samba 的权限叠加逻辑
[fileshare]是共享名称，客户端访问时写//服务器IP/fileshare，这个名字可以随意改，但方括号里的名称和客户端输入的路径必须完全一致。
path = /srv/samba/share是服务器上真实存在的目录路径。这个目录的 Linux 权限是后续所有访问的基础，很多人配置完提示 Permission denied，一半以上的根因出在这里。后面第 4 节我会专门讲目录权限链。
browseable = yes控制共享是否在"网络邻居"里可见。如果设为 no，客户端必须手动输入完整路径才能访问。两机互访场景建议设成 yes，省得每次敲地址。
read only = no是最容易和字面意思混淆的参数。字面上它是"只读"开关，no表示不只读，也就是允许写入。有的教程直接写writable = yes，效果完全一样，两者是同一含义的两种写法。我习惯用read only = no，因为它和新手理解直觉是反的，反而很难忘记它真实含义。
valid users = alice限定了只有哪些用户可以通过 Samba 访问这个共享。这里写的用户名必须是服务器系统里真实存在的用户，否则 Samba 会提示登录失败。不写这行的话，所有能通过 SMB 认证的用户都能访问，安全性弱很多。
force user = alice和force group = alice是我认为被很多教程忽略、但实际价值很高的配置。Samba 认证通过后，客户端对共享目录的文件操作会以谁的身份执行？默认是"认证用户本人"。如果目录属主是 root，alice 即使通过了 Samba 认证，写入也会被 Linux 权限拦截。加了force user = alice后，所有通过 Samba 的文件操作都会被强制映射成 alice 用户身份，这相当于绕过了复杂多用户管理的需求，在两台机器互访的个人场景下是最高效的做法。
3.3 掩码参数：为什么新建文件总是缺权限
create mask = 0664和directory mask = 0775控制通过 Samba 新建文件和目录时的默认权限。这里的 mask 是取反逻辑，不是你想当然的"直接赋予的权限值"。
create mask = 0664表示新建文件的权限在 0666 的基础上抹掉"其他用户写"（020）这一位，结果就是 0664：属主和属组可读写，其他用户只读。directory mask = 0775表示新建目录的权限在 0777 基础上抹掉"其他用户写"（002），结果就是 0775：属主和属组拥有全部权限，其他用户可读可执行。
如果不设置这两项，Samba 默认掩码会导致新建文件权限变成 0744 或者 0755 之类，别人没有组写权限，多用户协作时立刻出问题。在两台 Ubuntu 互访的场景下，0664 和 0775 是最实用的组合——文件可被同组成员修改，而不需开放所有权限给所有人。
3.4 配置文件的验证与重启
每次修改完 smb.conf，我强烈建议先跑一遍语法检查再重启服务：
testparm出现Loaded services file OK.就说明语法没问题。然后重启服务使配置生效：
sudo systemctl restart smbd注意一个容易二次踩坑的点：如果用户还在通过 Samba 连接共享，重启服务会强制断开所有会话，正在复制的大文件可能中断。我一般在低峰期修改配置，或者先通知一下对端机器再重启。
4. 最容易翻车的部分：用户认证与目录目录权限的链条
4.1 Samba 用户和系统用户不是一回事
Samba 有一套独立的用户数据库，但它依赖于系统已存在的用户来建立映射。也就是说，alice必须先是服务器上的 Linux 用户，然后你才能把它添加到 Samba 用户体系里：
sudo useradd -m -s /bin/bash alice sudo smbpasswd -a alice执行smbpasswd -a时，系统会提示输入两次密码。这个密码可以和 alice 的 Linux 登录密码不同，Samba 密码存储在/var/lib/samba/private/passdb.tdb中，和系统账户密码天然隔离。
这里有一个很多人初次配置时遇到的 "坑"：在 smbpasswd 里加了用户之后以为它一定生效了，但有时还是提示登录失败。原因在于新添加的 Samba 用户默认状态可能是 disabled，需要手动启用：
sudo smbpasswd -e alice-e参数表示 enable。另外，如果你之后用sudo passwd alice改了系统密码，Samba 密码不会跟着变，访问共享仍然用旧密码。这个特性容易让人困惑，但也是安全设计——两者本来就是独立凭证。
4.2 目录权限检查的顺序：先 Linux 后 Samba
很多共享访问失败，问题不在 Samba 配置，而是真实目录的 Linux 权限没有配好。我习惯把权限链拆成三层来检查：
- 目录本身对 alice 用户必须有可读可写可执行权限。
path的父目录对 alice 必须有执行权限，否则即使目标目录权限正确，访问时也会报"权限不够"。- Samba 层的
valid users和read only是否允许这次访问。
实际操作时，我通常把共享目录的属主直接改成目标用户，权限给到位：
sudo mkdir -p /srv/samba/share sudo chown -R alice:alice /srv/samba/share sudo chmod -R 0775 /srv/samba/share有了force user = alice之后，即使目录当前属主是 root，文件操作也会以 alice 身份执行。但父目录的执行权（/srv、/srv/samba这两层）仍然需要 open by search 权限，也就是任何一级路径都需要others带x权限，否则 alice 根本进不了目录树。用sudo chmod 0755 /srv /srv/samba可以解决。
4.3 用一个实际测试验证权限是否通
配置完权限不必急着上客户端，直接在服务器本地用 Samba 客户端工具自测最靠谱：
smbclient //localhost/fileshare -U alice输入密码后如果出现smb: \>提示符，说明身份认证和共享访问通了。再敲ls看看能否列出目录内容。这一步通过之后，问题基本只能出在客户端网络层面，排错范围一下就缩小了。
如果 smbclient 报NT_STATUS_ACCESS_DENIED，优先检查目录 Linux 权限和父目录的可搜索执行权限；如果报NT_STATUS_LOGON_FAILURE，优先检查 smbpasswd 的用户状态和密码是否正确。这两类报错指向完全不同的根因，下文排错部分会继续细说。
5. 客户端挂载：命令行、开机自动挂载、cifs-utils 细节
5.1 安装 cifs-utils 并手动挂载
客户端机器上需要安装cifs-utils，否则无法挂载 SMB 共享：
sudo apt update sudo apt install cifs-utils -y挂载的命令格式：
sudo mkdir -p /mnt/fileshare sudo mount -t cifs //192.168.1.100/fileshare /mnt/fileshare \ -o username=alice,password=你的密码,vers=3.0,uid=$(id -u),gid=$(id -g),iocharset=utf8//192.168.1.100/fileshare是服务器 IP 加共享名，不是主机名。username=alice是刚才在 smbpasswd 里配置的 Samba 用户。vers=3.0强制使用 SMB 3.0 协议，避免双方在协议协商时滑落到底版本。如果你的服务器配置了server min protocol = SMB2_10且客户端也较新，不写这行也能协商成功，但我习惯显式写出来。uid=$(id -u)和gid=$(id -g)很关键。不加这两个参数时，挂载点里的文件属主会显示为 root，普通用户无法修改挂载点内的文件。加上之后，文件在客户端看来就是你当前用户拥有的。
挂载成功后用df -h能看到新的 cifs 文件系统，直接 cd 进去读写测试。
5.2 密码安全与 credentials 文件
上一条命令里把密码直接写在命令行，虽然方便，但会被 shell history 记录，一旦该机器被多人共用就存在泄露风险。更稳妥的方式是使用 credentials 文件：
sudo mkdir -p /etc/samba sudo tee /etc/samba/credentials > /dev/null <<EOF username=alice password=你的密码 domain=WORKGROUP EOF sudo chmod 600 /etc/samba/credentials注意 credentials 文件必须限制权限，因为里面是明文密码。chmod 600之后，只有 root 能读。然后挂载命令简化为：
sudo mount -t cifs //192.168.1.100/fileshare /mnt/fileshare \ -o credentials=/etc/samba/credentials,vers=3.0,uid=$(id -u),gid=$(id -g),iocharset=utf85.3 开机自动挂载的 fstab 写法
重启后手动挂载会失效，需要把它写进客户端机器的/etc/fstab。完整写法：
//192.168.1.100/fileshare /mnt/fileshare cifs credentials=/etc/samba/credentials,uid=1000,gid=1000,iocharset=utf8,vers=3.0,_netdev 0 0这里有三个细节需要特别留意：
_netdev选项告诉系统这是一个网络设备，需要在网络就绪之后再挂载。如果没有这个选项，开机时网络尚未初始化，会出现"挂载失败"的报错，而且系统还可能因为 fstab 挂载失败进入紧急模式。uid=1000和gid=1000建议写明确数字，而不是写用户名。fstab 解析阶段用户名解析可能因系统环境差异出现问题，数字 ID 更稳定。- 写入 fstab 后千万不要直接重启测试，先用
sudo mount -a验证当前配置能否成功挂载。如果 mount -a 也报错，说明 fstab 写法有问题，此时重启会导致系统启动异常。
另一个防坑技巧：fstab 中 credentials 文件路径前不需要 sudo，但文件本身必须是 root 可读的。之前网上有一种写法会在 fstab 行尾加guest或者noperm，建议不要用——noperm会跳过客户端本地权限检查，虽然方便但隐藏了权限信息；guest则完全绕过了认证，安全性存疑。
5.4 挂载点目录权限
客户端挂载点/mnt/fileshare如果之前是 root 拥有，普通用户访问时会提示 Permission denied。建议确认挂载点权限：
sudo chown $(id -u):$(id -g) /mnt/fileshare不过 cifs 挂载后，挂载点原有的属主信息大部分被 Samba 会话覆盖，所以更关键的是挂载时是否带uid/gid参数。如果挂载后ls -l /mnt/fileshare看到属主是 root 且无法写入，优先检查挂载选项里是否遗漏了 uid/gid，而不是去 chmod 挂载点。
6. 访问失败排查链路：从日志到权限逐层定位
6.1 从客户端报错反向定位根因
我在这类共享访问失败问题上有一个固定的排查顺序，基本可以覆盖绝大多数情况：
第一步，确认网络连通性。
用 ping 确认对方 IP 可达。ping 不通就直接排除 Samba 配置问题，回到网络层查网段和路由。ping 通但 Samba 访问超时，查服务器 UFW 和 445 端口监听状态：
ss -tlnp | grep 445 sudo ufw status如果 445 没有被 smbd 监听，说明服务没起来或者配置没生效；如果监听正常但外部访问被拒绝，基本就是防火墙拦截。
第二步，用 smbclient 从客户端测试。
在客户端机器上执行：
smbclient -L //192.168.1.100 -U alice-L是列出服务器上所有共享。如果这一步能看到fileshare共享，说明认证和网络都通了，问题可能出在挂载选项；如果认证失败，会直接报SESSION_SETUP相关的 NT_STATUS 错误。
第三步，根据 NT_STATUS 报错分类处理。
| 报错信息 | 常见根因 | 处理方向 |
|---|---|---|
NT_STATUS_LOGON_FAILURE | Samba 用户密码错误、用户未启用、服务端禁用了 SMB 认证 | 重新执行smbpasswd -a/smbpasswd -e |
NT_STATUS_ACCESS_DENIED | 目录 Linux 权限不足、valid users 不包含当前用户、Samba 侧禁写 | 检查 path 目录属主与force user配置 |
NT_STATUS_BAD_NETWORK_NAME | 共享名写错、共享未定义 | 用testparm确认方括号名称拼写 |
mount error(13) Permission denied | 挂载选项里的用户名密码错误，或者 vers 协议不匹配 | 检查 credentials 文件内容、尝试加vers=3.0 |
mount error(112) Host is down | 445 端口不通、被防火墙拦截 | 查 UFW 规则和服务监听状态 |
第四步，如果服务端日志有可疑信息。
日志在/var/log/samba/目录。log.smbd和以客户端主机名命名的日志会记录认证失败和权限拒绝的细节。比如看到rhost和NT_STATUS_ACCESS_DENIED同时出现，基本可以断定是权限链路问题而不是网络问题。
6.2 我用一个真实案例演示完整排查思路
之前我帮朋友排查过一次"看不到共享"的问题，现象是：客户端 smbclient 列共享失败，错误是NT_STATUS_LOGON_FAILURE。当时第一反应是密码输错，但重设密码后仍然失败。继续看服务器上的/var/log/samba/log.smbd，发现一条关键信息：check_smb_security: auth failed for alice。
我接着做了两件事。第一，确认 alice 在系统里确实存在：id alice。第二，重新执行sudo smbpasswd -a alice，看到输出提示"enabling user alice"。问题就出在用户虽然存在，但 Samba 用户状态是 disabled——重新添加的过程顺带把它 enable 了。这个场景非常典型：新用户第一次添加 Samba 账号时，如果命令版本或系统状态有差异，会出现默认禁用的情况，必须用smbpasswd -e手动启用。
6.3 另一个高频坑：Samba 密码改过但客户端还在用旧密码
如果你改过 Samba 用户密码，客户端机器的 fstab 里如果用的是旧密码的 credentials 文件，挂载就会开始失败。此时不要急着改 fstab，先手动用新密码跑一遍 smbclient 确认凭据正确，再更新 credentials 文件：
sudo vim /etc/samba/credentials改完后执行sudo mount -a重新挂载。如果 fstab 里有常驻挂载，先卸载再挂载：
sudo umount /mnt/fileshare sudo mount -a这个坑之所以高频，是因为系统密码和 Samba 密码是两套体系，很多人改了系统密码就以为共享密码也变了，实际上 Samba 密码纹丝不动。反过来，你改了 Samba 密码也不会影响 SSH 登录系统。两条线程互不干扰，必须分别管理。
6.4 大文件传输卡顿和性能优化方向
Samba 在千兆局域网里传输大文件一般能到 100MB/s 左右，但如果你传输的是几万个零碎小文件（比如代码仓库、图片素材库），性能会明显下滑。这不是配置问题，而是 SMB 协议在小文件随机读写场景下有较高的元数据开销。
我自己在共享目录里做"大规模文件迁移"时，不会直接复制整个目录，而是先在服务器端打包：
tar -czf /srv/samba/share/backup.tar.gz /var/lib/some_data客户端直接拉取单一大文件，性能会好很多。日常使用如果发现挂着 Samba 的目录操作卡顿，可以先把文件复制到本地再处理，避免在 Samba 挂载点上直接跑大量随机读写的应用。
6.5 挂载断连后的恢复方法
Samba 挂载点如果长时间闲置或被网络波动断开，客户端访问时可能报Transport endpoint is not connected。这时候直接访问挂载点会卡住或者提示 I/O 错误，正确做法是先卸载再重新挂载：
sudo umount -l /mnt/fileshare sudo mount -a-l参数表示 lazy 卸载，即使有进程还占用挂载点也能强制脱离。这不是 Samba 的 bug，而是所有网络文件系统在断连后的通用行为。为避免频繁出现断连，客户端挂载选项可以加一个noatime，减少对服务端的元数据写请求，降低空闲超时触发的概率。
7. 我实际使用中的几点经验补充
整个配置跑通之后，我在实际操作里积累了几个值得分享的习惯。第一，把 smbpasswd 的账号状态列入定期检查清单。Samba 用户偶尔会因为密码过期策略或者手动操作被禁用，一旦连接到一半突然断开，优先查这个。第二，共享目录的路径尽量保持在/srv下，不要放在/home/某用户里——如果那个用户目录被加密（如 ecryptfs），Samba 服务重启后可能完全无法访问。第三，生产环境不要用force user = root，虽然这能解决所有权限问题，但安全性极差，任何通过 Samba 写入的文件都变成 root 所有，一旦共享被误配置为可写，等于把 root 写入权限暴露给网络。个人机器无所谓，但如果有其他同事或设备在同网段，建议还是用独立用户加force user = alice的方案。
如果你只是临时拷贝一批文件过去，用完即走，Samba 常驻服务可能确实有点重，这时候 rsync 更合适。但如果这台机器承载了持续变化的共享目录，或者你需要让不同操作系统的设备都能随时访问，Samba 这套方案稳定性和管理成本都表现很不错。配置文件里加注释是个好习惯，不然三个月后你回来看到read only = no和一堆 mask 参数，大概率要花时间重新回忆当时为什么这么写——我在这是吃过亏的。