Samba4添加Synology NAS域额外域控报schema_data_modify错误

schema_data_modify: we are not master: reject modify request报错的本质是本地数据库校验发现当前节点不持有Schema Master（架构操作主机）FSMO角色，拒绝写入schema修改，触发场景基本集中在3类：

• 你在新DC的join命令里错误加了--option="dsdb:schema update allowed = yes"参数：这个配置项的作用是允许持有Schema Master角色的现有主域控执行schema更新，待加入的新DC在加入完成前根本不持有任何FSMO角色，加这个参数会让本地数据库提前触发schema写入权限校验，直接拦截复制过来的schema数据。
• 现有主域控（你日志里的nas.home.intern）没有开启schema更新允许，或者FSMO角色状态异常：主DC作为Schema Master如果没开schema更新权限，DRS复制传递schema数据时的权限校验会失败，返回错误给新DC。
• 基础环境异常：新DC和主DC时间差超过Kerberos允许的5分钟阈值、新DC的DNS没指向主DC导致解析错误、加入操作使用的账号没有Schema Admins组权限，都会导致复制过程中权限校验失败，触发同类报错。日志里的Unable to determine the DomainSID提示就是本地数据库提前校验、还没拿到域核心信息时抛出的连带提示，不是根因。

• 第一步：删掉join命令里多余的--option="dsdb:schema update allowed = yes"参数，额外域控加入不需要加这个配置，基础命令格式参考：

  sudo samba-tool domain join home.intern DC -Uadministrator
  

  执行时输入域管理员密码即可。
• 第二步：登录现有主域控nas.home.intern做前置检查和配置：
  1. 执行samba-tool fsmo show，确认Schema Master、Domain Naming Master、PDC、RID Master、Infrastructure Master五个核心FSMO角色都正常由主DC持有，没有角色丢失或指向不存在节点的问题。
  2. 临时在主DC上开启schema更新权限：编辑主DC的smb.conf，在[global]段添加dsdb:schema update allowed = yes，重启smbd、samba服务，等新DC加入完成后把这行配置删掉重启服务即可，不需要长期开着。
  3. 执行samba-tool dbcheck --fix修复主DC本地AD数据库的不一致错误，避免复制时传输出错。
• 第三步：检查两台节点的基础网络和配置一致性：
  • 新DC的首选DNS必须填主DC的内网IP，不能配置公共DNS或者路由器DNS，确保域内域名、SRV记录解析正常。
  • 两台节点的系统时间差控制在1分钟以内，统一配置内网时间源同步，避免Kerberos认证因为时间偏差失败。
  • 新DC上提前做解析测试：ping nas.home.intern、host _ldap._tcp.home.intern，确认返回的是主DC的正确内网IP，没有解析错误。
• 第四步：确认执行加入操作的账号权限：账号必须同时属于Domain Admins、Schema Admins、Enterprise Admins三个组，不要用普通域用户或者权限不全的自定义管理员账号操作。
• 第五步：清理新DC上之前加入失败的残留数据再重试：

  sudo systemctl stop samba smbd nmbd winbind
  sudo rm -rf /var/lib/samba/* /var/cache/samba/* /etc/samba/smb.conf
  

  清理完成后重启相关服务，再重新执行join命令。
• 第六步：如果用的是群晖自带的定制版Samba，以上操作都无效的话，先把两台节点的Samba版本升级到一致的大版本，避免群晖定制修改导致的DRS复制兼容问题。

内容的提问来源于stack exchange，提问作者Talkabout