这个问题我之前帮不少开发者排查过，核心是你设置的权限没有被系统“持久化”，或者被某些自动机制覆盖了。下面是几个你可能遗漏的关键操作，按优先级试试：

• 检查权限的继承性与应用范围
  右键Windows/Temp文件夹 → 属性 → 安全 → 高级，确保你添加的Network Service和IIS_IUSRS权限是应用到「这个文件夹、子文件夹和文件」，而不是仅当前文件夹。同时勾选「替换所有子对象权限项」后点击应用——这一步能避免子文件夹权限没同步，很多时候重启后出问题就是子项权限没跟上。另外别忘了检查权限条目里有没有针对这些账户的「拒绝」权限，拒绝会直接覆盖允许，哪怕你给了完全控制。

• 确认应用池的实际运行身份
  有时候你给了Network Service权限，但你的应用池实际用的是其他身份（比如默认的ApplicationPoolIdentity）。打开IIS管理器 → 找到你的应用对应的应用池 → 高级设置 → 进程模型 → 身份。如果是ApplicationPoolIdentity，你需要给IIS AppPool\[你的应用池名称]这个专属虚拟账户授予Windows/Temp的完全控制权限，而不是仅依赖IIS_IUSRS组——因为每个应用池的ApplicationPoolIdentity是独立的，IIS_IUSRS组不一定包含它。

• 排查组策略是否重置权限
  Windows的本地组策略可能会在重启时自动重置Temp文件夹的权限。按下Win+R输入gpedit.msc打开本地组策略编辑器，依次展开「计算机配置 → Windows设置 → 安全设置 → 文件系统」，看看有没有针对C:\Windows\Temp的策略。如果有，双击它把Network Service和相关IIS账户加进去，设置完全控制后应用策略；如果这个策略是强制重置权限的，你需要修改它的配置，确保你的自定义权限不会被覆盖。

• 修正Temp文件夹的所有者
  如果Temp文件夹的所有者不是Administrators组，重启后系统可能会自动调整权限。右键Temp → 属性 → 安全 → 高级 → 所有者 → 编辑，选择Administrators组，勾选「替换子容器和对象的所有者」后点击应用。之后再重新设置一次权限，这样权限的稳定性会高很多。

• 改用自定义临时目录（终极方案）
  要是不想跟系统Temp文件夹较劲，你可以直接让.NET应用使用自定义的临时目录。在应用的web.config里添加这段配置：

  <system.web>
    <compilation tempDirectory="D:\YourCustomTempFolder" />
  </system.web>
  

  然后给这个你自己创建的文件夹授予应用池运行身份的完全控制权限——这个文件夹是你自己管理的，系统不会轻易重置它的权限。

内容的提问来源于stack exchange，提问作者Moloy Adhikary