✅ Understanding IUSR, IIS_IUSRS, and Everyone Permissions in IIS

When setting up a website on IIS, one of the most critical but often overlooked aspects is file system permissions. Misconfigured permissions can lead to security vulnerabilities or runtime errors such as “file not found” or “access denied.”

This article walks through how IUSR, IIS_IUSRS, and Everyone function in the context of an IIS web server, and provides practical, security-conscious guidance based on real-world troubleshooting.

1. Key IIS User Accounts and Groups

2. What Permissions Should IUSR Have by Default?

For the website root directory (e.g. C:\inetpub\wwwroot\MySite\), if anonymous access is enabled, IUSR should have:

• ✅ Read

• ✅ Read & Execute

• ✅ List Folder Contents

⚠️ Note: Granting only Read is not sufficient. Read & Execute is essential for dynamic content like PHP, ASP.NET, or compiled scripts to function correctly.

3. What If the Website Allows Uploads or File Generation?

If your site allows users to upload files (e.g. profile images), or generates logs, caches, or thumbnails, do not give write permissions to the whole site root.

Instead:

• ✅ Create dedicated directories (like uploads/ or logs/) for file write operations.

• ✅ Grant only those directories the necessary write permissions.

Example structure:

C:\inetpub\wwwroot\MySite\
├── index.html
├── css\
├── uploads\    ← This directory alone gets write permissions

Recommended Permissions (for uploads/):

• ✅ IIS_IUSRS or IIS APPPOOL\YourApp

  • Read

  • Write

  • Modify

💡 Using IIS_IUSRS is safer and more future-proof than assigning permissions to IUSR directly.

4. Real-World Issue: File “Not Exists” After Removing Everyone

Case: After removing the Everyone group, a Joomla 5 site threw an error:

plugins/system/ytshortcodes/assets/css/shortcodes.css not exists

Diagnosis: The file existed — the problem was insufficient file permissions for the account running the website.

Resolution:

Explicitly grant access to the proper account:

icacls "C:\inetpub\wwwroot\your_site\plugins\system\ytshortcodes\assets\css" /grant "IIS_IUSRS:(OI)(CI)(RX)" /T

5. Should You Keep the Everyone Group?

✅ How to Decide if You Can Remove Everyone:

You can temporarily remove the Everyone group, then grant access only to IIS_IUSRS or your app pool account.

If the website runs fine afterward (no 403/404/500 errors), then it’s safe to permanently remove Everyone.

6. Best Practices Summary

7. Common Mistakes & What to Watch Out For

❌ Mistake 1: Granting only Read to IUSR, ignoring Read & Execute.

❌ Mistake 2: Giving full write permissions to the entire site folder.

❌ Mistake 3: Removing Everyone without first assigning necessary permissions to IIS_IUSRS or app pool identity.

✅ Checklist:

• Understand what user runs your site (check the app pool identity).

• Use icacls or File Explorer to audit and fix permissions.

• Grant Write only to specific folders like uploads/.

• Test the site after any permission changes.