Fix IIS Configuration File Permissions

This IIS configuration error means Windows blocked the identity loading the site from reading a configuration file or one of its parent folders. The safe repair is to identify the actual application-pool or service identity, confirm the exact path named in the error, grant only the required read access, then recycle the affected application pool and test the site. Do not give Everyone broad access as a permanent fix: it hides the real identity problem and unnecessarily exposes configuration files. Use this table to match the error details to the most likely place to investigate.

Symptom	Likely Cause	Safe Fix
The error names web.config inside the application directory	The site’s runtime identity cannot read the app folder, file, or a parent folder	Check the app pool identity and grant it read access to the necessary application path
Granting access to the web app folder does not help	IIS is reading a separate, global configuration file	Use the filename and physical path shown in the error instead of assuming the app folder is involved
Access works after granting Everyone permissions	Permissions are the issue, but the correct account has not been identified	Remove the broad test permission and grant the actual runtime identity or a limited group
A custom service account or managed service account is configured	Permissions were granted to a default IIS account instead of the configured identity	Grant access to the account assigned to the affected site or service
A Nodinite Core Service error names redirection.config	The configured service identity cannot read IIS’s global configuration directory	Check the Nodinite service identity and its access to the IIS configuration directory

What the IIS Configuration Permission Error Means

IIS loads configuration before it can run much of your application. That configuration can come from several places, including the site’s web.config, a parent directory’s configuration, or IIS-wide configuration files. If Windows denies the process identity access at any point, IIS returns a configuration error instead of starting the application.

The filename in the error page is the most important clue. Treat it as the source of truth. A permission change on your application directory will not fix an error caused by a file elsewhere on the server.

Windows access checks also apply to the folders leading to the file. An account may have permission on a config file itself but still fail if it cannot traverse or read the relevant parent directory. Explicit deny entries, broken inherited permissions, encrypted files, and network-share permissions can also produce an access-denied result.

The account that browses the site is not always the account IIS uses to read configuration. For example, changing permissions for Network Service, IUSR, or an anonymous-authentication account is ineffective if the affected application pool uses a custom identity.

How to Fix the IIS Configuration Permission Error

Step 1: Capture the Exact File and Physical Path

1. Reproduce the error and copy the complete error details before changing permissions.
2. Record the configuration filename, the physical path, and the affected website or application pool.
3. Check whether the named file is inside the application directory, an IIS configuration directory, or a network location.
4. Avoid editing the configuration file yet. A malformed configuration file causes a different problem and can make the permission issue harder to diagnose.

If the error names a file under your deployment directory, begin with that deployment path. If it names a file under the Windows directory or another system-managed location, changing your app folder ACL is unlikely to solve it.

Step 2: Identify the Identity That Actually Runs the Site

1. Find the application pool assigned to the affected IIS site.
2. Inspect that application pool’s configured identity.
3. If the application uses a custom Windows account, group-managed service account, or service-specific account, use that exact identity in the permission check.
4. Do not assume that Network Service is the correct account merely because it is common on older IIS installations.

For a Nodinite Core Service, the relevant IIS website identity is configured in the Nodinite Portal’s Auth step and Servers step. Nodinite’s Core Service documentation specifically ties this error to the service identity assigned there.

Anonymous authentication can add confusion. The anonymous user may be relevant when IIS serves content, but it is not automatically the identity that reads every IIS configuration resource. Diagnose the identity configured for the affected application pool or service instead of granting access to several guessed accounts.

Step 3: Check Effective Access on the Named Path

1. Open the security settings for the exact file named in the error.
2. Check whether the affected identity has read access to that file.
3. Check each parent folder from the application or configuration root down to the file.
4. Look for explicit deny entries, missing inherited permissions, or a permission entry that applies only to files or only to folders.
5. If the path is on a network share, verify both the share permissions and the underlying NTFS permissions.

Windows evaluates the effective combination of direct permissions, inherited permissions, group membership, and deny entries. A direct allow entry may not help if a deny entry applies to the same identity through a group.

Be especially careful when the configuration path is under a system directory. Do not take ownership, disable inherited protection, or replace broad system ACLs just to eliminate an error. Those changes can affect other IIS sites and Windows components.

Step 4: Grant the Smallest Necessary Permission

1. Grant the identified runtime identity read access to the exact configuration location it needs.
2. Prefer a suitable limited group when multiple related services need the same access.
3. Preserve existing inherited entries unless you have identified a specific broken entry.
4. Remove any temporary Everyone, Users, or broad write permissions used during testing.

For an ordinary application config file, the fix is usually read access for the application pool identity on the application directory and its configuration files. Do not grant Modify or Full Control unless the application has a separate, documented need to write there.

For a Nodinite Core Service that fails while reading IIS configuration, Nodinite recommends adding the service identity to the local IIS_IUSRS group and ensuring that group has Read rights on %windir%\system32\inetsrv\config. The alternative is to grant the service identity itself Read rights on %windir%\system32\inetsrv\config.

