.net - 无法批量加载，因为无法打开文件 “"。操作系统错误代码5(访问被拒绝。)

Question

好的。我确实看到已经有人提出了很多类似的问题。从表面上看，我似乎不应该问这个问题，因为很多人已经尝试回答这个问题，但我会解释我的情况是不同的:

首先我的设置:

负载均衡器后面有两台服务器

服务器A:作为域Service_account运行Windows服务服务器B:作为域service_account运行Windows服务

然后这个 Windows 服务最终调用 SQL Server 来执行存储过程，该存储过程当然会尝试从位于\network\location 上的文件进行批量插入。现在，我不知道他的信息有多重要，但这个网络位置实际上是在服务器 B 上作为网络共享共享的文件夹，所以基本上\network\location = Server B: C/something。

现在，我已将每个人添加为该文件夹的用户，并将其设置为完全控制，以确保尝试访问该文件夹的任何人都不会出现权限问题。

现在，我确实收到此错误:无法批量加载，因为无法打开文件“”。操作系统错误代码 5(访问被拒绝。)。

只是有时。这里的整个问题是错误不能始终如一地重现。它每周只发生一次。我尝试绕过负载均衡器并直接从服务器发出请求，但没有发现任何问题。另外，我还观察到在此失败请求之前和之后发出的请求均成功。这意味着这是真正意义上的偶发错误。

浏览 SO 后，我发现传统上导致此错误的两个主要原因是:

1. 当运行该服务的用户确实无权访问此文件夹时。事实并非如此，因为实际上每个人都可以访问该文件夹。

2. 我遇到了一些帖子，人们指出潜在的 Kerberos Double Hop 是一个潜在问题。正如这里所解释的:https://learn.microsoft.com/en-us/previous-versions/msp-n-p/ff649317(v=pandp.10)?redirectedfrom=MSDN

这可能是 Kerberos，我正在进一步挖掘以查看是否存在问题。但与此同时，假设 Kerberos 双跳 是罪魁祸首，那么如何解释此错误的偶发性呢？如果 kerberos 正在删除凭据，那么不是会一直删除它，而不是仅选择几次？

或者，如果这两个都不是此错误背后的真正原因。真正的问题不是错误本身，而是错误的零星性质。是否是网络中的某些问题导致连接中断？

Answer 1

确保 SQL Server 可以看到该共享。我发现测试这一点的一个好方法是使用 xp_cmdshell 在共享上执行 DIR。例如

exec sp_configure 'show advanced' , 1
RECONFIGURE
exec sp_configure 'xp_cmdshell' , 1
RECONFIGURE
exec xp_cmdshell 'dir \\host.domain.local\sharename'

如果是零星的，可能是因为 DNS/网络名称解析有问题？确保您使用 FQDN。如果它与 Kerberos 相关，那么您可以使用托管共享的服务器的 IP 地址来排除问题，即 exec xp_cmdshell 'dir\\10.10.10.x\sharename' 当您使用IP，身份验证必须回退到 NTLM。根据服务器的安全设置，您可能需要更改一些 GPO 才能使其正常工作。