某些网站上的某些用户有时会出现 MOSS 404 错误
对于大多数帐户来说，100% 的情况下一切都工作正常，但有时有些用户有一天能够正常访问子网站，第二天就会收到标准的 404 错误。这可能会持续一个小时或两天，这真的很不一致。
我检查了 iis 日志，它说这些请求的状态也是 404，没有其他看起来异常的情况。 Sharepoint 日志也没有任何时间戳。
如果我错了，请纠正我，但如果是权限问题，则会显示访问被拒绝的消息。
这不是单独的计算机，因为当用户遇到此问题并且我可以使用他们的帐户登录时，我也会收到 404 错误，尽管我在同一时间在另一个浏览器中使用另一个帐户访问同一网站，并且它工作完美。
任何建议将不胜感激，我已经进行了大量搜索，但找不到类似的情况或在任何地方提供帮助。
Everything works fine for most accounts 100% of the time but here and there some users who are able to access a subsite fine one day are greeted with a standard 404 the next. This can last for an hour or two days, it's really inconsistent.
I check the iis logs and it says the status is also a 404 for these requests, nothing else looks unusual. Sharepoint logs have nothing for the timestamps either.
Correct me if I am wrong but if it was a permission issue an access denied message would be shown.
It is not the individual computer because when a user is having this problem and I can log in with their account and I also get the 404 error although I am on the exact site with another account in another browser at exactly the same time, and it works perfect.
Any suggestions would be greatly appreciated, I've done a fair amount of searching but can not find a similar situation or help anywhere.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
由于目前的信息非常严格，我将提出一些可能引导您解决问题的问题。
可能经常发生的情况是，例如，当您在 GAC 或 bin 文件夹上自定义了 DLL 代码时，并且由于您可能处于负载平衡状态，所以第二个服务器中没有此 DLL其自己的 GAC 或 BIN 文件夹。当未找到程序集（而不仅仅是请求）时，Sharepoint 通常也会引发 404。
Since the information is very strict at the moment, I will throw a few questions that might lead you towards the problem.
Something that might occur very often is when you have, say, custom code a DLL on the GAC or the bin folder, and since you could be on loading balance the second server does not have this DLL in its own GAC or BIN folder. Sharepoint usually raises 404s when assemblies are not found too, not only requests.
这似乎不太可能，但是...那些 SharePoint 网站会抛出 404 HttpException 吗？您似乎也会在 SharePoint 日志中看到这一点，因此这种情况更不可能。
无论如何，您的 SharePoint 日志记录级别是否设置为适当的详细级别来调试此类奇怪的内容？
This seems like a longshot, but... could those SharePoint sites be throwing a 404 HttpException? It seems like you'd see that in the SharePoint logs, too, so it's even more unlikely.
At any rate, is your SharePoint logging level set to an appropriately verbose level to debug weird stuff like this?
人们是否正在办理入住手续？当新的 CSS 文件和/或其他包含文件（脚本文件等）尚未发布时发布母版页更改？我曾多次看到用户在发布前忘记检查时会导致 404 错误。
Are people checking in & publishing master page changes when new CSS files and/or other includes (script files, etc.) are not yet published at all? I've seen this cause a 404 a few times when users forget to check before they publish.
我必须在 SharePoint 上下文中编写自定义代码，并且也遇到了 404 错误。就我而言，解决方案是确保执行的代码块满足这两个条件：
1）以提升的权限运行，无论它是 404，这是解决方案的一部分。
2) web.AllowUnsafeUpdates = true;即使这行代码被包装在提升的权限块中，也需要添加它。
添加这些后，问题就没有发生。这种情况在负载和非负载平衡环境中都会发生。
I have had to write custom code within a SharePoint context and I had those 404 errors as well. The solution, in my case, was to ensure that the block of code executing had these 2 conditions met:
1) Run with elevated privileges, regardless of the fact that it is a 404 this was part of the solution.
2) web.AllowUnsafeUpdates = true; This line of code needed to be added even though it was wrapped within an elevated privileges block.
Once these were added the issue did not occur. This was happening on both load and non-load balanced environments.
这让我想起了几个月前遇到的一个奇怪的 asp.net bug。
这是由已应用的补丁引起的（如果我没记错的话，应用于框架）
尝试下载此 Windows 更新列表工具并查看自问题出现以来发生了哪些变化。
我承认，如果补丁存在问题，那么它更有可能是一个一致的错误，但值得一看。
This reminds me of a strange asp.net bug that I had a few months back.
It was caused by a patch that had been applied (to the framework if I remember correctly)
try downloading this Windows update list tool and have a look at what has changed since the problem started.
I concede that if there was a problem with a patch then its more likely that it would be a consistent error, but it's worth a look.
这是一个权限问题，我不久前就发现了这一点，但基本上有一些帐户没有正确设置，无法加载页面的新副本，当其他人点击它时，他们将能够正常查看缓存的页面。错误从未因权限问题或访问被拒绝而在任何地方抛出，但这就是解决问题的原因。
It was a permission issue, I had figured this out awhile back but basically a few accounts were not setup properly and could not load a fresh copy of the page, when someone else would hit it they would be able to view the cached page fine. Error was never thrown as a permission issue or access denied anywhere but this is what fixed the problem.