
简介面向Samba 4 AD-DC管理员与Debian运维人员的实用脚本合集汇集了作者在Debian Jessie/Stretch服务器上日常使用的工具覆盖Samba域备份、SePrivileges权限查看、sysvol ACL校验与设置、域信息查询等高频运维场景。压缩包共25个文件以Shell脚本为主12个sh另有9个txt操作指南与3个md说明文档整体仅71KB轻量易部署。已有247人学习浏览适合需要快速搭建和维护Samba 4域控的初中级运维工程师。脚本多来自生产环境实测其中backup_samba4基于官方备份脚本改进samba-check-set-sysvol.sh可自动检查并修复sysvol ACLsamba-info.sh同时支持AD成员和DC状态展示附带的多份how-to文本则提供从最小化AD部署到成员文件服务器配置的完整路径便于按需查阅和二次开发。 如果你维护过 Samba 4 域控估计跟我有一样的感受部署阶段翻翻文档两天就能搞定但真正折腾人的是上线之后的日常运维——新员工入职要挨个敲samba-tool user create业务部门开新共享你得反复调权限每周雷打不动的数据库备份、半夜服务挂掉被监控短信吵醒。这些重复劳动不解决域控管理员迟早要疯。我在 Debian Jessie 和 Debian Stretch 上维护 Samba 4 域控制器有两三年时间断断续续攒下一套脚本覆盖备份、批量建号、共享创建、服务自愈这四个高频场景纯 bash 实现核心只依赖samba-tool、systemd和常见的 GNU 工具不需要额外装重型依赖。今天把这套脚本的整体设计、核心代码和踩坑记录一起放出来正在维护 Samba 4 的朋友可以拿去直接用刚入门的朋友也能从里面看到一套域控日常运维的基本思路。1. 脚本集全貌我为什么攒下这套东西1.1 域控运维最耗时间的四个场景先说结论这套脚本不是花活纯粹被重复劳动逼出来的。Samba 4 域控上线后最高频的维护动作无非四类。第一是备份Samba 的域控数据不是单纯备份 smb.conf 就行里面还有 AD 数据库、sysvol、DNS 记录和各类 .tdb 文件目录结构分散靠手工打包极易漏东西而且在线状态下的备份要考虑一致性。第二是用户管理十几人的小规模倒是无所谓公司稍微大点批量入职的场景就来了一个个执行samba-tool user create不仅累还容易因为密码策略不满足导致命令中断脚本里必须考虑自动跳过和错误收集。第三是共享目录创建在 AD 环境里开新共享不只是改 smb.conf还涉及 POSIX 权限、SELinux虽然 Debian 默认没有、Samba 侧权限的联动手工操作漏一步后面就是各种访问异常。第四是服务状态保障AD 域控挂了不是小事客户端缓存过期后连登录都会受影响需要一种轻量级的自愈手段。针对这四个场景我分别写了samba-ad-backup.sh、samba-user-import.sh、samba-share-create.sh和samba-monitor.sh。每个脚本都保持单一职责互不依赖可以独立部署到任意一台域控上。1.2 环境选型Jessie 和 Stretch 的取舍选择 Debian Jessie8和 Debian Stretch9做验证环境原因很朴素当时生产环境就是这两个版本而且它们的 Samba 版本差异恰好覆盖了两个有代表性的版本线。Jessie 自带 Samba 4.2Stretch 自带 Samba 4.5。4.5 版本开始官方推出了samba-tool domain backup系列命令非常好用但 4.2 上根本没有这个子命令所以我的备份脚本里特意做了版本判断低版本走手动打包 plus 一致性校验的路线高版本直接调官方工具。这套设计思路到现在也不过时因为很多企业还在用 Samba 4.4 ~ 4.7 之间的小版本。1.3 仓库结构与依赖说明脚本集的结构很简单没有用复杂目录树全部放在根目录下。除了四个核心脚本还有一个lib/目录放公共函数类似日志格式统一、配置文件解析这些逻辑。所有脚本都用#!/usr/bin/env bash开头执行时依赖bash、samba-tool、systemctl、tar、grep、awk、ip这几个基础组件Debian 默认安装基本都带唯一可能需要手动装的是samba-tool对应的 samba-common-bin 包。2. 核心脚本功能拆解2.1 备份脚本离线与在线备份双保险备份脚本是全套脚本里优先级最高的。Samba 4 域控的数据在运行期处于持续写入状态简单复制文件不能保证一致性轻则备份文件损坏重则恢复出来的 AD 数据库在域内引发复制冲突。在高版本 Samba 上我优先使用官方提供的离线备份方式#!/bin/bash # samba-ad-backup.sh - Samba 4 域控数据库备份 set -euo pipefail BACKUP_DIR${1:-/var/backups/samba} KEEP_DAYS${2:-14} LOG_FILE/var/log/samba-backup.log log() { echo $(date %Y-%m-%d %H:%M:%S) - $* | tee -a $LOG_FILE } if ! command -v samba-tool /dev/null 21; then log 错误: 未找到 samba-tool请安装 samba-common-bin exit 1 fi mkdir -p $BACKUP_DIR # Samba 4.5 使用官方备份命令 if samba-tool domain backup offline --help /dev/null 21; then log 检测到 Samba $(samba-tool --version | grep -oE [0-9]\.[0-9] | head -1)使用 domain backup offline samba-tool domain backup offline --targetdir$BACKUP_DIR 2$LOG_FILE else log Samba 版本较旧回退到手动打包模式 tar czf $BACKUP_DIR/samba-manual-$(date %Y%m%d%H%M).tar.gz \ /etc/samba/ \ /var/lib/samba/ \ /var/cache/samba/ 2$LOG_FILE fi # 清理过期备份 find $BACKUP_DIR -name *.tar.bz2 -mtime $KEEP_DAYS -delete find $BACKUP_DIR -name *.tar.gz -mtime $KEEP_DAYS -delete log 备份完成备份目录: $BACKUP_DIR这里有几个细节值得说明。set -euo pipefail是 bash 脚本的保险三件套-e让脚本在遇到错误时立即退出-u防止变量未定义-o pipefail让管道中任一步骤失败都能被捕获。备份我是建议先做离线备份因为在线备份虽然服务不中断但数据一致性依赖 Samba 内部的机制在繁忙时段仍有可能打快照出错。执行备份的时机放在凌晨低峰期比较稳妥用 cron 或者 systemd timer 调度。对于旧的 Samba 4.2手动打包tar的路径覆盖了 Samba 的配置、数据、缓存三块打包前我会先执行samba-tool dbcheck做一次数据库一致性检查确保库本身没有基础性损坏再打包这一点脚本里没体现实际建议加上。2.2 建号脚本CSV 批量导入用户批量建号在市场部、销售部这种人员流动快的部门是刚需。我从 HR 系统导出的员工表整理成固定格式的 CSV脚本读取后逐行创建。#!/bin/bash # samba-user-import.sh users.csv # CSV 列顺序: 用户名,显示名,部门,初始密码 set -euo pipefail CSV_FILE${1:?用法: $0 users.csv} LOG_FILE/var/log/samba-user-import.log PASSWD_DEFAULTChangeMe2024 if [ ! -f $CSV_FILE ]; then echo 错误: CSV 文件不存在 exit 1 fi # 跳过 CSV 中的注释行和空行 grep -vE ^\s*(#|$) $CSV_FILE | while IFS, read -r username displayname department password; do # 去掉首尾空格 username$(echo $username | xargs) displayname$(echo $displayname | xargs) department$(echo $department | xargs) password${password:-$PASSWD_DEFAULT} if [ -z $username ]; then continue fi # 检查用户是否已存在 if samba-tool user show $username /dev/null 21; then echo $(date %F %T) - 用户 $username 已存在跳过 | tee -a $LOG_FILE continue fi # 创建用户并附加 AD 属性 if samba-tool user create $username $password \ --given-name$displayname \ --department$department \ --must-change-at-next-login /dev/null 21; then echo $(date %F %T) - 成功创建用户: $username | tee -a $LOG_FILE else echo $(date %F %T) - 创建失败: $username可能是密码策略不满足 | tee -a $LOG_FILE fi done脚本的关键在于密码策略处理。--must-change-at-next-login是 Samba 4 域控的常见做法管理员先设置一个统一的临时密码强制用户首次登录修改。这样即使 CSV 里初始密码相同也不会造成长期安全问题。另外一个坑Samba 密码复杂度策略默认开启初始密码最好带上大小写字母数字和特殊字符否则脚本会在创建阶段就收到“密码不满足复杂度要求”的报错。CSV 文件最好用dos2unix转换一下换行符在 Windows 上编辑过 CSV 直接拿到 Linux 上跑\r会粘在最后一个字段后面导致用户属性异常。2.3 共享创建脚本一条命令开好一个共享共享目录创建脚本负责把 smb.conf 追加、目录创建、权限设置、配置校验这几个动作串起来。AD 环境下最忌讳的就是手工补配置因为 Samba 侧的valid users、POSIX 侧的属主权限、共享目录本身的实际路径三者一旦不一致排查起来非常头疼。#!/bin/bash # samba-share-create.sh 共享名 本地路径 [备注] set -euo pipefail SHARE_NAME${1:?用法: $0 共享名 本地路径 [备注]} SHARE_PATH${2:?用法: $0 共享名 本地路径 [备注]} SHARE_COMMENT${3:-Shared Directory} # 目录不存在则创建并设置属主为 Domain Admins if [ ! -d $SHARE_PATH ]; then mkdir -p $SHARE_PATH chown root:domain admins $SHARE_PATH fi chmod 2770 $SHARE_PATH cat /etc/samba/smb.conf EOF [$SHARE_NAME] path $SHARE_PATH comment $SHARE_COMMENT browseable yes read only no guest ok no valid users $SHARE_NAME_rw write list $SHARE_NAME_rw create mask 0660 directory mask 0770 inherit permissions yes EOF # 校验配置 testparm -s /dev/null systemctl reload smbd echo 共享 $SHARE_NAME 已创建对应 AD 组 ${SHARE_NAME}_rw 需要提前创建共享目录使用setgidchmod 2770是一个容易忽略但极其重要的细节。有了 setgid目录内新建的文件会自动继承目录的属组这样同一个共享下面所有人创建的内容组权限能保持一致不会出现一个人建了文件同事访问不了的尴尬。valid users指定了域组比如sales_rw这意味着接脚本之前你得先在 AD 里建好对应的组把相关人员加进去。这是刻意把权限模型简化避免往 smb.conf 里塞一堆主机 ACL后续维护时自己都看不懂。2.4 监控脚本服务挂掉自动拉起来监控脚本的作用不是替代 Nagios、Zabbix 这种专业监控系统而是做一个内建的快速自愈层。域控这种核心节点服务异常时能第一时间自己恢复优先级比通知人还高。#!/bin/bash # samba-monitor.sh set -euo pipefail # AD DC 模式下需要关注的三个服务 SERVICES(samba-ad-dc smbd nmbd) NOTIFY_EMAILadminexample.com for svc in ${SERVICES[]}; do if systemctl is-active --quiet $svc; then continue fi echo $(date %F %T) - 服务 $svc 异常尝试重启 /var/log/samba-monitor.log systemctl restart $svc # 重启后等待 5 秒再检查一次 sleep 5 if systemctl is-active --quiet $svc; then systemctl start sendmail 2/dev/null || true # 简单邮件通知这里依赖本地的 sendmail 兼容程序 printf Samba 服务 %s 已自动恢复 $svc | mail -s [Samba] $svc 自动恢复 $NOTIFY_EMAIL fi done需要注意在纯 AD DC 模式下很多老教程会告诉你把 smbd、nmbd 服务禁用只保留 samba-ad-dc。实际在 Debian 的打包环境下三个服务是拆开的samba-ad-dc 负责域控职责smbd/nmbd 负责文件共享和 NetBIOS 功能。所以这里三个都监控而不是一刀切只看 samba-ad-dc。监控脚本建议用 systemd timer 每 2 分钟执行一次不要用 cronsystemd timer 可以把执行日志纳入 journald出问题查日志更直观。3. 部署实操从裸机到脚本跑通3.1 基础环境准备假设你已经装好了 Debian第一件事不是装 Samba而是把网络和源搞定。Debian 的网卡配置在/etc/network/interfaces但 Stretch 默认装完系统后如果还启用了 systemd-networkd两者可能打架表现就是配置了静态 IP 但重启后不生效。我个人的习惯是只保留一个网络管理方案要么全部走/etc/network/interfaces要么全部走 systemd-networkd避免双份配置互相覆盖。双网卡机器上还有一个很常见的坑两个网口分别连内网和业务网默认路由经常串线。需要在/etc/network/interfaces里给业务网口加上metric 100内网口metric 200否则流量会走错出口域控跟客户的通信时好时坏。这个坑排查起来特别隐蔽因为 ping 外网是通的但域内客户端就是加不进域。装包很简单一步到位apt install samba samba-common-bin smbclient winbind在 Stretch 上如果机器要纯做 AD DC不建议装 winbindSamba 4 自带内置的 LDAP 和 DNSwinbind 反而可能干扰。做成员服务器才需要 winbind。装完后先别急着配置把所有脚本拉到一个约定目录比如/usr/local/sbin/samba-tools/下面确保可执行权限。3.2 smb.conf 关键配置AD DC 模式下 smb.conf 由samba-tool domain provision自动生成正常情况下不需要手工调整。我遇到的唯一高频调整是在 variables 区加日志级别和日志大小[global] log level 2 log file /var/log/samba/log.%m max log size 10000 server role active directory domain controllerlog level 不建议一上来就拉满到 5AD DC 高频环境下日志量非常惊人24 小时能产生几个 GB 的日志排查问题时临时调整级别排查完降回去才是正常做法。log file按客户端机器名分文件多人访问时定位问题非常方便。另外如果文件共享和 AD DC 在同一个节点[global]下记得加min protocol SMB2_10老协议漏洞多SMBv1 在域控上一定要禁用。Samba 4.2 在 Jessie 上默认还能开 SMB1Stretch 的 4.5 版本已经默认关闭但老配置升上来时还是要检查一遍。3.3 脚本部署与验证脚本本身不需要安装复制到目录后加执行权限即可用。建议先用bash -n 脚本名做语法检查再跑bash -x看调试输出。我每写一个脚本都会先在测试域的备机上面完整跑一遍备份和恢复流程确认恢复后的域控能正常参与复制才上生产。这种备份不可恢复等于没备份的教训我见得太多了。首次部署建议按这个顺序验证先跑备份脚本确认备份目录下有文件生成再跑监控脚本确认服务状态判断正常接着造一个测试用户在非生产 OU 里跑一次批量导入最后才创建共享。一个环节一个环节过不要一上来全链路跑出问题不好定位。4. 实战排坑Debian 上的那些坑4.1 网络配置的坑我把网络问题单独拎出来说因为 Samba 域控对网络稳定性的要求极高而 Debian 的网络配置恰恰容易在这几个地方翻车。第一是/etc/network/interfaces里写了auto eth0但 eth0 实际被 systemd 重命名成了 ens3 或 enp0s3导致网卡起不来。Debian Jessie 还在用 eth 系列命名Stretch 引入了可预测命名规则以后网卡名经常变成en*写配置前先执行ip link确认实际接口名。第二是双网卡默认路由问题前面提过用 metric 解决。第三是 DNS 配置Samba 4 自带 DNS 服务域控的/etc/resolv.conf应该把本机 IP 放在第一位外部 DNS 放在后面否则客户端执行 DNS 查询可能跳到外部 DNS 上拿不到正确的域记录。4.2 脚本调试技巧我的经验是不要直接在生产的域控上面边改边跑先在备机或虚拟机里完整模拟一遍。调试时打开bash -x就能看到每一步变量的展开值大部分错误一眼就能定位。还有一个容易翻车的点samba-tool 命令默认连接到本机运行中的 Samba 服务调试时如果服务没起来会直接报连接失败而不是命令不存在。所以脚本里第一步应该检查服务状态而不是盲目执行后续逻辑。如果发现脚本行为跟预期不一致优先查日志。Samba 的日志在/var/log/samba/下注意看 log.samba 和 log.smbd里面记录了认证失败、共享访问被拒的详细原因。很多权限问题在 Windows 客户端上只显示拒绝访问日志里却能明确看到是 POSIX 权限不足还是 Samba 配置拒绝。4.3 常见错误速查表现象可能原因排查/解决办法运行 samba-tool 提示找不到命令samba-common-bin 未安装或 PATH 未包含/usr/bin执行apt install samba-common-bin确认which samba-tool备份脚本报 domain backup 子命令不存在Samba 版本低于 4.5脚本会自动回退到手动打包模式或升级到 Stretch 以上用户导入时部分用户创建失败密码不满足复杂度要求初始密码改为包含大小写字母、数字、特殊字符或用--must-change-at-next-login共享创建后 Windows 客户端访问提示无权限POSIX 属主/属组不正确检查共享目录ls -l确认属主是 root属组是domain admins权限至少 770smbd 服务反复重启失败smb.conf 存在语法错误执行testparm定位具体错误行客户端无法连接域控本机 DNS 配置未指向域控自身检查/etc/resolv.conf确保域控自身 IP 在第一位系统日志里大量 avahi 相关错误系统默认开启了 avahi-daemon与 Samba 的 mDNS 冲突在 AD DC 上执行systemctl disable --now avahi-daemoncron 执行备份脚本没有产生日志cron 环境 PATH 不完整cron 里显式写/usr/local/sbin/脚本脚本开头导出PATH/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin排查 Samba 问题时不妨先按这个顺序看网络能否 ping 通、DNS 解析是否正确、看服务systemctl 状态、看日志/var/log/samba、看配置testparm。绝大多数问题都逃不出这四个环节。最后再分享一点体会。这套脚本跟着我度过了从 Samba 4.2 到 4.5 的迁移周期最值钱的经验倒不是某个脚本本身而是脚本要随环境演进这件事。Samba 的版本迭代很快官方在 4.5 之后又加了更多samba-tool子命令我现在用的备份逻辑已经不是当初刚写的版本而是根据生产环境实际遇到过的备份失败案例调整过的。所以你在参考这套方案时也别把它当终点当成一个起点跑一段时间后把你自己环境里那些特殊的目录、特殊的权限模型、特殊的业务节奏沉淀进去这套脚本才是真正长了腿。本文还有配套的精品资源点击获取