在这个最小示例中，网络中有三台机器。一台 Windows 服务器充当域（包含所有相关内容）、一台 Synology NAS（用于存储一些数据和备份）以及一台需要访问同一台 NAS 的 Linux 主机。
由于我不想弄乱或维护 NAS 上的一组单独的权限，因此 Linux 主机应该使用与 Windows 主机相同的访问机制；为此，我将共享安装为 CIFS 并从 Windows 服务器请求 Kerberos 票证。这个功能；并且份额不断增加。
但后来我遇到了一些只能被描述为搞什么？。
假设域有两个用户 wuB 和 wuV。用户 wuV 已在 Synology 共享上创建了一个文件夹。我现在想以（Windows 域）用户 wuB 的身份从 Linux 主机访问此文件。
我在 Linux 机器上运行以下命令：
$ kinit [email protected]
$ mount --verbose -t cifs -o sec=krb5i,vers=2.0,username=root,uid=0000,gid=0000,iocharset=utf8,dir_mode=0777,file_mode=0777,noperm //mysynology.company.com/backup /var/backups/synology1
mount.cifs kernel mount options (...)
$ cd /var/backups/synology1/
$ ls
existing_dir_owned_by_wuV
$ mkdir testdir
$ cd testdir
$ touch testfile
$ echo "yessir" > testfile
$ cat testfile
yessir
$ ls -lha
drwxrwxrwx 2 root root 0 Sep 20 12:28 .
drwxrwxrwx 2 root root 0 Sep 20 12:28 ..
-rwxrwxrwx 1 root root 6 Sep 20 12:28 testfile
$ cd ..
$ cd existing_dir_owned_by_wuV
$ ls -la
'.' : permission denied
$ cat existing_file_in_subfolder
permission denied
$ cd ..
$ cat existing_file_in_mainfolder
hello world
检查 Synology 上的所有权：test 文件夹被标记为company.com/wuB 所有，现有文件夹被标记为company.com/wuV 所有。这意味着，是的，我正在以 Windows 用户 wuB 的身份访问共享。
在 Synology 上，Windows/NTFS 样式权限仅在共享本身上设置；子文件夹/文件继承仅权限。 wuV 和 wuB 都被标记为具有读写访问共享中的所有文件。安装时，linux权限设置为777。我正在执行所有操作根在 Linux 机器上，因此权限问题也不是源自那里。
这怎么可能？
我该如何解决这个问题？
答案1
对于有类似问题的人；我找到了答案：
Synology 对 NTFS 权限的显示本质上是：错误的。它以某种方式缓存它们，并显示它自己的现实版本，这与 SMB/CIFS 存储内容的方式并不完全匹配。我通过以同一用户身份从 Windows 计算机安装文件夹发现了这一点。我无法访问某些现有目录。
事实证明，跟踪遗产是越野车。 NTFS权限比较复杂，每个文件夹都有自己的权限继承旗帜。如果其中任何一项被关闭，则共享上的权限将不适用。事实证明，一个有缺陷的程序正在创建它所写入的一些文件夹/文件，而不尊重管理员的继承设置。 （但管理员无论如何都没有能力更改这些权限）。为什么这是可能的，这是 Windows 委员会的设计缺陷之一。
解决方案是在每个有问题的文件夹上打开继承（并对所有文件和子文件夹执行此操作）。可以使用 cacls 自动化，或在同一资源管理器窗口中完成。
在查看这个答案时，我还发现了ntfssecaudit一种在没有可用 Windows 机器的情况下从 Linux 主机执行相同操作的方法。如果连接的用户有权查看这些内容，它也会将继承报告为关闭；但这可以通过使用 kerberos 票证重新安装来简单解决administrator。