smb共享不丢失创建者权限，问题根源在于ntfs权限未启用继承或缺失creator owner条目：需启用继承、添加creator owner并赋予权限，确保客户端复制时保留安全描述符。
这个问题核心在于：smb共享本身不传递“创建者”这一身份语义，windows server上所谓“丢失创建者权限”，其实是对ntfs权限继承机制和smb协议行为的误解。真正的故障点不在smb传输过程，而在于目标共享文件夹的ntfs权限配置是否启用“替换所有子对象权限项”及“继承权限”的实际状态。
确认“创建者”在NTFS中的真实含义
“创建者”不是某个具体用户账户，而是NTFS中一个特殊标识符（CREATOR OWNER）。它只在权限继承链中起作用——当新文件被创建时，系统会把该文件的拥有者自动设为当前操作用户，并把“CREATOR OWNER”对应的权限规则应用到该文件上。但这个机制生效的前提是：目标文件夹必须开启权限继承，且未勾选“阻止继承”。如果共享文件夹的NTFS权限里手动清空了继承、又没显式添加CREATOR OWNER条目，那任何用户复制进来的文件都不会体现“创建者专属权限”。
检查共享文件夹的NTFS权限继承设置
在共享服务器上，右键目标文件夹→“属性”→“安全”→“高级”：
- 确认“启用继承”已勾选；若显示“已禁用继承”，点击“启用继承”并选择“将继承的权限项添加到此对象和所有子对象”
- 在权限条目列表中查找是否存在“CREATOR OWNER”，权限应包含“完全控制”或至少“修改+读取和执行”
- 如果没有CREATOR OWNER条目，点击“添加”→“选择主体”，输入CREATOR OWNER→赋予对应权限→勾选“仅将这些权限应用于此容器中的对象和/或容器”
验证SMB共享是否启用“强制所有权”类策略
某些组策略或第三方存储软件会覆盖默认行为：
- 运行gpedit.msc，依次展开：计算机配置→管理模板→网络→Lanman工作站，检查“启用不安全的来宾登录”是否启用（虽不直接相关，但影响认证上下文）
- 重点检查：计算机配置→Windows设置→安全设置→本地策略→安全选项→“网络安全: LAN Manager 身份验证级别”，若设为“仅NTLMv2响应”，可能影响旧客户端的身份传递完整性
- 在注册表中确认HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters下无DisableLastAccess以外的干扰项（如Smb2CreditsMin等非标准键值）
排除客户端侧的复制工具干扰
使用资源管理器拖放、robocopy、xcopy行为不同：
- 资源管理器复制（含Ctrl+C/V）默认保留源文件的拥有者和权限，但仅当目标支持且继承开启时才生效
- robocopy /copyall /sec 会尝试复制完整安全描述符，但若目标NTFS未启用继承，仍无法触发CREATOR OWNER逻辑
- PowerShell Copy-Item -Recurse 默认不复制ACL，必须加 -PreserveAll 参数（仅Windows Server 2019+支持）
本质上，这不是SMB协议缺陷，而是NTFS权限模型与共享操作方式的匹配问题。只要目标文件夹继承开启、CREATOR OWNER存在、且客户端未强制剥离安全信息，新创建的文件就会自动归属操作者并应用其对应权限。
