中文
English 在部署 IIS 网站时，文件夹权限配置是保障网站正常运行与安全防护的关键步骤。本文基于一次实战排查，详细梳理了 IUSR、IIS_IUSRS、Everyone 之间的区别、用途及推荐做法，同时指出了常见误区。
一、关键账户角色说明
| 用户/组名 | 说明 |
|---|---|
| IUSR | 用于匿名访问网站的内置用户（由 IIS 自动使用）。 |
| IIS_IUSRS | 一个用户组，包含所有 IIS 相关账户（如各 AppPool 身份）。 |
| IIS APPPOOL\xxx | 应用池的虚拟账户，用于以隔离身份运行网站，推荐用于权限控制。 |
| Everyone | 包括所有本地和网络用户，过于宽泛，通常不推荐在公网服务器使用。 |
二、默认情况下 IUSR 应赋予什么权限？
针对网站根目录（如 C:\inetpub\wwwroot\MySite\），IUSR（或等效账户）通常只需以下权限：
-
✅ 读取（Read）
-
✅ 读取和执行（Read & Execute）
-
✅ 列出文件夹内容（List Folder Contents）
❗ 注意：仅授予
Read权限是不够的。必须同时有读取和执行等权限，否则静态页面可以访问，PHP 或其他脚本文件将无法正常运行。
三、当网站涉及上传或生成文件怎么办？
如果网站支持匿名用户上传（如头像、图片）或运行时生成日志、缓存，则：
-
✅ 不应为整个网站目录授予写入权限；
-
✅ 应只对特定子目录（如
uploads/、logs/）授予写入权限。
例如：
C:\inetpub\wwwroot\MySite\
├── index.html
├── css\
├── uploads\ ← 仅此目录授予写权限
推荐做法：
-
向
uploads\授权IIS_IUSRS或IIS APPPOOL\YourAppPoolName：-
✅ 读取
-
✅ 写入（Write）
-
✅ 修改（Modify）
-
相比直接给
IUSR赋权，使用IIS_IUSRS更安全、兼容性更强。
四、删除 Everyone 后出现“文件不存在”问题
案例：删除 Everyone 后，Joomla 网站提示：
plugins/system/ytshortcodes/assets/css/shortcodes.css not exists
实质原因不是文件不存在，而是当前网站运行用户没有权限读取该文件。
解决方案：
-
为目录手动添加
IIS_IUSRS或应用池账户（如IIS APPPOOL\MyAppPool）的读取权限； -
可使用以下命令修复：
icacls "C:\inetpub\wwwroot\your_site\plugins\system\ytshortcodes\assets\css" /grant "IIS_IUSRS:(OI)(CI)(RX)" /T
五、Everyone 权限到底要不要保留？
| 项 | 分析 |
|---|---|
| ✅ 不是必须 | IIS 网站只要为运行账户正确设置权限即可，无需保留 Everyone。 |
| ⚠️ 删除前需谨慎 | 如果未显式授予其他账户权限，删除 Everyone 可能造成网站 403、404、500 等错误。 |
| ❌ 不建议用于公网网站 | 由于包含所有用户，Everyone 容易成为安全隐患，建议删除。 |
✅ 判断自己是否需要 Everyone：
你可以先暂时删除 Everyone，然后只赋权限给 IIS_IUSRS 或应用池账户，如果网站运行正常（无 403、404、500 等错误），就说明可以安全去除 Everyone，无需保留。
六、总结与推荐实践
| 项目 | 推荐设置 |
|---|---|
| 网站根目录 | IIS_IUSRS 或 IIS APPPOOL\xxx：读取 / 执行 |
| 上传目录等 | 同上：+ 写入权限 |
| 不使用的匿名写权限 | 禁止 |
Everyone |
不推荐使用，除非非常清楚其风险与作用 |
| 脚本执行错误排查 | 先查文件是否存在，其次查“是否有读取权限” |
七、实战经验总结：常见误区与注意事项
❌ 误区 1：认为给
IUSR设置 read 权限就够了，忽略了Read & Execute。
❌ 误区 2：直接给整个网站目录赋写权限，存在安全风险。
❌ 误区 3：删除
Everyone却忘了给其他用户组补充权限，导致网站异常。
✅ 注意事项：
-
修改权限前，先了解网站使用的应用池身份；
-
修改权限后，推荐使用
icacls等命令行工具统一修复； -
上传目录、缓存目录等应单独设置权限，切勿全站开放写权限。
