我有一个使用简单文件共享的 XP Pro 系统。为特定文件夹启用共享，以及“允许网络用户更改我的文件”。
从另一台机器复制（读取）共享文件时，其中一些（大约 1000 个中的 20 个）给出访问被拒绝错误。没有程序打开文件。
我必须去共享文件的机器并运行
CACLS C:\MySharedFolder\*.* /T /e /g Everyone:c
这解决了问题，并且可以访问所有文件。但是必须运行该命令很不方便。几天或几周后，错误又回来了。
这个错误的根本原因是什么？似乎访问文件的程序（在本例中为 Eudora）错误地设置了权限 - 但为什么只在这台机器上？我有其他机器具有相同的共享文件夹配置，从来没有这个问题。
通常，这可能是由于用户将文件剪切并粘贴到共享中造成的。这意味着如果文件（在源）被设置为不从父文件夹继承权限，当它们被剪切并粘贴到目标时，它们会保留旧的权限。
这不是真正的答案，而是更多信息（由于字符限制，无法使用评论）。我仍在努力理解和解决这个问题。
以下是 CACLS 中“坏”文件的权限（权限阻止从另一台机器复制）：
这是一个“好”文件的样子：
“邮件”（父）文件夹的权限如下所示：
“Everyone:C”和“BUILTIN\Administrators:F”属性不知何故从问题文件中删除。不同的文件在不同的时间受到影响。似乎没有任何一致性。
这不是一个解决方案，而是一些可以比较笔记的东西......
我有几乎完全相同的问题。但是，就我而言，我有一个用户 ID 登录到充当 PDC 的 Samba-3 服务器（所以我有机器加入了域）。
此用户 ID 可以从 WinXP 框中访问文件，但在 Win7-PRO 机器上，他们会收到拒绝访问错误。该文件没有从一个共享移动到另一个共享或从一个文件夹移动到另一个文件夹。它只是一个公用文件夹，公司中的每个人都可以访问。
我尽一切努力解决问题，我发现的唯一一件事就是用干净的 Windows-7 副本重新部署工作站解决了这个问题。
就我而言，Windows7 与 SAMBA 的交互似乎是个问题。有趣的是，我还有其他 Win7 机器，但其他用户没有出现问题，但这个特定的特定用户 ID 仅在 Win7 机器上出现问题。
我什至删除了用户 ID 并重新创建了它，但清除他们的漫游配置文件并没有解决问题。我还发现，如果我告诉用户使用与旧用户 ID 不匹配的新创建的用户 ID，问题仍然存在。
如果这台 Windows-7 工作站导致问题与用户 ID 一起出现，则在它使用该用户 ID 传送到其他 Win-7 工作站之后。
重新安装一个 Win-7 工作站可以解决问题。