Skip to main content
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.
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 or 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:
    Ubuntu:
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

​
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
  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 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 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:
If that returns Enforcing, apply the writable web content type to the webroot:
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:
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.