Windows站点搭建总踩坑？5步权限配置法一次到位

　　去年四月份，我在客户机房盯IIS站点上线——不是远程，是真坐在那张掉漆的蓝色折叠椅上，手边泡了半杯凉透的茉莉花茶，杯底沉着三颗没化的糖粒。

　　站点跑起来了，首页能打开，但一进后台就502。反复刷新七次，第八次我盯着错误日志里那行“HTTP Error 502.5 - Process Failure”，突然想起刚才运维小张甩过来一句：“这台服务器刚重装过系统，组策略全清了。”

　　我原以为只是应用池启动失败，结果翻进程列表发现w3wp.exe根本没起来；再查事件查看器，Event ID 1000底下压着一行灰字：“The application 'xxx' failed to start because it could not read the web.config file — access denied.”

　　——等等，web.config？我明明给IIS_IUSRS加过读取权限啊。
（窗台上那盆绿萝叶子尖发黄，我伸手捏了捏，脆，一碰就断。）

　　回看权限继承链：D:\\www\\site1这个目录，NTFS权限里IIS_IUSRS只挂了“读取和执行”“列出文件夹内容”“读取”，但缺了“遍历文件夹/执行文件”。这玩意儿不起眼，不点开高级权限根本看不到勾没勾上。而ApplicationPoolIdentity默认身份恰好要靠“遍历”才能钻进子目录去读web.config——它连根目录都进不去，更别说读子目录下的config了。

　　我补上“遍历”，再重启应用池，502没了。可紧接着另一个报错弹出来：“Could not load file or assembly 'Newtonsoft.Json, Version=13.0.0.0...' — Access is denied.”
（楼道里有人拖着椅子走过，刺啦、刺啦、停顿两秒、又刺啦。）

　　这才意识到bin目录下dll文件本身没继承父目录权限——NTFS权限不自动下传到已有文件，只对新创建的生效。我们部署用的是7z解压脚本，解出来的dll全沿用压缩包里旧的ACL，Owner还是Administrator，IIS_IUSRS在上面连个影子都没有。二十来分钟里我手动选中所有.dll，右键→属性→安全→编辑→添加→IIS_IUSRS→勾读取→确定……光点确认就点了六十三次。

文章配图，仅供参考

　　五步真有：1. 目录级给IIS_IUSRS加“遍历”（别信继承）；2. 手动补全所有dll的读取权限（脚本不管旧文件）；3. 检查applicationHost.config里对应applicationPool的identity类型（必须是ApplicationPoolIdentity，不是NetworkService）；4. 确认磁盘是NTFS格式（FAT32直接死）；5. 进程启动账户对%SystemRoot%\\System32\\inetsrv\\config\\applicationHost.config有读权限（很多人漏这儿）。
但第四步那个NTFS判据——我今天翻三台服务器才遇到一台是FAT32的，还是2012年装的旧镜像，谁还敢用FAT32配IIS？反正我觉得它站得住的地方是优胜劣汰：活下来的Windows服务器，早把FAT32筛掉了。

　　最后我让小张自己再跑一遍流程，他卡在第三步，问我：“这个identity在哪儿改？”我说路径，他说“哦哦”，十秒后喊我：“刘工，改完了，可应用池还是‘停止’状态……”
我走过去看，他改的是defaultapppool，不是我们新建的那个site1pool——名字太像，他眼花了。
有谁碰到过这个吗

（编辑：航空爱好网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!