我遇到了一个非常令人沮丧的问题，NTFS 权限继承无法正常工作。
我使用云存储（特别是 OneDrive）来存储某些文件；在这种情况下，我的笔记本电脑上有一个客户端，并且也希望能够访问桌面上的文件。
在笔记本电脑上，客户端通常位于计算机上，但我不会在桌面上运行客户端，因为云存储客户端占用大量 RAM 和 CPU，我不希望在我的工作站上运行它。相反，我在服务器上有一个 VM（位于工作站旁边），它为云存储客户端和一些其他文件共享运行虚拟机。然后使用 SMB 将云存储文件夹映射到工作站，就像任何其他文件共享一样。VM 全天候运行，而我有时会让桌面处于休眠状态，例如整夜。
我以前在 Windows 7 上这样做过，效果很好。我最近才将该 VM“升级”到 Windows 10，因为微软下个月将停止对 Windows 7 的 OneDrive 支持，从而强制淘汰该功能。否则，我会回到那个已知的工作设置。
我现在遇到的问题是，当我在此设置之外创建新文件时（例如在笔记本电脑上或在线），这些文件会同步到虚拟机，但当我尝试从桌面访问它们时，会显示“访问被拒绝”。 （桌面运行的是 Windows 7，但问题不在桌面上，而是在虚拟机上）。
设置方式是在虚拟机上配置一个非交互式用户，该用户对所有相关文件夹具有完全控制 SMB 和 NTFS 权限，用于桌面上的驱动器映射。NTFS 权限设置为继承。
但是，当虚拟机上出现不是它创建的新文件时，权限不会继承。它只是设置为允许 SYSTEM、admin 和 Administrators 完全控制。
上周，为了尝试修复此问题，除了将标准用户添加为完全控制权限外，我还将“用户”添加为完全控制权限，以防其中一个权限失败。
但这并不起作用；两个都这些权限无法继承，并且由于我没有以管理员身份映射驱动器，因此出现“拒绝访问”的情况。
除了让用于映射的标准用户实际拥有 OneDrive 目录的所有权（由于以admin该用户身份运行，因此该目录归该用户所有）之外，还有其他方法可以修复此权限问题吗？我已经多次进入顶级目录并重新应用 NTFS 权限来添加其他用户，当然，它会修复最近添加的文件，但仍然无法应用于未来的文件。似乎这里出了什么严重问题。
本质上，每当发生这种情况时，我都需要通过 RDP 进入虚拟机并手动修复新文件的权限。这是完全站不住脚的。
我能想到的唯一区别是在旧虚拟机上，OneDrive 的路径是C:\OneDrive，而现在是默认的C:\Users\admin\OneDrive。但权限已正确设置，因此它应该可以工作。
VM 不会执行任何其他操作，因此作为最后的手段，我只需为所有人设置 NTFS 权限即可，因为 SMB 权限没有任何问题，但似乎没有必要这样做。有什么建议可以解决这个问题吗？
我应该补充一点，我不想与其他用户一起“取得”目录的所有权的主要原因是，问题很可能反过来发生，即由于某种原因，admin该文件夹的继承权限可能会中断，然后admin不允许对其自己的 OneDrive 目录进行完全控制访问。我需要一种万无一失的方法来确保两个用户都拥有完全控制权。
其他观察：
这似乎可能是 OneDrive 和/或 Windows 10 的一些错误。
OneDrive将文件夹移动C:\OneDrive到C:\Users\admin\OneDrive（并重新应用 NTFS 权限并重新创建共享）不是解决问题。- Dropbox 没有这个问题。
- 同样的安排在 Windows 7 上运行良好，没有任何问题。
我认为这以前行不通，但如果我在笔记本电脑上创建文本文件并尝试在桌面上访问它们，那似乎有效。但是，PDF 从来不会出现同样的情况；我总是收到“拒绝访问”的提示。
这仅有的有效的方法是，您猜对了：以管理员身份映射共享，并将adminVM 添加到 SMB 权限。
我对这种安排并不十分满意，但无论如何我都是这些机器的唯一用户，因此安全性无论如何都不是问题，所以目前它只能算是一种草率的解决方法。（但最初的问题仍然存在：以非运行虚拟机上程序的用户身份访问文件时不兼容）。