眠子子子大概每个运维都经历过这种尴尬：办公室里一半人用Windows，一半人用Linux，传文件不是靠U盘抡一圈，就是塞聊天软件里被压缩成马赛克。后来我在团队服务器上把Samba配置好，Windows同事直接映射出一个网络驱动器，开机自动连接，用起来和本地磁盘没什么两样，再也没人来敲我"帮我把这个文件夹发一下"。这篇文章就从零开始，把Linux配置Samba、Windows登录、再到开机自动映射登录的完整过程写清楚，适合正在配置Samba服务器的运维和网管，也适合想在宿舍、家里让Windows自由访问Linux共享目录的个人用户。
这篇文章的路线很直接：先说为什么选Samba而不是FTP或者NFS，然后讲服务端怎么装、怎么改配置，再讲Windows端怎么登录、怎么映射，重点内容放在开机自动映射的几种落地方式上，最后把权限、SELinux、防火墙这些最容易踩的坑集中复盘一遍。整个过程都是我实际操作过的，照着做基本能一次跑通。
1. 为什么选Samba：跨平台共享的通行方案
1.1 Windows和Linux之间那座"协议桥"
Windows的文件共享走的是SMB协议，从当年局域网里的"网上邻居"一路演进到现在的SMB 3.1.1；而Linux原生环境里最常用的是NFS。一个用SMB，一个用NFS，两套协议完全不互通，这就是跨平台文件共享最根本的障碍。
Samba做的事情，就是在Linux上完整实现了SMB/CIFS协议栈。装了Samba的Linux服务器，在Windows的资源管理器里看起来就是一台标准的Windows文件服务器，不需要装任何额外客户端，映射网络驱动器、访问共享目录这些操作跟访问Windows共享一模一样。Samba从1992年诞生到现在已经快三十年，协议覆盖度高、社区活跃度好、安全性也不断在加强，是Linux环境向Windows客户端提供文件共享最成熟的选择。
对很多小型团队来说，Samba的价值还不只是"能用"。它支持标准的用户密码认证、粒度到目录的权限控制、能够记录访问日志，这些特性足够覆盖日常办公和开发场景。而且它是免费的，不必给团队里每个Windows用户购买额外的共享软件授权。
1.2 和FTP、NFS放在一起对比，差距就出来了
我自己早期也图省事搞过FTP，也试过直接在Linux上开NFS给Windows用，最后都换成了Samba。三者的实际差异，用一张表看得比较清楚：
| 对比维度 | FTP | NFS | Samba |
|---|---|---|---|
| Windows原生支持 | 需装FTP客户端 | 不支持（需额外装软件） | 原生支持 |
| 认证方式 | 明文或简单认证 | 基于RPC认证，配置复杂 | 用户名密码认证，域认证可选 |
| 文件锁定 | 基本不支持 | 支持较差 | 支持完善 |
| 实时编辑 | 需下载后编辑再上传 | 支持挂载后直接编辑 | 支持映射后直接编辑 |
| 权限管理 | 跟系统权限割裂 | 依赖NFS export权限 | 和Linux文件权限联动 |
| 部署难度 | 低 | 中 | 中 |
FTP最大的问题是不适合协作场景。两个人同时编辑一个文件，FTP压根没有文件锁的概念，最后谁覆盖谁全靠缘分。NFS在Linux之间确实性能好，但Windows客户端访问NFS要么装额外软件，要么用Windows 10以上自带的NFS客户端功能——这个功能默认还没启用，即便启用了，遇到文件锁和权限映射的问题也够折腾一壶的。
Samba则解决了两个核心问题：Windows用来访问它的协议是系统自带的，驱动器和文件夹的直接编辑体验几乎无感；权限上则沿用Linux的文件权限体系，保留粒度的同时，写权限、只读权限还能在共享配置层面再控制一层，灵活度很高。所以我这几年新上的共享目录服务，一律Samba。
1.3 什么场景最适合直接上手Samba
从我经手的实际需求来看，下面这四类场景最适合用Samba：
- 办公文档共享：Windows办公电脑连接Linux服务器，共享部门资料、合同模板、会议记录，还能做版本备份落地。
- 开发环境共享：代码目录统一放Linux服务器上，Windows开发机直接映射一个盘符，IDE打开代码文件跟本地一样。
- 日志与报表中转：Linux服务器的日志文件、导出报表放到Samba共享目录里，Windows同事可以直接打开分析。
- 跨终端协备：SMB协议在macOS、iPad、安卓手机上同样支持，一台Linux服务器做共享中心，所有终端都能访问同一批文件。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 服务端准备：从装包到配置文件逐项拆解
2.1 安装、启动、确认服务状态
Samba安装没什么技巧，包管理器一把梭就行。不同发行版命令略有差异：
bash复制# Debian / Ubuntu
sudo apt update && sudo apt install -y samba samba-client
# RHEL / CentOS 7/8/9
sudo yum install -y samba samba-client
# openSUSE
sudo zypper install -y samba samba-client
samba-client 这个包一定要装，里面带了smbclient、testparm几个排查工具，后面定位问题全靠它。
安装完成后，Debian系和红帽系的服务名基本都是smbd和nmbd两个，启动并设置开机自启：
bash复制sudo systemctl enable --now smbd nmbd
sudo systemctl status smbd
nmbd是用来做NetBIOS名称解析的，现代Windows走WSD和LLMNR居多，但nmbd开着也没坏处，能让局域网内的主机名解析更顺畅。服务起来后先看一眼版本，不同版本对协议支持差异挺大：
bash复制smbd --version
正常情况下输出的应该是 Version 4.x.x 这样的结果。如果版本在4.0以下，建议升级系统源，因为太老的Samba默认可能还在启用SMB1协议，而Windows 10/11早就把SMB1当成高危功能默认禁掉了，两边的协议协商会出问题。
2.2 共享目录和用户体系先规划好
我最开始配Samba的时候，直接把整个 /home 挂出去共享，结果用户权限乱成一锅粥。现在我做Samba共享，一律按"独立分区 + 独立用户组 + 独立共享名"的原则来。
先把共享目录的根路径规划好。个人习惯是放到 /srv/samba/ 下面，每个共享点建一个子目录：
bash复制sudo mkdir -p /srv/samba/data
这个路径的好处是跟系统目录、家目录隔离，备份、迁移、重配都很干净。
接下来是用户体系。Samba的账号必须对应一个Linux系统用户，因为最终落地到文件系统上还是要靠Linux权限。实际生产环境里，我不会给这些账号开shell登录权限，也不给Home目录，让它们只作为Samba访问账号存在：
bash复制# 创建用户，无登录shell，不建家目录
sudo useradd -M -s /usr/sbin/nologin zhangsan
sudo useradd -M -s /usr/sbin/nologin lisi
# 创建一个共享用户组
sudo groupadd sambashare
sudo usermod -aG sambashare zhangsan
sudo usermod -aG sambashare lisi
然后给共享目录设置好组权限，目录属主是root，属组是sambashare，权限用2770，其中2表示继承组ID，保证在目录里新建的文件自动继承sambashare组，后面写权限才不会乱：
bash复制sudo chown root:sambashare /srv/samba/data
sudo chmod 2770 /srv/samba/data
最后把用户的Samba密码设置一下，这个密码和Linux系统登录密码是独立的：
bash复制sudo smbpasswd -a zhangsan
sudo smbpasswd -a lisi
查看当前有哪些Samba账号，用 pdbedit -L。如果在创建共享时提示账号不存在或密码不对，优先回这里检查账号是否真的创建成功了。
2.3 smb.conf核心配置逐行拆解
Samba的配置文件是 /etc/samba/smb.conf。官方默认文件里注释量巨大，适合参考，但真正配置的时候我习惯直接写精简版，方便后续维护。下面这份是我现在部署Samba时用的最小可靠配置：
ini复制[global]
workgroup = WORKGROUP
server string = File Server
security = user
server min protocol = SMB2
log file = /var/log/samba/log.%m
max log size = 1024
[data]
comment = 部门共享资料
path = /srv/samba/data
browseable = yes
read only = no
valid users = zhangsan, lisi
write list = zhangsan, lisi
create mask = 0664
directory mask = 0775
force group = sambashare
逐项拆一下这些参数的含义：
workgroup = WORKGROUP：Windows工作组名字，家庭版Windows默认就是WORKGROUP，如果局域网有工作组且不是这个名字，改成实际的。security = user：认证模式，表示每个用户必须用Samba账号密码验证。这是目前最常用的模式，除非你有特殊的多用户匿名访问需求，否则不要动它。server min protocol = SMB2：限定最低协议版本。这里手动指定SMB2是为了避免某些老配置回落到SMB1，Windows 10/11默认禁用SMB1，如果你不改这一项，早期Samba默认配置可能协商失败，表现出来就是"找不到网络路径"。log file和max log size：把每个客户端的访问日志单独分开，排错的时候只看某个IP的行为非常方便。
然后看共享段 [data]，这一段的名字将来就是Windows里输入共享路径时最后那一级目录名，比如 \\192.168.1.100\data：
path：对应磁盘上的实际路径。browseable = yes：允许在"网络"里浏览到这个共享。不设置的话要手动输入路径才能访问，日常用建议开启。read only = no：共享层允许写。如果只读需求，改成read only = yes。valid users：限制哪些用户有资格访问这个共享。没写在里面的用户，即使有系统账号也进不来。write list：明确哪些用户可写。这里和valid users配合，可以做到"某些人能读，某些人能写"。create mask和directory mask：控制新创建文件的权限。0664、0775是日常办公比较合适的组合，不影响组成员写，其他人可读。force group = sambashare：强制所有新创建的文件都属于sambashare组，这样可以避免某个用户建的文件其他人写不了。
配置文件改完后，不要急着重启服务，先用测试工具检查一遍语法：
bash复制testparm
如果输出里没有 ERROR 字样，再平滑重载配置：
bash复制sudo systemctl restart smbd nmbd
重启之后再验证一下共享列表是否能看到，可以用本机测：
bash复制smbclient -L //127.0.0.1 -U zhangsan
输入密码后，如果列出来 data 这个共享，服务端配置就算基本通了。
2.4 防火墙和SELinux：最容易被遗忘的隐形拦截
很多Samba配置教程到这里就结束了，结果Windows一访问，要么转圈超时，要么弹出"找不到网络路径"。十有八九问题出在防火墙或者SELinux。
先开放Samba需要的端口。Samba服务监听的是135/TCP、137-138/UDP、139/TCP、445/TCP，其中445是最核心的。用firewalld的话，可以直接用现成的服务类别：
bash复制sudo firewall-cmd --permanent --add-service=samba
sudo firewall-cmd --reload
用ufw的话则是：
bash复制sudo ufw allow samba
如果是CentOS/RHEL系统，别忽略了SELinux。很多管理员都是先关掉再排错，其实没必要，开两个boolean就行：
bash复制# 允许Samba导出用户Home目录
sudo setsebool -P samba_enable_home_dirs on
# 允许Samba导出全部可写目录
sudo setsebool -P samba_export_all_rw on
-P 参数让设置永久生效。执行完这两条，SELinux基本就不会再拦截Samba的读写操作了。如果你发现访问共享时能读不能写、或者报权限以外的奇怪状态码，优先检查SELinux的拦截记录：
bash复制sudo ausearch -m avc -ts recent
有内容输出就说明确实被SELinux拦了，对照放行对应的boolean即可。
3. Windows客户端连接：图形界面和命令行的双路实践
3.1 GUI映射：给临时用户最快的上手方式
服务端配好了，Windows这边最简单的接入方式是图形界面。打开"此电脑"，右键选择"映射网络驱动器"，选择一个空闲盘符，在文件夹框输入：
code复制\\192.168.1.100\data
如果局域网里有DNS或WSD良好的环境，也可以输主机名，比如 \\samba-server\data。然后勾选"登录时重新连接"，输入账号密码后勾选"记住我的凭据"，点完成就能在资源管理器里看到这个盘符了。
这儿有个实际经验：很多用户勾了"登录时重新连接"，第二天开机照样弹红叉。这个现象Win7时代就有，直到现在的Win11也没完全根治，原因跟网络初始化的时机有关，后面第4章会专门展开讲手动脚本式映射的方案。所以GUI映射只适合临时用一下，生产环境还是建议上脚本。
还有一个细节：如果输入IP能访问，输入主机名反而打不开，或者资源管理器里能看到服务器图标但进去是空的，多半是NetBIOS名称解析没走通。这时候不用纠结解析问题，直接共享路径里填IP最稳。
3.2 命令行net use：稳定且适合脚本化
批量部署或者写自动化脚本时，net use 命令才是主力。几个最常用的写法：
bat复制:: 手动输入密码，交互式认证
net use Z: \\192.168.1.100\data /user:zhangsan *
:: 直接指定密码（脚本内使用）
net use Z: \\192.168.1.100\data /user:zhangsan 123456
:: 持久化映射，Windows重启后会自动重连
net use Z: \\192.168.1.100\data /user:zhangsan 123456 /persistent:yes
:: 查看当前所有映射
net use
:: 断开指定盘符
net use Z: /delete
:: 断开所有映射
net use * /delete
/persistent:yes 这个选项很关键，它会把映射关系写到注册表，Windows重启后会尝试自动重连。但要注意，日子久了如果服务器换了IP或者Samba重启过程中连接中断，系统留下的"僵尸连接"可能导致下一次映射时报"本地设备名已在使用中"。所以在脚本里做映射前，先 net use Z: /delete 清理一次，几乎是必写的前置命令。
凭据方面，Windows自己有一个凭据管理器，可以通过 cmdkey 预先把密码存下来。这样脚本里可以不用显式写密码，减少明文密码的暴露面：
bat复制cmdkey /add:192.168.1.100 /user:zhangsan /pass:123456
net use Z: \\192.168.1.100\data /persistent:yes
使用 cmdkey 之后，net use 就不需要再给账号密码了，系统会自动匹配凭据。这个思路在后面讲开机映射脚本时会再提到。
3.3 连接失败的快速自检链路
Samba连接不上时，我一般按这条链路逐层排查，基本能定位90%的问题：
- 网络通不通：在Windows命令行执行
ping 192.168.1.100。不通就回到网络配置上，看IP、掩码、网段。 - 端口通不通：
telnet 192.168.1.100 445或者 PowerShell里的Test-NetConnection 192.168.1.100 -Port 445。端口不通查Linux侧防火墙。 - 服务端共享列表有没有：在Linux上执行
smbclient -L //127.0.0.1 -U zhangsan。能列出data共享，说明服务端没问题，问题在认证或Windows侧。 - 看Samba日志：
/var/log/samba/log.smbd或log.192.168.1.x，里面有详细的认证失败、共享名错误信息。
下面这张表是我总结的常见Samba错误码对照，遇到对应提示直接对症下药：
| Windows错误提示 | 常见原因 | 解决办法 |
|---|---|---|
| NT_STATUS_ACCESS_DENIED | 共享权限不足或SELinux拦截 | 检查valid users/write list，查看SELinux拦截日志 |
| NT_STATUS_LOGON_FAILURE | 用户名或Samba密码错误 | 用smbpasswd重置密码，确认账号存在 |
| NT_STATUS_BAD_NETWORK_NAME | 共享名写错或path不存在 | 核对smb.conf里共享段名称，确认path目录存在 |
| NT_STATUS_HOST_UNREACHABLE | 网络不通或端口被防火墙拦截 | ping/Test-NetConnection排查445端口 |
| 找不到网络路径 | SMB1协议协商失败 | 在smb.conf加server min protocol = SMB2 |
4. 开机自动映射网络驱动器：三种落地方式
标题里最核心的需求是"开机自动映射登录"，这节我把实际用过的三种方式都放出来，按稳妥程度排序。
4.1 启动文件夹+批处理脚本：最简单的人门方案
这是最传统、最容易理解的方式：把一段映射脚本放到Windows的"启动"文件夹里，用户登录Windows后自动执行。
按 Win + R，输入 shell:startup，回车打开当前用户的启动文件夹。在里面放一个 .bat 脚本即可。脚本内容我推荐写成下面这样，比网上很多一行版严谨不少：
bat复制@echo off
set SHARE_SERVER=192.168.1.100
set SHARE_NAME=data
set DRIVE_LETTER=Z:
set SMB_USER=zhangsan
set SMB_PASS=123456
:: 先清理可能残留的旧映射
net use %DRIVE_LETTER% /delete >nul 2>&1
:: 简单等网络就绪，防止开机网络没起来导致映射失败
ping -n 5 %SHARE_SERVER% >nul
:: 执行映射
net use %DRIVE_LETTER% \\%SHARE_SERVER%\%SHARE_NAME% /user:%SMB_USER% %SMB_PASS% /persistent:yes
:: 把映射结果写日志，方便排错
echo %date% %time% >> %USERPROFILE%\map_drive.log
net use %DRIVE_LETTER% >> %USERPROFILE%\map_drive.log 2>&1
这个脚本的关键点在于：
- 先
net use Z: /delete，把系统里可能残留的旧连接清掉，避免"本地设备名已在使用中"。 ping -n 5让脚本短等几秒。Windows登录后网卡可能还在获取IP，或者Wi-Fi还没连上，不等直接映射几乎必失败。- 写日志。哪怕映射失败，打开日志就能知道是哪一步出的问题，不用每次靠猜。
把脚本存成 map_drive.bat 放进启动文件夹，下次登录Windows它会自动执行。这个方法够用，但有两个小毛病：一是在用户登录后才执行，如果用户不登录就永远不挂载；二是启动文件夹的脚本是"静默执行"，一旦失败没有明显提示，得手动看日志。对绝大多数办公场景来说，这两个毛病不致命。
4.2 计划任务：延迟执行加失败重试的职业方案
比启动文件夹更稳妥的办法是用Windows任务计划程序。好处是可以设置延迟、失败重试、以最高权限运行，可控性比启动文件夹高一个档次。
可以在任务计划程序GUI里创建，也可以直接用命令行：
bat复制schtasks /create /tn "MapDrive" /tr "C:\scripts\map_drive.bat" /sc onlogon /rl highest /f
关键参数：
/sc onlogon：在用户登录时触发。比启动文件夹多一个优势：计划任务能设置延迟，不用在脚本里靠ping硬等。/rl highest：以最高权限运行，避免某些共享目录因为普通权限写入受限。
命令行创建的任务默认没有延迟。图形界面创建时，建议在"触发器"选项卡里把"延迟任务时间"设成30秒，给网络初始化留足时间。如果想完全用命令行一步到位，也可以这样注册：
bat复制schtasks /create /tn "MapDrive" /tr "C:\scripts\map_drive.bat" /sc onlogon /delay 0000:30 /rl highest /f
/delay 0000:30 表示延迟30秒触发。
任务计划程序还有一个启动文件夹没有的优势：它可以在任务设置里勾选"如果任务失败，每隔5分钟重新启动一次，最多3次"。对于早上办公地点不稳定、Wi-Fi漫游严重的笔记本来说，这个重试机制可以说非常救命。
4.3 组策略登录脚本：域环境下最彻底的无人值守方案
如果你的Windows机器加入了Active Directory域，那最规范的做法是用组策略下发登录脚本。不用每台电脑去放启动文件夹或建计划任务，域控制器刷新组策略时自动分发。
单机版也能尝到这个功能的甜头。没有域控的机器，用 gpedit.msc 打开本地组策略编辑器，走这条路径：
用户配置 -> Windows设置 -> 脚本(登录/注销) -> 登录
然后在"登录"属性里添加脚本，把 map_drive.bat 的路径填进去。
组策略脚本和计划任务的区别在于，它由系统本身在登录阶段消费，脚本执行更早，但同样面临网络环境尚未就绪的问题。所以在这个方案里，脚本里的 ping -n 5 等待逻辑依然要保留。如果是在域环境，还能借助组策略的"在登录脚本中等待网络"策略项，系统会在网络完全可用后再跑脚本，体验比单机好很多。
4.4 关于脚本里密码的几点现实建议
三种方案绕不开一个问题：脚本里的明文密码。任何运维都不能回避安全风险，但也不能脱离实际环境一刀切。我自己的实践原则是这样的：
- Home目录和实验室环境：脚本直接写明文密码问题不大，因为网络本身是受信的，丢机器也就丢一台。
- 办公生产环境：优先用
cmdkey把密码存到Windows凭据管理器，让脚本不出现密码字段。 - 人员规模稍大或安全要求高：考虑把Samba接到Linux侧的LDAP或直接上Windows域认证，账号密码统一走域认证，脚本里完全不需要存密码。
- 风险兜底：脚本里不要用域管理员等特权账号跑映射，只用一个"能读能写指定共享"的普通账号，万一泄露，影响面可控。
坦白说，如果每一步都追求最安全，很多小团队反而会拖着一直不上Samba。不如先以一个低风险账号跑起来，等团队壮大了再平滑迁移到统一认证，这个路线现实得多。
5. 权限、SELinux与故障复盘：真实踩坑记录
5.1 一次"能ping通共享但打不开"的完整排查过程
前阵子同事反馈：从Windows能ping通Samba服务器，但在资源管理器输入 \\192.168.1.100\data 就是打不开，一直转圈报错。
我的排查链路是这样的。先在Windows上测端口：
powershell复制Test-NetConnection 192.168.1.100 -Port 445
结果没问题，445端口是通的。再回到Linux上，执行 smbclient -L //127.0.0.1 -U zhangsan，共享列表正常显示。
端口、共享列表都正常，那问题基本锁定在SELinux。查看拦截日志：
bash复制sudo ausearch -m avc -ts recent
果然出来一串Samba相关的AVC记录，都是 denied { read write }。执行前面说的两条setsebool命令放行后，Windows立刻就能打开了。
这个案例时隔很久我仍然记忆犹新，因为当时我已经把smb.conf翻了好几遍，还差点去改目录权限，压根没想到SELinux这层。现在配置Samba时，我习惯把SELinux放行命令直接写进部署清单里，不要等服务发现问题再补。
5.2 "明明加了valid users却还是写不进去"的三种原因
Samba共享权限是一个叠加体系，光在共享配置里加了 write list 还不够。以下三种情况会导致用户能进共享、能看文件，但写入就报"需要权限"：
- Linux文件系统权限不够：共享目录本身是
drwxr-x--，属组没有写权限，Samba用户自然写不进。解决办法：sudo chmod 2770 /srv/samba/data，并把用户的组设到sambashare。 - SELinux写权限被拦：
samba_export_all_rw这个boolean没开。放行命令上文已经给过。 - 磁盘配额或者目录属性限制：极少数情况是目录被设置了只读属性，用
lsattr /srv/samba/data看有没有i标志，有就chattr -i去掉。
判断到底是哪一层拦截，可以用 sudo tail -f /var/log/samba/log.smbd 边操作边看。日志里如果频繁出现 NT_STATUS_ACCESS_DENIED 但又看不出用户或共享名错误，那基本就是文件系统或SELinux层面的事了。
5.3 Windows睡眠唤醒后"红叉"问题
这是Windows映射网络驱动器最经典的"玄学Bug"：昨晚还好好的，第二天笔记本从睡眠唤醒，Z盘打了个红叉，双击提示"无法访问"。
产生这个问题的原因是网络驱动器映射在登录阶段建立后，系统休眠时网络连接被挂起，唤醒后SMB会话没有自动恢复，但Windows还没意识到连接已断开，盘符仍然显示着但已经失效。
对这种问题，我的思路是在映射脚本基础上加一个"修复"脚本。双击一下即可重连：
bat复制@echo off
net use Z: /delete >nul 2>&1
net use Z: \\192.168.1.100\data /user:zhangsan 123456 /persistent:yes
echo 修复完成
pause
如果红叉发生很频繁，可以把上面的修复逻辑也放到计划任务里，基于登录或解锁事件触发。方法是在任务计划程序里建一个任务，触发器选"解锁工作站"，操作运行修复脚本。这样一来，每次登录或解锁系统都会自动重连一遍Samba，红叉出现的概率几乎降为零。
5.4 给新手的部署清单和运维习惯
最后分享几个我踩了不少坑才形成的部署习惯：
- 配置文件改前先备份：
sudo cp /etc/samba/smb.conf /etc/samba/smb.conf.bak。Samba配置出问题不致命，但手一抖删错行，服务全都断，备份能救急。 - 配置改完先testparm再重启：testparm不仅能查语法，还能帮你发现拼写错误的关键字。
- 日志级别别开太高：开发调试时可以用
log level = 3看详细交互，生产环境调回默认2，否则日志会暴涨。 - 尽量减少匿名共享：
guest ok = yes和map to guest = Bad User虽然方便，但在公网或半信任网络下风险不小，建议只在纯内网且没有敏感文件的场景使用。 - 定期检查服务状态：我一般会在每个周一早上扫一眼
sudo systemctl status smbd和服务器磁盘水位，因为共享空间一满，整个团队就会开始反馈"文件保存失败"。
写在最后
Samba这套东西，配置本身并不复杂，难点往往在"你以为配好了，但它就是连不上"的排障过程。我的体会是：服务端先把端口、SELinux、权限三座大山按顺序过一遍，Windows端再把"能不能走脚本映射"作为核心目标而不是图一两次手点成功，这样你在后续的使用中就会省很多事。
至于开机自动映射，我个人最推荐的组合是计划任务 + 带日志的映射脚本，既解决延迟和执行时机问题，又能在出问题的时候有据可查。等哪天团队上了域环境，再顺势迁移到组策略登录脚本，体验还会再上一个台阶。最后再分享一个小技巧：映射好之后，在Windows里跑一次 net use Z: /persistent:yes，就算你之前忘记勾选"登录时重新连接"，后续重启系统也会自动尝试恢复这个盘符。