前几天一个同事半夜给我打电话说生产环境的一个Samba共享里某个项目文件突然消失了问了一圈没人承认删过。我登录TrueNAS一看共享是开了但Samba没有配任何审计日志里干干净净连谁连过、什么时候连的、做了什么操作一概没有记录。最后只能靠快照恢复文件但谁删的这个问题永远没有答案。那次之后我认真研究了一遍TrueNAS上Samba的Full_Audit审计日志配置把CORE和SCALE两种版本都试了一遍也踩了不少坑。这篇文章就是我整理出来的完整实例覆盖Full_Audit模块的原理、UI和命令行的配置方法、日志留存180天的方案以及我在实战中遇到的各种疑难杂症。适合正在用TrueNAS做文件共享、又需要对文件操作留痕的运维和存储管理员参考。1. 为什么审计日志会成为Samba共享的刚需1.1 一次把我逼到墙角的文件凭空消失事件先说回开头那个事故。那是一个设计团队的共享目录里面放的都是高精度PSD和工程文件单个文件好几个GB。删除操作发生在下午三点左右等到晚上七点多同事发现时已经过了四个小时。期间又有其他人往同一个目录写过文件快照回滚的话这四小时内的新增内容也会一起丢失。当时我查了TrueNAS的SMB服务状态、看了/var/log/samba/log.smbd只能看到连接建立的记录完全看不到文件级别的操作。后来才知道Samba默认的日志记录的是连接、协议错误这类信息它不记录谁删除了哪个文件。想要知道这类操作必须给Samba挂上VFS审计模块也就是Full_Audit。这个经历给我的教训很直接文件共享上了生产环境审计日志不应该当作可选项而应该是部署清单里的一部分。它平时看起来没什么用一旦出问题就是唯一的溯源依据。1.2 Full_Audit到底审计了什么Full_Audit是Samba自带的VFS模块之一它的作用是拦截Samba处理的各种文件系统操作按照你配置的规则把成功或失败的事件写入syslog或者独立的日志文件。它能记录的事件很多但常用的其实就这些事件触发时机审计价值connect客户端建立SMB会话谁在什么时间连上来了disconnect会话断开连接时长分析open打开文件访问了哪个文件close关闭文件操作结束read/pread读取文件内容不适合全量开启量太大write/pwrite写入文件不适合全量开启量太大rename重命名文件文件被改名unlink删除文件谁删的、删的哪个文件mkdir/rmdir创建/删除目录目录结构变更chmod/fchmod修改权限权限被篡改chown/fchown修改属主属主被篡改opendir打开目录目录浏览行为ftruncate截断文件文件被清空需要注意的是Full_Audit记录的是操作事件本身包括操作者、来源IP、时间、共享名、文件路径这些元数据但它不记录文件内容也不记录读取了文件的哪些字节。所以它适合用来回答谁删了文件谁改了权限不适合用来回答文件内容被改成了什么。内容层面的追溯要配合快照或者备份系统来做。1.3 Full_Audit与Samba自带日志、vfs_audit的取舍Samba自带日志也就是log.smbd、log.nmbd里面的内容主要记录服务运行状态、协议协商、认证结果这类信息。默认日志级别是1只会记录错误和告警。你把log level调到3以上能看到更多连接和请求的细节但粒度完全达不到文件操作审计的级别而且会产生海量日志对排查日常问题来说噪音太大。vfs_audit是Full_Audit之前的旧模块配置方式类似也是通过vfs objects加载但它不支持分别指定成功和失败的事件灵活性和可读性都不如Full_Audit。在Samba的官方文档里新配置推荐直接用full_audit。我自己选Full_Audit的核心原因有三个第一它是Samba源码自带的模块不需要额外安装第二它能把成功事件和失败事件分开配置比如我只关心删除和重命名的成功操作但所有失败操作我都要记录第三它支持自定义输出前缀格式用户名、IP、主机名、共享名都能塞进去日志一出来就能看懂。2. 配置前必须搞清的版本与机制差异2.1 TrueNAS CORE与SCALE的Samba差异TrueNAS现在有两个主流版本线CORE基于FreeBSDSCALE基于Debian Linux。两者在Web界面上看配置项差别不大但底层的Samba实现和文件路径有区别。CORE的Samba由FreeBSD的ports管理VFS模块路径通常是/usr/local/libexec/samba/vfs/配置通过smb.conf加载。SCALE的Samba是Debian包路径在/usr/lib/x86_64-linux-gnu/samba/vfs/同时整个系统的Samba进程是由middleware中间件服务统一管理的。这个差异直接影响你排查问题的思路。在CORE上你可以直接改/etc/smb.conf然后重启服务配置基本上不会被覆盖。但在SCALE上如果你手动改了/etc/smb.conf过不了多久middleware就会把自己生成的配置重新写回去你的修改直接没了。所以SCALE上的正解是走Web界面的辅助参数Auxiliary Parameters入口让系统知道你的意图然后由它来生成最终的配置。2.2 中间件会覆盖smb.conf辅助参数才是正经入口我见过很多人在SCALE上直接SSH进去改smb.conf加vfs objects full_audit改完重启服务当时是生效的。但只要你再改一次共享设置、或者TrueNAS执行配置同步middleware就会把smb.conf重新生成一遍手工加的内容消失得无影无踪。正确的入口有两个全局配置在系统设置 - 服务 - SMB - 编辑里面有一个Auxiliary Parameters框这里填的内容会追加到smb.conf的[global]段。单共享配置在共享 - Windows共享(SMB) - 编辑共享 - 高级选项 - 辅助参数这里填的内容会追加到对应的[共享名]段。这两个入口是TrueNAS官方支持的配置方式middleware在生成配置文件时会把你填的内容合并进去不会丢。这也是为什么我下面的配置步骤全部围绕辅助参数展开而不是教你直接改配置文件。2.3 先确认full_audit模块真实可用在配置之前先用命令确认一下系统里的Samba是否真的带上了full_audit模块。不同版本确认方式略有不同。在SCALE上执行ls -l /usr/lib/x86_64-linux-gnu/samba/vfs/full_audit.so如果文件存在说明模块已经装了。还可以用testparm验证Samba能否正确解析模块参数testparm -v 2/dev/null | grep -i full_audit能输出一堆full_audit:*参数说明模块可用。CORE上把路径换成/usr/local/libexec/samba/vfs/full_audit.so就行。这里要注意一个细节即使模块存在也不代表当前smb.conf里加载了它。VFS模块必须通过vfs objects参数显式加载否则不会生效。这也是新手最容易困惑的地方——模块装了和用了是两回事。还有一个需要提前想清楚的问题你打算做单共享审计还是全共享审计如果几个共享都需要审计直接在全局配置加vfs objects full_audit最省事。如果只有个别共享需要就在那个共享的辅助参数里加。两种方式不要混用否则会出现事件重复记录的问题这个我在第5章详细讲。3. 实操从共享配置到日志产出全流程3.1 单共享开启审计UI里的辅助参数写法以SCALE为例我要给名为design的共享开启Full_Audit审计操作步骤如下进入共享 - Windows共享(SMB)找到design这一行点右侧的编辑按钮。打开高级选项找到辅助参数输入框。填入以下配置vfs objects full_audit full_audit:prefix %u|%I|%m|%S full_audit:success connect, disconnect, mkdir, rmdir, rename, unlink, chmod, chown, ftruncate full_audit:failure connect, open, mkdir, rmdir, rename, unlink, chmod, chown, ftruncate, write, pwrite full_audit:facility local7 full_audit:priority notice点击保存系统会重新生成smb.conf并自动重载Samba服务。这段配置的意思是对成功事件里我关心的主要是连接、目录操作、重命名、删除、权限修改、文件截断这几类失败事件里除了这些还把open和write也纳入了因为连接失败或者写入被拒绝往往跟权限问题相关记录下来有助于排查。3.2 全共享审计全局配置块怎么加如果你要审计所有共享不用一个个在共享里添加直接在全局辅助参数里设置即可进入系统设置 - 服务找到SMB服务点击右侧的编辑按钮铅笔图标。在Auxiliary Parameters里填入同样的配置。保存后重启SMB服务。全局配置的好处是一劳永逸以后新建的共享会自动继承这个VFS配置。但要注意全局配置里的vfs objects会被每个共享继承如果某个共享本身还需要其他VFS模块比如shadow_copy2这个做快照浏览的模块你需要在那个共享的辅助参数里重新指定完整的模块列表类似vfs objects full_audit, shadow_copy2因为Samba处理共享配置时vfs objects是覆盖式设置不是追加式。共享级别写了vfs objects full_audit全局里的shadow_copy2就被顶掉了共享的快照浏览功能就会失效。这个点当时也坑了我一把后面细说。3.3 关键参数逐条拆解full_audit:prefix是让我眼前一亮的一个参数它决定每条日志前面带哪些上下文信息。我常用的占位符%uSamba用户名%I客户端IP地址%m客户端NetBIOS主机名%S共享名%D用户所属域/工作组用|分隔日志看起来就是一行的几个字段后期用awk、cut处理非常方便。full_audit:success和full_audit:failure分别指定需要记录的事件类型。这两个参数的语义要搞明白success表示该操作执行成功后记录failure表示该操作执行失败后记录。比如unlink操作后台执行成功了会触发success记录如果文件被占用删不掉就会触发failure记录。full_audit:facility和full_audit:priority是syslog的设施级别和优先级。默认的facility是local7priority是notice。如果你不做特殊修改Full_Audit的日志会跟着syslog的配置走。在SCALE上默认的syslog配置会把所有日志丢给journald你可以用journalctl查。但为了留存方便我们一般会把local7单独重定向到文件这个放到第4章讲。3.4 验证日志是否真的在写配置保存后不要急着收工先验证一下日志有没有产出。在客户端上做几个操作然后到TrueNAS上看日志。在SCALE上如果还没配置独立的日志文件先执行journalctl -t smbd -f如果日志量太大可以配合grep过滤。然后在Windows客户端上用一个有权限的账号连接design共享、新建一个文件夹、删除一个文件。回到TrueNAS你应该能看到类似这样的记录Mar 12 10:24:33 truenas smbd[3521]: [2025/03/12 10:24:33.152301, 3, pid3521, effective(1000, 1000), real(1000, 0)] /usr/lib/x86_64-linux-gnu/samba/modules/vfs_full_audit.c:578: connect|zhangsan|192.168.31.88|design|smbd Mar 12 10:24:45 truenas smbd[3521]: [2025/03/12 10:24:45.621088, 3, pid3521, effective(1000, 1000), real(1000, 0)] /usr/lib/x86_64-linux-gnu/samba/modules/vfs_full_audit.c:578: unlink|zhangsan|192.168.31.88|design|/design/archive/old_plan.pdf第一行是连接成功的事件第二行是删除文件的事件。按照prefix里定义的顺序第一段是用户名第二段是客户端IP第三段是主机名第四段是共享名最后是具体操作和文件路径。看到这样的输出说明审计已经在正常工作了。4. 日志留存180天的两个落地方案4.1 为什么默认配置存不了180天默认情况下journald对日志容量是有限制的。在TrueNAS SCALE上/var/log/journal的容量上限取决于系统内存大小和SystemMaxUse的设定通常只有几个GB。Full_Audit一旦全量审计一天产生几百MB日志是很正常的journald很快就会开始丢弃旧日志。就算日志进了/var/log/samba/下的文件系统自带的logrotate也不会自动给你保留180天。所以如何留存180天这个问题核心是给审计日志单独设置一套归档清理机制。下面是我实际在用的两种方案。4.2 方案一rsyslog独立目录 logrotate按天归档这个方案适用于SCALE因为SCALE基础系统自带rsyslog和logrotate整个链路比较经典。第一步把local7设施重定向到独立文件。在/etc/rsyslog.d/下新建一个配置文件cat /etc/rsyslog.d/30-samba-audit.conf EOF local7.* /var/log/samba/audit.log EOF重启rsyslog服务systemctl restart rsyslog这里有个注意点rsyslog.conf里通常有一行*.*;auth,authpriv.none -/var/log/syslog这会把所有日志都写进syslog文件。加了这个新配置后local7的内容会被同时写到/var/log/samba/audit.log和/var/log/syslog。为了避免重复可以检查一下rsyslog配置里有没有local7.none的排除项或者直接改行把local7.none加上。第二步配置logrotate按天轮转并保留180份。新建/etc/logrotate.d/samba-audit/var/log/samba/audit.log { daily rotate 180 compress delaycompress missingok notifempty su root adm postrotate /usr/bin/systemctl restart rsyslog /dev/null 21 || true endscript }每天的轮转任务会在凌晨自动执行180份日日志就代表180天。delaycompress的意思是当天的日志先不压缩第二天轮转时再压缩这样如果当天要查日志直接打开原文件就行不用先解压。文件轮转之后必须让rsyslog重新打开新文件这就是postrotate里重启rsyslog的原因。验证配置是否正确logrotate -d /etc/logrotate.d/samba-audit-d是调试模式会打印将要执行的动作不会真正去执行。确认没问题后再手动强制执行一次logrotate -f /etc/logrotate.d/samba-audit4.3 方案二按月份归档的脚本方案如果你不想依赖logrotate也可以用rsyslog的模板功能按月份归档。这个方案我自己在CORE上用过因为FreeBSD的rsyslog环境跟Linux略有差异用脚本反而更可控。在/etc/rsyslog.d/30-samba-audit.conf里改成local7.* action(typeomfile file/var/log/samba/audit-%Y%m.log)然后写一个简单的清理脚本定期删除超过6个月的日志文件。比如用cron每月执行一次find /var/log/samba/ -name audit-*.log -mtime 180 -exec rm {} \;这个方案的好处是日志文件天然按月份拆开比如audit-202503.log就是2025年3月的全部审计日志查起来非常直观。缺点是清理粒度比较粗如果某个月日志量特别大这个文件可能非常大需要注意磁盘空间。4.4 日志怎么查才有意义日志留存是为了查的。我在实战里用最多的几个查询场景按用户查操作记录grep zhangsan /var/log/samba/audit.log | grep unlink按来源IP查grep 192.168.31.88 /var/log/samba/audit.log按共享查删除情况grep |design| /var/log/samba/audit.log | grep unlink统计某个用户的操作次数排行awk -F| {print $2} /var/log/samba/audit.log | sort | uniq -c | sort -rn | head -20如果是压缩过的历史日志先解压到标准输出再管道处理zcat /var/log/samba/audit-*.gz | grep old_plan.pdf这些命令基本就是日常取证的看家本领不用装额外工具系统自带命令就够用。5. 踩坑实录从日志缺失到性能下降5.1 配置写了但日志一条都没有最典型的场景辅助参数里加了vfs objects full_audit保存后客户端实际操作了一通但日志文件里一条记录都没有。排查链路是这样的第一步确认Samba是否真的重新加载了配置。在命令行执行testparm 2/dev/null | grep -A 20 \[design\]看看共享段里有没有你加的那几行。如果没有说明你保存共享的时候可能没点对按钮或者编辑的是共享的基本设置而不是高级选项。注意共享编辑页面里辅助参数默认是折叠起来的必须先展开高级选项才能看到。第二步确认VFS模块加载是否成功。看Samba的日志grep -i vfs /var/log/samba/log.smbd如果模块加载失败这里会有明确报错比如Cant find vfs module。这种情况通常是模块路径不对或者你的Samba版本太老压根没编译这个模块。第三步检查syslog链路。如果你用rsyslog方案先确认local7是否真的被路由到了audit.loglogger -p local7.notice test audit message cat /var/log/samba/audit.log看到测试消息说明rsyslog配置正常问题出在Samba侧看不到问题就在rsyslog侧。5.2 事件重复记录与vfs对象重复加载全局配置里加了vfs objects full_audit某个共享的辅助参数里也加了同一行结果就是在一个操作里日志出现了两条完全相同或者基本相同的记录。原理是Samba的共享配置继承了全局的vfs objects如果共享级又写了一份模块会被加载两次。解决方式很简单全局加了共享就别重复加共享需要额外模块时用逗号把full_audit和其他模块一起列全而不是两个地方分别设置。我给个标准写法假设共享要用快照浏览和审计vfs objects full_audit, shadow_copy25.3 审计写IO把共享拖慢Full_Audit的一个隐藏成本是性能。它的每次审计记录都是同步操作事件触发后要格式化字符串、写入syslog在高频操作下这个开销会被放大。我跟团队实测过一个场景一个共享里开着SAP的接口目录每分钟有几百次文件创建和删除开启全量写操作审计也就是把write、pwrite都放进success列表之后客户端的平均响应时间从20ms涨到了35ms左右。对于网络存储来说这个涨幅已经非常可观了。解决思路是分层审计对普通用户共享只审计破坏性操作unlink、rename、rmdir、chmod、chown和连接事件。对核心业务共享如果需要审查写操作也要把read和write排除在外只保留open、close、ftruncate这类低频事件。如果某些事件必须全量记录但业务对IO敏感可以把审计输出打到独立的物理盘上避免跟数据盘抢IO。说实话我在生产环境里几乎不会在success列表里加write和pwrite除非是安全合规有明确要求。因为一旦加上日志量会呈指数级增长180天留存方案的磁盘开销也会大幅上升。先算一下账一个50人团队平均每人每天产生5000条操作记录其中有80%是写入事件那一天的日志量就要20万条。按每条200字节算一天40MB180天就是7.2GB。如果每个操作都是一整行系统日志加前缀实际量还会翻倍。5.4 审计日志如何帮我定位用户无法登录有段时间我们接到反馈说某个Windows用户在更新密码之后无法访问Samba共享。让人头疼的是Samba的默认日志里只显示认证失败不显示详细原因。我把审计配置里的failure事件配好之后问题一下子清楚了。在/var/log/samba/audit.log里能看到这样的记录Mar 11 22:05:12 truenas smbd[4521]: [2025/03/11 22:05:12.118374, 3, pid4521, effective(1000, 1000), real(1000, 0)] ... connect|zhangsan|192.168.31.88|design|smbd配合log.smbd里的认证错误能定位到是NTLM还是Kerberos认证失败、是密码过期还是账号被锁定。这个信息量比单纯看smbd日志要大得多。所以我的建议是在full_audit的failure事件里无论如何都要加上connect和open这两个基础事件。它们不会产生太大日志量但能帮你解决大量连接和权限问题。5.5 辅助参数被UI覆盖的前因后果还有一个坑必须提醒某些版本的TrueNAS在升级或者导入配置时会校验辅助参数的格式如果格式不满足要求可能会被middleware丢弃甚至在界面上报错。比如full_audit:success connect, disconnect, mkdir这几个参数中间用逗号分隔是正常写法但如果你在TrueNAS的某个配置文件里用分号或中文逗号那就可能引发校验失败。我的经验是辅助参数里只写Samba原生识别的参数不要加注释#开头的行有时会被正确处理但不同版本行为不一致参数值是列表时用英文逗号分隔保存后过几分钟重新打开共享编辑页面确认你填的内容还在然后再用testparm验证一遍最终生成的配置。6. 进阶玩法让审计日志从能查变成好用6.1 定期生成审计统计报告日志留存下来之后如果只是等到出事才去查那价值只发挥了三分之一。更好的做法是定期生成审计统计报告主动发现异常行为。我写过一个简单的脚本每周统计一次高频删除用户频繁失败操作凌晨时段的异常连接然后发到管理员的邮箱。核心思路就是用awk和sort处理audit.log把统计结果格式化输出。一条很实用的命令统计本周删除文件次数前10的用户awk -F| $5unlink {print $2} /var/log/samba/audit.log | sort | uniq -c | sort -rn | head -10如果这些字段的顺序跟你配置的prefix不完全一致记得先看一眼实际日志格式再写awk。把这行命令放进cron里每周跑一次输出重定向到报告文件就形成了一个轻量级的审计报表。6.2 Samba层审计与系统层审计如何配合Full_Audit解决的是通过Samba访问共享这个层面的审计。但如果有人直接SSH到TrueNAS上操作文件或者通过其他服务比如NFS、SFTP读写共享目录Samba层的审计就看不到了。在敏感环境里我建议把Samba的Full_Audit和系统层的auditd配合起来用。TrueNAS SCALE的底层是Debian Linux可以直接启用auditd来监控文件系统级别的操作。这样两个人一个盯Samba协议层一个盯系统调用层覆盖范围才完整。两者的定位不同Full_Audit回答的是哪个用户删了共享里的文件auditd回答的是哪个系统进程删了这个路径。前者对业务管理员友好后者对安全审计友好。配合使用时要注意日志量会叠加存储规划要提前考虑。6.3 快照、告警和取证的闭环审计日志的价值不只是事后追溯更在于它能跟快照机制形成闭环。我现在的做法是TrueNAS的存储池开启定时快照Samba开启Full_Audit审计再配一个简单的日志监控脚本一旦出现批量删除或权限变更事件立即触发告警。这样一来告警能让我在几分钟内发现异常快照能让我回滚数据审计日志能让我定位操作人。三件事配合起来一个防误删、防篡改、可追溯的文件服务体系就成型了。具体的告警脚本也不复杂核心逻辑就是实时tail审计日志用正则匹配关键事件命中后调用Webhook发消息到企业微信或者钉钉。比如匹配某个用户在短时间内删除超过50个文件这通常是误删或者恶意操作的信号。我在这套方案跑通之后又加了一个细节把审计日志的哈希值定期固化到另一个存储位置。这个做法能防止日志本身被篡改——如果哪天需要把审计结果作为证据提交这一步会让它的可信度高很多。具体做法是每天凌晨计算前一天日志文件的SHA256存到一个只有管理员能访问的目录里。6.4 性能优化思路大日志量场景下的降级策略如果你确实需要全量审计日志量会非常可观。这种情况下我建议按以下顺序做优化第一事件分离。把连接和文件操作分开配置到不同的锁存级别。比如连接事件用notice级别文件操作事件用info级别这样在查询时可以按优先级过滤。第二日志采样。对于高频但低风险的事件比如read可以在prefix里加上%t当前时间来判断是否属于业务高峰但这需要更复杂的处理流程。更简单的做法是不在success列表里记录read和write只记录低频但关键的操作。第三独立存储。审计日志所在的分区最好跟数据分区分开。如果条件允许挂一块SATA SSD专门放日志既避免日志增长撑爆系统盘也减少对业务IO的影响。我这套配置在TrueNAS SCALE上跑了大半年日志从一天几百MB降到了每天不到100MB同时审计的覆盖范围没有缩水只砍掉了真正影响性能的read/write事件。对于绝大多数文件共享场景来说这个粒度已经足够看清谁做了什么操作了。而且半年下来凡是遇到过删除事故的团队没有一个觉得这个配置是多余的。