“IIS应用程序池身份无目标路径权限”是“访问路径被拒绝”的主因，需为IIS AppPoolYourAppPoolName显式授予目标文件夹读写权限，禁用Everyone或Administrators等宽泛授权，遵循最小权限原则。
部署后报“访问路径被拒绝”，不是代码写错了，而是 IIS 应用程序池身份压根没权限碰那个文件夹。
检查应用程序池身份是否对目标路径有读写权限
默认的 ApplicationPoolIdentity 是一个隔离账户，它在文件系统上没有显式权限，连自己的临时目录都可能进不去。不能指望它自动拥有你项目里任意路径（比如上传目录、日志目录、共享路径）的访问权。
- 在 IIS 管理器中右键你的应用程序池 → “高级设置” → 查看
Identity值（常见为ApplicationPoolIdentity或自定义用户） - 打开目标文件夹（如
D:MyAppUploads或\servershare）→ 右键“属性” → “安全”选项卡 → “编辑” → “添加” - 输入框里直接输
IIS AppPoolYourAppPoolName（注意格式：IIS AppPool开头，后面跟你在 IIS 里看到的**确切池名**），点“检查名称”确认，再勾选读取和写入（上传/日志场景必须） - 如果是网络共享路径，还要额外确认该账户在共享服务器上也有对应 NTFS 权限和共享权限
为什么给 Everyone 或 Administrators 权限不是好办法
临时加 Everyone 全控确实能过，但这是把门敞开——任何能登录服务器的本地账户都能删你上传文件、篡改配置。IIS 官方明确不建议这种做法，尤其在生产环境。
-
Administrators组权限过大，且一旦应用池用的是ApplicationPoolIdentity，它根本不在这个组里，加了也无效 - 真正该授权的是具体的应用池标识，例如
IIS AppPoolDefaultAppPool，最小权限原则 - 若需跨机器访问共享（如
\fileserverdata），必须在共享端用相同用户名（或映射为域账户）显式授权，仅本机设权限没用
遇到 Temporary ASP.NET Files 拒绝访问怎么办
这类错误多见于 .NET Framework 项目，提示路径类似 C:WindowsMicrosoft.NETFramework64 4.0.30319Temporary ASP.NET Files...，本质还是权限缺失，但位置特殊，不能随便加 Everyone。
- 先确认该目录真实存在；若不存在，不要手动创建——它是 .NET 运行时自动建的，说明运行时没跑起来
- 正确做法：给
IIS AppPoolYourAppPoolName添加对该父级目录（如C:WindowsMicrosoft.NETFramework64 4.0.30319）的读取 & 执行、列出文件夹内容、读取权限即可，无需写入 - 如果用了自定义应用程序池身份（比如
DOMAINUser），则必须确保该用户对Temporary ASP.NET Files所在驱动器的根目录（如C:）至少有读取 & 执行权限，否则连目录遍历都会失败
部署后突然报路径拒绝，但之前好好的
常见于服务重启、IIS 配置变更或 Windows 补丁更新后。不是代码变了，是权限继承链断了。
- 检查目标文件夹是否被移动、重命名或从另一磁盘复制过来——复制会丢失原有 ACL，必须重新授权
- 确认应用程序池是否被改成其他身份（比如从
ApplicationPoolIdentity改成LocalSystem），权限要跟着重配 - 某些杀毒软件或组策略会定期重置 NTFS 权限，可临时禁用策略测试，再通过 PowerShell 脚本固化权限（如用
icacls） - 日志里若出现
HRESULT: 0x80070005，基本锁定为 COM/DCOM 权限问题（如调用 SolidWorks、Excel 等），需单独进dcomcnfg配置，不是简单加文件夹权限能解决的
权限不是一次配完就一劳永逸的事，尤其是涉及临时目录、共享路径、COM 组件的场景，每次部署或系统更新后都得按实际身份核对一遍——漏掉一个斜杠、拼错一个池名，就会卡在“拒绝访问”上不动。
