Samba 4 运维脚本实战:sysvol 备份、域信息巡检与避坑指南 简介这份资源面向在 Debian Jessie 与 Stretch 上部署和维护 Samba 4 AD-DC 的运维人员与系统管理员汇集了作者日常使用的实用脚本用于解决域控备份、SePrivileges 权限核查、sysvol ACL 设置与域信息查看等常见运维问题适合具备一定 Linux 与 Samba 基础的中级读者参考。压缩包共 25 个文件以 12 个 sh 脚本为主体辅以 9 个 txt 操作记录与 howto 说明、3 个 md 文档及 1 个 backup_samba4 备份脚本整体约 71KB体积轻量便于随取随用。目前已有 250 人学习。内容覆盖最小化 AD 搭建、成员文件服务器权限示例、DNS 批量添加、数据库复制检查与调试信息收集等场景读者可据此快速完成域控备份、权限校验与故障排查并借助 howto 文档理解各脚本的配置思路与适用边界。1. 一套被低估的 Samba 4 运维脚本从 sysvol 备份到域信息巡检手里管着一台 Debian 上的 Samba 4 域控最怕的不是搭起来而是搭起来之后没人管。sysvol 共享被误删、域账号信息查不全、备份脚本跑了一半报错退出这些事在小型办公网络里几乎每周都能撞上一次。这套脚本资源就是冲着这些日常运维动作去的一组围绕 Samba 4 的 Shell 脚本覆盖 sysvol 备份、域信息采集、状态巡检等场景作者明确说在 Debian Jessie 和 Debian Stretch 上做过测试。它不适合想从零学 Samba 原理的人适合已经把域控跑起来、需要一套能直接改参数就用的运维工具的人。下面按「脚本能干什么、怎么落地、哪里会翻车」的顺序拆开讲中间会给可直接抄的调用方式和参数说明。2. 脚本包的能力边界先搞清楚每个脚本管哪一段拿到一个 Shell 脚本包第一件事不是急着执行而是先读它到底调了哪些 Samba 自带命令。这套脚本的价值不在于发明新东西而在于把samba-tool、smbclient、rsync这些零散命令封装成有固定输出、有退出码、能塞进 cron 的运维单元。理解这一点后面改参数和排错才有依据。2.1 从 samba-tool 派生出来的三类脚本Samba 4 自带samba-tool这个管理入口域用户、组、DNS 记录、域级别信息都能查但它的子命令多、输出格式偏原始直接拿来做巡检不友好。这套脚本大致分三类第一类是信息采集型把samba-tool domain info、samba-tool user list、samba-tool group list的输出整理成可读文本第二类是备份型核心是 sysvol 目录的同步与归档第三类是状态检查型判断 smbd、nmbd 进程和关键共享是否正常。信息采集型脚本通常长这样本质是对samba-tool做一层包装#!/bin/bash # samba-info.sh - 采集域基础信息输出到指定目录 set -euo pipefail OUT_DIR${1:-/var/log/samba-info} DC_FQDNdc01.example.lan # 改成自己的域控 FQDN mkdir -p $OUT_DIR STAMP$(date %Y%m%d-%H%M%S) { echo domain info samba-tool domain info $DC_FQDN echo user list samba-tool user list echo group list samba-tool group list } $OUT_DIR/samba-info-$STAMP.txt 21 echo written: $OUT_DIR/samba-info-$STAMP.txt这段的关键在set -euo pipefail任何一条samba-tool子命令失败脚本立刻退出并保留非零退出码cron 才能感知到异常。DC_FQDN必须换成实际域控名写localhost在部分子命令下会拿不到完整域信息。输出重定向用21把错误也收进文件否则排错时只剩一个空文件等于给自己挖坑。OUT_DIR用位置参数传入默认落到/var/log/samba-info方便按天归档。2.2 sysvol 备份脚本的同步模型sysvol 是 Samba 4 域控里最不能丢的目录组策略对象、登录脚本、NETLOGON 共享全在里面。这套脚本的备份思路通常是「本地快照 异地同步」两段式先用rsync把/var/lib/samba/sysvol同步到一个本地暂存目录再打包或推送到备份位置。之所以不直接tar原目录是因为 sysvol 在运行中可能被写入直接打包容易拿到不一致的状态。#!/bin/bash # samba-sysvol-backup.sh - sysvol 本地快照 归档 set -euo pipefail SRC/var/lib/samba/sysvol/ STAGE/var/backups/samba/sysvol-stage/ DEST/var/backups/samba/archive/ STAMP$(date %Y%m%d-%H%M%S) KEEP_DAYS14 mkdir -p $STAGE $DEST # 第一段增量同步到暂存目录--delete 保证暂存与源一致 rsync -aHAX --delete $SRC $STAGE # 第二段从暂存目录打包避免直接读运行中的源 tar -czf $DEST/sysvol-$STAMP.tar.gz -C $STAGE . # 清理超过保留期的归档 find $DEST -name sysvol-*.tar.gz -mtime $KEEP_DAYS -delete echo backup done: $DEST/sysvol-$STAMP.tar.gz-aHAX这几个参数不是凑数的-a保留权限和时间戳-H保留硬链接-A保留 ACL-X保留扩展属性。sysvol 里的 GPO 目录带 ACL少了-A恢复后权限会乱客户端组策略直接失效这是血泪经验。--delete让暂存目录严格镜像源目录删掉的 GPO 不会在备份里阴魂不散。KEEP_DAYS控制归档保留天数按磁盘容量调14 天对小型域够用。注意tar的-C $STAGE .写法打包的是暂存目录内容而不是目录本身恢复时解压路径才对得上。2.3 脚本之间的调用关系与执行顺序这套脚本不是各自为政的正常运维节奏是信息采集脚本每天跑一次留档sysvol 备份脚本按小时或按天跑状态检查脚本频率更高。它们共享同一个日志目录和同一套环境变量约定所以部署时最好统一放到/usr/local/sbin/samba-scripts/日志统一落到/var/log/samba-scripts/。脚本类型建议频率依赖命令失败影响信息采集每天 1 次samba-tool仅缺巡检记录sysvol 备份每天 1 次或每 6 小时rsync、tar丢失恢复点状态检查每 15 分钟systemctl、smbclient故障发现延迟执行顺序上状态检查应该最先跑确认服务活着再谈备份备份脚本和信息采集可以并行但别在同一分钟触发避免samba-tool和rsync同时压 IO。常见做法是用 cron 错开比如状态检查*/15备份30 2 * * *信息采集45 2 * * *。3. 在 Debian 上落地依赖、权限与 cron 编排脚本能跑起来的前提是环境对。Debian Jessie 和 Stretch 这两个版本的系统自带软件包版本差异不小Samba 4 的路径和samba-tool子命令输出也有细微区别落地时得按实际系统微调不能照搬。3.1 依赖检查与最小安装先确认samba-tool、rsync、smbclient都在。Debian 上 Samba 4 域控通常由samba包提供samba-tool随包安装rsync和smbclient可能要单独装。Jessie 的软件源较老装之前先apt-get update否则容易拿到过期索引导致依赖解析失败。# 检查关键命令是否存在 for cmd in samba-tool rsync smbclient tar; do command -v $cmd /dev/null 21 || echo MISSING: $cmd done # Debian 上补齐依赖Jessie/Stretch 通用 apt-get update apt-get install -y rsync smbclientcommand -v比which可靠在非交互 Shell 里也能正确返回。循环里只报缺失不退出是为了让你一次看全所有缺的命令而不是修一个跑一次。smbclient在状态检查脚本里用来测试共享连通性缺了它状态检查会误报。装完再跑一遍检查确认没有MISSING输出。3.2 权限模型为什么不能直接用 root 裸跑sysvol 目录权限敏感脚本如果用 root 直接跑生成的归档文件属主全是 root恢复时可能和 Samba 内部的权限映射冲突。更稳妥的做法是建一个专用运维账号加入sambashare组或对 sysvol 有读权限的组备份脚本以该账号执行归档文件属主清晰。# 创建专用备份账号并授权读取 sysvol useradd -r -s /usr/sbin/nologin sambabak chgrp -R sambabak /var/lib/samba/sysvol chmod -R grX /var/lib/samba/sysvol # 归档目录归该账号所有 mkdir -p /var/backups/samba chown -R sambabak:sambabak /var/backups/samba-r建系统账号-s /usr/sbin/nologin禁止登录降低被滥用的面。grX里的X只给目录加执行位、给已有执行位的文件保留执行位避免把普通文件误设成可执行。改完权限记得验证用sudo -u sambabak rsync -aHAX --dry-run /var/lib/samba/sysvol/ /tmp/test-stage/空跑一次能列出文件清单才算权限到位。这一步别省权限没配对cron 里跑起来只会给你一封看不懂的报错邮件。3.3 cron 编排与日志落盘cron 环境和你登录 Shell 的环境不一样PATH 往往只有/usr/bin:/binsamba-tool如果在/usr/sbin下就会找不到。所以脚本里要么写全路径要么在 crontab 顶部显式设 PATH。日志统一重定向到文件别指望 cron 默认邮件很多机器根本没配 MTA。# /etc/cron.d/samba-ops PATH/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin SHELL/bin/bash */15 * * * * sambabak /usr/local/sbin/samba-scripts/samba-check.sh /var/log/samba-scripts/check.log 21 30 2 * * * sambabak /usr/local/sbin/samba-scripts/samba-sysvol-backup.sh /var/log/samba-scripts/backup.log 21 45 2 * * * sambabak /usr/local/sbin/samba-scripts/samba-info.sh /var/log/samba-scripts/info.log 21/etc/cron.d/下的文件格式比crontab -e多一个用户字段这里就是sambabak。PATH 显式声明解决命令找不到的问题。追加而不是覆盖保留历史便于回溯。日志文件本身也要有轮转否则几个月后能把分区写满常见做法是配一条logrotate规则按周切割、保留 8 份。cron 任务上线后头两天一定要手动tail -f盯一下日志确认没有静默失败。4. 避坑与排查五个真实会撞上的问题脚本跑不顺八成不是脚本本身写错而是环境假设不成立。下面这几条是这类 Samba 4 运维脚本落地时最常翻车的地方按「现象 → 原因 → 解决」记下来能省不少排查时间。4.1 备份归档恢复后组策略失效现象从sysvol-*.tar.gz解压恢复后客户端gpupdate报找不到 GPO或者策略不生效。原因打包时漏了 ACL 或扩展属性tar默认不保留这些恢复后 GPO 目录权限和原环境不一致。解决打包命令必须带--acls --xattrs或者用tar --acls --xattrs -czf更稳的是恢复后用samba-tool ntacl sysvolreset重置 sysvol 的 NT ACL再让客户端重新拉策略。这条坑的根因在备份阶段别等恢复了才发现。4.2 cron 里 samba-tool 报 command not found现象手动执行脚本正常cron 触发就报samba-tool: command not found。原因cron 的 PATH 不含/usr/sbin而 Debian 上samba-tool常装在那里。解决在/etc/cron.d/文件顶部显式设PATH或在脚本里用绝对路径调用。验证方法是env -i /bin/bash -c /usr/local/sbin/samba-scripts/samba-info.sh模拟最小环境跑一遍能过就说明 PATH 问题解决了。4.3 rsync 同步 sysvol 时权限拒绝现象备份脚本在rsync阶段报Permission denied部分子目录没同步过去。原因执行账号对 sysvol 下某些 GPO 目录没有读权限或者 ACL 挡住了组权限。解决先sudo -u sambabak rsync -aHAX --dry-run定位具体路径再针对性补setfacl或调整组归属不要图省事直接chmod -R 777那会把 Samba 的权限模型彻底搞乱恢复时更麻烦。4.4 归档文件越积越多把磁盘写满现象某天备份突然失败日志报No space left on device。原因find ... -mtime N -delete的清理逻辑没生效常见是-name模式和实际文件名对不上或者KEEP_DAYS设得过大。解决先ls -lh看归档目录实际占用再单独跑一遍find的-print版本确认匹配到的文件确认无误再换成-delete。清理逻辑上线前一定先用-print空跑。4.5 状态检查脚本误报服务正常现象smbd进程挂了但状态检查脚本仍返回成功。原因脚本只判断了进程名存在没验证端口或共享是否真的可访问僵尸进程或半死状态骗过了检查。解决检查逻辑改成「进程 端口 共享探测」三重判断用smbclient -L localhost -N实际列一次共享返回非零才算异常。单看pgrep smbd是不够的这个坑在半夜告警失灵时最要命。5. 进阶用法把脚本变成可验证的巡检闭环脚本能跑只是及格线真正省心的是让它自己证明「备份是好的、恢复是可行的」。我一般会在备份脚本后面挂一个轻量校验每次归档完成后从归档里抽一个已知的 GPO 目录解压到临时位置比对文件数和关键文件是否存在校验失败就返回非零退出码让 cron 的告警链路接住。#!/bin/bash # verify-sysvol-backup.sh - 校验最新归档可解压且内容完整 set -euo pipefail ARCHIVE$(ls -t /var/backups/samba/archive/sysvol-*.tar.gz | head -n1) TMP$(mktemp -d) trap rm -rf $TMP EXIT tar -tzf $ARCHIVE /dev/null # 先验证归档本身没损坏 tar -xzf $ARCHIVE -C $TMP --acls --xattrs # 关键目录存在性检查路径按实际域调整 for p in $TMP/policies $TMP/scripts; do [ -d $p ] || { echo MISSING in archive: $p; exit 1; } done COUNT$(find $TMP -type f | wc -l) echo verify ok: $ARCHIVE, files$COUNTtar -tzf只列不解先确认归档没被截断这一步能挡住磁盘写满导致的半截包。trap ... EXIT保证临时目录一定被清理不然校验脚本自己会变成磁盘杀手。关键目录检查按实际 sysvol 结构改policies和scripts是最常见的两个顶层目录。COUNT输出到日志方便对比历史值文件数突然腰斩往往意味着源目录出过问题。再进一步可以把校验结果和备份时间写进一个状态文件状态检查脚本读这个文件判断「最近一次备份是否成功且已校验」形成闭环。参数上校验频率不必和备份一样高每天备份后跑一次即可告警阈值可以设成「连续两次校验失败」再触发避免偶发 IO 抖动造成误报。这套组合跑顺之后sysvol 这块基本可以从日常焦虑清单里划掉。从那以后我每次给 Samba 4 域控加运维脚本都强制先跑一遍「最小环境模拟 归档解压校验」两步都过才敢挂 cron。希望帮到你。本文还有配套的精品资源点击获取