Samba 4域控运维自动化：备份、批量建号、共享创建与自愈脚本实战

简介：面向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 ACL，samba-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 Jessie（8）和 Debian Stretch（9）做验证环境，原因很朴素：当时生产环境就是这两个版本，而且它们的 Samba 版本差异恰好覆盖了两个有代表性的版本线。Jessie 自带 Samba 4.2，Stretch 自带 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 2>&1; 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 2>&1; 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_DEFAULT="ChangeMe@2024" 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 2>&1; 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 2>&1; 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 需要提前创建"

共享目录使用setgid（chmod 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_EMAIL="admin@example.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 分钟执行一次，不要用 cron，systemd 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，不建议装 winbind，Samba 4 自带内置的 LDAP 和 DNS，winbind 反而可能干扰。做成员服务器才需要 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 controller

log level 不建议一上来就拉满到 5，AD DC 高频环境下日志量非常惊人，24 小时能产生几个 GB 的日志，排查问题时临时调整级别，排查完降回去才是正常做法。log file按客户端机器名分文件，多人访问时定位问题非常方便。

另外，如果文件共享和 AD DC 在同一个节点，[global]下记得加min protocol = SMB2_10，老协议漏洞多，SMBv1 在域控上一定要禁用。Samba 4.2 在 Jessie 上默认还能开 SMB1，Stretch 的 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 问题时不妨先按这个顺序：看网络（能否 ping 通、DNS 解析是否正确）、看服务（systemctl 状态）、看日志（/var/log/samba）、看配置（testparm）。绝大多数问题都逃不出这四个环节。

最后再分享一点体会。这套脚本跟着我度过了从 Samba 4.2 到 4.5 的迁移周期，最值钱的经验倒不是某个脚本本身，而是"脚本要随环境演进"这件事。Samba 的版本迭代很快，官方在 4.5 之后又加了更多samba-tool子命令，我现在用的备份逻辑已经不是当初刚写的版本，而是根据生产环境实际遇到过的备份失败案例调整过的。所以你在参考这套方案时，也别把它当终点，当成一个起点，跑一段时间后把你自己环境里那些特殊的目录、特殊的权限模型、特殊的业务节奏沉淀进去，这套脚本才是真正长了腿。

本文还有配套的精品资源，点击获取