“iis应用程序池身份无目标路径权限”是“访问路径被拒绝”的主因，需为iis apppoolyourapppoolname显式授予目标文件夹读写权限，禁用everyone或administrators等宽泛授权，遵循最小权限原则。

部署后报“访问路径被拒绝”，不是代码写错了，而是 IIS 应用程序池身份压根没权限碰那个文件夹。

检查应用程序池身份是否对目标路径有读写权限

默认的 ApplicationPoolIdentity 是一个隔离账户，它在文件系统上没有显式权限，连自己的临时目录都可能进不去。不能指望它自动拥有你项目里任意路径（比如上传目录、日志目录、共享路径）的访问权。

• 在 IIS 管理器中右键你的应用程序池 → “高级设置” → 查看 Identity 值（常见为 ApplicationPoolIdentity 或自定义用户）
• 打开目标文件夹（如 D:MyAppUploads 或 \servershare）→ 右键“属性” → “安全”选项卡 → “编辑” → “添加”
• 输入框里直接输 IIS AppPoolYourAppPoolName（注意格式：IIS AppPool 开头，后面跟你在 IIS 里看到的**确切池名**），点“检查名称”确认，再勾选 读取 和 写入（上传/日志场景必须）
• 如果是网络共享路径，还要额外确认该账户在共享服务器上也有对应 NTFS 权限和共享权限

为什么给 Everyone 或 Administrators 权限不是好办法

临时加 Everyone 全控确实能过，但这是把门敞开——任何能登录服务器的本地账户都能删你上传文件、篡改配置。IIS 官方明确不建议这种做法，尤其在生产环境。

C#

"避开 C# 常见错误——空陷阱、异步陷阱、LINQ 陷阱及资源泄漏。"

下载

• Administrators 组权限过大，且一旦应用池用的是 ApplicationPoolIdentity，它根本不在这个组里，加了也无效
• 真正该授权的是具体的应用池标识，例如 IIS AppPoolDefaultAppPool，最小权限原则
• 若需跨机器访问共享（如 \fileserverdata），必须在共享端用相同用户名（或映射为域账户）显式授权，仅本机设权限没用

遇到 Temporary ASP.NET Files 拒绝访问怎么办

这类错误多见于 .NET Framework 项目，提示路径类似 C:WindowsMicrosoft.NETFramework644.0.30319Temporary ASP.NET Files...，本质还是权限缺失，但位置特殊，不能随便加 Everyone。

• 先确认该目录真实存在；若不存在，不要手动创建——它是 .NET 运行时自动建的，说明运行时没跑起来
• 正确做法：给 IIS AppPoolYourAppPoolName 添加对该父级目录（如 C:WindowsMicrosoft.NETFramework644.0.30319）的 读取 & 执行、列出文件夹内容、读取 权限即可，无需写入
• 如果用了自定义应用程序池身份（比如 DOMAINUser），则必须确保该用户对 Temporary ASP.NET Files 所在驱动器的根目录（如 C:）至少有 读取 & 执行 权限，否则连目录遍历都会失败

部署后突然报路径拒绝，但之前好好的

常见于服务重启、IIS 配置变更或 Windows 补丁更新后。不是代码变了，是权限继承链断了。

• 检查目标文件夹是否被移动、重命名或从另一磁盘复制过来——复制会丢失原有 ACL，必须重新授权
• 确认应用程序池是否被改成其他身份（比如从 ApplicationPoolIdentity 改成 LocalSystem），权限要跟着重配
• 某些杀毒软件或组策略会定期重置 NTFS 权限，可临时禁用策略测试，再通过 PowerShell 脚本固化权限（如用 icacls）
• 日志里若出现 HRESULT: 0x80070005，基本锁定为 COM/DCOM 权限问题（如调用 SolidWorks、Excel 等），需单独进 dcomcnfg 配置，不是简单加文件夹权限能解决的

权限不是一次配完就一劳永逸的事，尤其是涉及临时目录、共享路径、COM 组件的场景，每次部署或系统更新后都得按实际身份核对一遍——漏掉一个斜杠、拼错一个池名，就会卡在“拒绝访问”上不动。