Step 5: Recycle the Application Pool and Test the Site

1. Recycle the application pool assigned to the affected website.
2. Request the failing page, API endpoint, or service health endpoint again.
3. Confirm that the configuration error no longer appears.
4. Review the resulting ACL and remove any temporary diagnostic permissions.
5. If the error remains, compare the error’s filename and physical path with the path you changed. A mismatch means IIS is still failing on a different resource.

For the Nodinite case, recycle the application pool for the affected website after applying either permission fix. Nodinite specifically calls for recycling the affected pool after correcting the access issue.

IIS Cases That Commonly Lead to the Wrong Fix

Wrong fixes commonly result from changing the application-folder ACL, granting access to a guessed account, or confusing authentication with configuration loading.

The Application Folder Is Not the Denied Location

If changing the application-folder ACL changes nothing, the actual denied configuration file may be outside the application folder.

This is especially important when the error gives a system path. A site can start reading its own web.config and then fail while IIS reads global configuration required by a module, provider, or management API.

For Nodinite Core Service on Windows Server, the denied file can be redirection.config in %windir%\system32\inetsrv\config, rather than a file below the web application. That is why access changes limited to the deployed application folder may fail to resolve the error.

The Wrong IIS Account Received Permission

Older IIS setups often used familiar built-in accounts, which makes it tempting to try them one at a time. Modern deployments may instead use an application-pool virtual identity, a domain service account, a managed service account, or a product-specific account.

Granting permissions to a guessed identity can create a misleading test result. The correct approach is to start with the identity assigned to the affected app pool or service, then verify that its effective access reaches the exact file IIS reports.

Authentication Settings Change the Symptom

Switching from anonymous authentication to Windows authentication may change which user can access site content, but it does not automatically repair an application-pool configuration read failure. Likewise, adding permissions for IUSR can appear to solve one type of request failure while leaving the underlying service identity unable to load configuration.

Keep the authorization problem separate from the configuration-loading problem:

• Authentication controls who may request the application.
• File-system permissions control which identity may read configuration and content.
• Application pool identity controls which Windows identity runs the worker process unless the application deliberately impersonates another account.

How to Confirm the Fix and Prevent a Repeat

A completed repair should meet all of these conditions:

• The affected IIS site loads without the configuration permission error.
• The application pool remains assigned to its intended identity.
• The account has only the access it needs, normally read access for configuration.
• Temporary broad permissions have been removed.
• No explicit deny entry still applies to the account or one of its groups.
• The configuration path and its parent folders have consistent access rules.

Document the service name, application pool, runtime identity, configuration location, and reason for the ACL entry. This matters during server rebuilds, identity changes, and deployments, when a working permission can otherwise disappear without an obvious explanation.

Avoid storing application code, writable uploads, logs, and sensitive configuration under one broadly writable directory. Separating read-only deployment files from runtime-write locations makes permission troubleshooting safer and reduces the temptation to grant excessive access.

If the error still occurs after a least-privilege ACL change and application-pool recycle, capture the new error details and investigate the exact filename it reports rather than widening permissions further.

Frequently Asked Questions

Which IIS account needs permission to read the configuration file?

The account that needs access is the identity actually assigned to the affected application pool or service. It may be an application-pool identity, a custom service account, or a managed service account rather than Network Service or IUSR. Check the affected site’s configured runtime identity, then grant that identity only the read access required by the error’s physical path.

Why did granting Network Service permission not fix the error?

Granting Network Service does not help when the application pool is configured to run under another identity. IIS may use a custom account, an application-pool virtual account, or a product-specific service identity. Compare the account you granted with the identity configured for the site that generated the error.

How do I fix a Server Error in “/” Application caused by access denied?

Start with the filename and physical path displayed in the error, then identify the application pool’s runtime identity and check its effective read access to that file and every required parent folder. Grant only the needed read permission, recycle the application pool, and retry the failing request. If the file is on a network share, both share and NTFS permissions must permit the account.

What are the three basic file permissions?

The three basic permission types are read, write, and execute. Read permits viewing file contents or configuration data, write permits changing or deleting content, and execute permits running a program or traversing a directory where applicable. A configuration file should normally require read access, not write access, for the IIS runtime identity.

Should I use chmod 777 to fix a configuration permission error?

No. chmod 777 gives every local user read, write, and execute access on Linux and is not a safe general fix. It also does not apply to Windows NTFS ACLs or IIS configuration errors; on IIS, grant the identified application or service identity the minimum read access needed for the named configuration path.

What should you check when ServerManager cannot read an IIS configuration file?

Check whether the application-pool identity for the affected IIS site can read the configuration file that ServerManager is accessing. If the error names redirection.config, its documented location is %windir%\system32\inetsrv\config; grant the service identity Read rights on that directory.