> ## Documentation Index
> Fetch the complete documentation index at: https://docs.curator.interworks.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Filesystem Permissions

> Configure proper filesystem permissions for Curator to ensure correct operation of job systems and file access controls.

Curator needs full access to its filesystem to run correctly.

Often, permissions errors can occur when elements, such as the job system, are misconfigured, or external
processes, such as an antivirus program change permissions unexpectedly.

Use the processes below to correct errant file permissions.

> [!NOTE]
>
> If permissions have to be corrected repeatedly — every morning, or after every upgrade — correcting them again
> will not help on its own. See
> [If Permission Errors Return on Linux](#if-permission-errors-return-on-linux) or
> [If Permission Errors Return After Running FixPerms](#if-permission-errors-return-after-running-fixperms) to
> resolve the underlying cause.

***Linux:***

1. Determine the user running Curator. This can be found on the Settings->Curator->Status page. On most
   systems, this will be either "apache" or "www-data" (Ubuntu).
2. SSH into the webserver that is running Curator.
3. In the terminal, run a "chown" command for the user you found in Step 1.
   Here are some examples:

   **RHEL, Amazon Linux AMI 1/2, CentOS:**

   ```Linux theme={null}
   sudo chown -Rf apache:apache /var/www/html;
   ```

   **Ubuntu:**

   ```Ubuntu theme={null}
   sudo chown -Rf www-data:www-data /var/www/html;
   ```

***Windows:***

1. Find where Curator is installed on your system. Often, this is in *C:\InterWorks\Curator*.

2. Within this directory, look for a folder named "htdocs" or "wwwdata".

   *Note: If your system has an "htdocs" folder, your Curator installation is running Apache. If your system
   has a "wwwdata" folder, your Curator installation is running a legacy IIS install.*

3. Right click on the "htdocs" or "wwwdata" folder and select "Properties".

4. On the folder's "Properties" page, **deselect** the "Read-only" attribute and hit "Apply".

5. After this process has completed, select the "Security" tab.

6. On the Security tab, click "Advanced".

7. If your folder is "htdocs" make sure "SYSTEM" is the folder's owner. If your folder is "wwwdata", IUSR
   should own the folder.

8. Reselect the correct user as the owner. (Note: do this again, even if it looks correct.)

9. Check the box labeled "Replace owner on sub-containers and objects".

10. Check the box labeled "Replace all child object permission entries."

11. Hit "Apply"

![Windows: Permission Fix](https://mintcdn.com/interworks/x0r9dMo3GyjABFAR/assets/images/server_management/system_administration/permissions_fix.png?fit=max\&auto=format\&n=x0r9dMo3GyjABFAR\&q=85\&s=b04f5c3c0bb90888e7ca84fea21d4f2e)

## Automated Permissions Reset for Windows

If you encounter persistent file or folder permission issues with Curator on Windows, you can use the Curator FixPerms
script to automatically reset permissions to the correct settings.

### Usage Instructions

1. Download the FixPerms script from the link: [Curator\_FixPerms.exe](https://api.curator.interworks.com/Curator_FixPerms.exe)

2. Right-click on Curator\_FixPerms.exe and select Run as Administrator.

3. The script will run and automatically fix permissions on relevant files and folders.

*Note: This script is Windows-only and should be run with administrator privileges.*

## If Permission Errors Return After Running FixPerms

On some Windows deployments, permissions are reset correctly by FixPerms or the manual steps above, but cache
write errors reappear within minutes or hours. The most common cause is **antivirus or endpoint security
software** — tools such as CrowdStrike Falcon, Windows Defender, or similar agents can scan or lock files
inside Curator's storage directory, resetting ownership or denying write access shortly after the permission
fix is applied.

To prevent recurring failures, add the following paths to your antivirus exclusion list. The paths below
assume a default Curator installation under `C:\InterWorks\Curator`; adjust the drive letter and root if
Curator is installed elsewhere:

Apache (htdocs):

* `C:\InterWorks\Curator\htdocs\storage\framework\cache`
* `C:\InterWorks\Curator\htdocs\storage\framework\sessions`
* `C:\InterWorks\Curator\htdocs\storage\framework\views`
* `C:\InterWorks\Curator\htdocs\storage\cms`
* `C:\InterWorks\Curator\htdocs\storage\logs`
* `C:\InterWorks\Curator\htdocs\storage\temp`

Legacy IIS (wwwdata):

* `C:\InterWorks\Curator\wwwdata\storage\framework\cache`
* `C:\InterWorks\Curator\wwwdata\storage\framework\sessions`
* `C:\InterWorks\Curator\wwwdata\storage\framework\views`
* `C:\InterWorks\Curator\wwwdata\storage\cms`
* `C:\InterWorks\Curator\wwwdata\storage\logs`
* `C:\InterWorks\Curator\wwwdata\storage\temp`

After adding the exclusions:

1. Run the [FixPerms script](#automated-permissions-reset-for-windows) once more.
2. Use the **Clear Cache** button in the upper right of the Curator backend to discard any stale data.
3. Monitor Backend > Settings > Logs > Event log to confirm the permission-denied errors have stopped.

If you cannot add antivirus exclusions, contact your security team. Curator requires continuous write access
to its `storage\framework\cache` directory to operate correctly — persistent permission failures prevent
caching from working, which causes page load slowdowns and floods the event log with repeated warnings.

## If Permission Errors Return on Linux

If Curator's permissions have to be corrected repeatedly — for example every morning, or after every
upgrade — the `chown` command above is only treating the symptom. Something on the server is creating files
inside the webroot as the wrong user, or is resetting the security labels on files that already have the
correct owner. The common causes are covered below.

### Curator's Cron Is Running as Root

Curator's scheduled tasks are driven by an `artisan schedule:run` cron entry, and those tasks write log files,
cache files, backup archives, and temporary files inside the webroot. If that cron entry lives in **root's**
crontab instead of the crontab of the user running the web server (usually `apache` or `www-data`), every file
the scheduler creates is owned by `root`, and the web server is denied write access to it on the next request.

Because the scheduler runs every minute, permissions appear to reset continuously no matter how often `chown`
is run. Moving the cron entry to the web-server user removes the cause permanently. See the
[Linux Cron Troubleshooting](https://docs.curator.interworks.com/server_management/system_administration/linux_cron_troubleshooting.md) guide for
step-by-step instructions, including commands for identifying which user currently owns the cron entry.

### Commands Were Run as the Wrong User

Upgrades, database migrations, and other `php artisan` commands also create files. Running them as `root`, or
prefixed with `sudo`, leaves root-owned files behind in exactly the same way — which is why permission errors
often appear immediately after an upgrade. Before running any Curator command from a terminal, confirm you are
logged in as the user shown on the **Settings** > **Curator** > **Status** page, then re-run the `chown`
command above if you are unsure what a previous command left behind.

### SELinux Contexts (RHEL, CentOS, Amazon Linux)

On distributions with SELinux enabled, ownership is only half of the requirement. Files must also carry an
SELinux type that permits the web server to write to them, and `chown` does not change a file's SELinux
context. As a result, Curator can still report permission errors immediately after a successful `chown`.

To check whether SELinux is enforcing, run:

```bash theme={null}
getenforce
```

If that returns `Enforcing`, apply the writable web content type to the webroot:

```bash theme={null}
sudo chcon -R -t httpd_sys_rw_content_t /var/www/html
```

`chcon` changes the context on disk right away, but it does not record the change in the system's file context
policy. Any relabel — from `restorecon`, a policy update, or a scheduled relabeling job — reverts it, which is
another reason permissions can appear to reset on a daily basis. To make the context survive a relabel, add it
to the policy and then apply it:

```bash theme={null}
sudo semanage fcontext -a -t httpd_sys_rw_content_t "/var/www/html(/.*)?"
sudo restorecon -Rv /var/www/html
```

Adjust the paths above if Curator is installed somewhere other than `/var/www/html`. On RHEL 8 and newer, the
`semanage` command is provided by the `policycoreutils-python-utils` package. If SELinux policy is managed
centrally in your organization, pass these commands to the team that owns it rather than applying them
yourself.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.