Problem: IIS permissions
"Access is denied." So you gave Everyone full control.
A 500.19 error, a CMS that cannot update itself, uploads that fail, logs that never appear. The first search result says to grant Everyone or Users full control on the website folder, and it works, which is why so many Windows web servers are one compromised plugin away from every site on the box being rewritten. Here is what the application pool actually needs, folder by folder.
Part of the Server setup and Websites modules. 30-day money-back promise.
Who is asking for access
Each IIS website runs in an application pool, and by default the pool runs as a virtual account named after it: IIS AppPool\example.com. That account, not IIS_IUSRS and certainly not Everyone, is what needs permission on the site's folders. Grant it exactly what each folder is for and nothing more:
| Site root | Read and execute. The pool must traverse the folder and read configuration, nothing else. |
|---|---|
| wwwroot | Modify, if the application updates itself or accepts uploads (WordPress, most CMSs). Read only for a static site or a deployed application that is never written at runtime. |
| logs | Modify. IIS and PHP write here. |
| temp (sessions, uploads in progress) | Modify. Keep it outside wwwroot so nothing in it can ever be served. |
| private (configuration, credentials) | Read. The application reads its database credentials from here; it never needs to write them, and nothing here is under wwwroot. |
| backups | Nothing. A compromised site must not be able to read or delete its own backups. |
Grant it by hand
One command per folder, from an administrator prompt. This grants the pool identity modify on wwwroot, inherited by files and subfolders:
icacls "C:\websites\example.com\wwwroot" /grant "IIS AppPool\example.com:(OI)(CI)M"Use RX instead of M for read and execute. Then remove any entry for Everyone or Users that a previous fix left behind, and check that inheritance from a parent folder is not quietly granting more than you intended.
Why Everyone full control is how sites get hacked
Every website on the server, every local account and every process can then write anywhere under that folder. One outdated plugin on one site lets an attacker write a file into every other site's wwwroot, read every site's database credentials, and delete the backups. Per-site permissions turn one compromised site into one compromised site.
What ServerMaid does
The exact ACL, computed and applied
Nothing to Everyone or Users
Ever. Each website's application pool gets read on its folder, modify only on wwwroot, temp and logs, and nothing on backups.
A permission engine
ServerMaid computes the exact ACL each folder needs and applies only what differs, so a re-run changes nothing that is already right and a hand-made mess is put back in order.
A clean layout per site
Every website gets wwwroot, logs, private, temp and backups under a websites root you choose, so temp files and credentials are never inside the folder that is served.
Drift caught
Broad write access is one of the attack signals the health score watches for. A folder that has been opened up since the build is a deduction with the fix next to it.
Repair in one click
Repair compares every site's permissions with what they should be and applies the difference, without touching the files themselves.
Plain English errors
A permission problem is reported as which site, which folder and what is missing, with a Fix button, not as a 500.19 code to search for.
Questions about IIS permissions
What about IIS_IUSRS?
IIS_IUSRS is a group containing every application pool identity on the server. Granting it access to one site's folder grants every site's pool access to that folder, which defeats the point. Grant the site's own pool identity instead.
Does WordPress really need modify on wwwroot?
Yes, if you want it to update itself, install plugins and accept media uploads. That is a trade-off every CMS makes. Keeping temp, credentials and backups outside wwwroot limits what a compromised plugin can reach.
Should the pool run as a custom account instead?
The built-in virtual account per pool is the recommended default: it is isolated, has no password to manage and is created automatically. A custom account is only needed to reach resources on other machines.
Will ServerMaid change permissions on folders it did not create?
No. It manages the websites root it created and the sites under it. Folders belonging to other applications are reported if they look risky and left alone.
Can I see what will change before it is applied?
Yes. Preview lists every permission change per folder before anything runs, and each change is journaled so it can be rolled back.
Per-site permissions, without the spreadsheet
Every website ServerMaid creates gets the exact permissions it needs and no more, kept that way by the health score and Repair.