两台 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/138UDPNetBIOS 名称解析和浏览139TCP老版本 SMBSMB1/2 时代445TCP现代 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 认证通过后客户端对共享目录的文件操作会以谁的身份执行默认是认证用户本人。如果目录属主是 rootalice 即使通过了 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 usernamealice,password你的密码,vers3.0,uid$(id -u),gid$(id -g),iocharsetutf8//192.168.1.100/fileshare是服务器 IP 加共享名不是主机名。usernamealice是刚才在 smbpasswd 里配置的 Samba 用户。vers3.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 usernamealice password你的密码 domainWORKGROUP 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,vers3.0,uid$(id -u),gid$(id -g),iocharsetutf85.3 开机自动挂载的 fstab 写法重启后手动挂载会失效需要把它写进客户端机器的/etc/fstab。完整写法//192.168.1.100/fileshare /mnt/fileshare cifs credentials/etc/samba/credentials,uid1000,gid1000,iocharsetutf8,vers3.0,_netdev 0 0这里有三个细节需要特别留意_netdev选项告诉系统这是一个网络设备需要在网络就绪之后再挂载。如果没有这个选项开机时网络尚未初始化会出现挂载失败的报错而且系统还可能因为 fstab 挂载失败进入紧急模式。uid1000和gid1000建议写明确数字而不是写用户名。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_FAILURESamba 用户密码错误、用户未启用、服务端禁用了 SMB 认证重新执行smbpasswd -a/smbpasswd -eNT_STATUS_ACCESS_DENIED目录 Linux 权限不足、valid users 不包含当前用户、Samba 侧禁写检查 path 目录属主与force user配置NT_STATUS_BAD_NETWORK_NAME共享名写错、共享未定义用testparm确认方括号名称拼写mount error(13) Permission denied挂载选项里的用户名密码错误或者 vers 协议不匹配检查 credentials 文件内容、尝试加vers3.0mount error(112) Host is down445 端口不通、被防火墙拦截查 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/某用户里——如果那个用户目录被加密如 ecryptfsSamba 服务重启后可能完全无法访问。第三生产环境不要用force user root虽然这能解决所有权限问题但安全性极差任何通过 Samba 写入的文件都变成 root 所有一旦共享被误配置为可写等于把 root 写入权限暴露给网络。个人机器无所谓但如果有其他同事或设备在同网段建议还是用独立用户加force user alice的方案。如果你只是临时拷贝一批文件过去用完即走Samba 常驻服务可能确实有点重这时候 rsync 更合适。但如果这台机器承载了持续变化的共享目录或者你需要让不同操作系统的设备都能随时访问Samba 这套方案稳定性和管理成本都表现很不错。配置文件里加注释是个好习惯不然三个月后你回来看到read only no和一堆 mask 参数大概率要花时间重新回忆当时为什么这么写——我在这是吃过亏的。