The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →If WordPress says it cannot write a custom CSS file, first check whether the message names a real .css path. The core Customizer’s Additional CSS feature normally saves CSS in the database as a custom_css post; it does not create a file in wp-content/uploads. An error naming a file such as style-custom.css therefore usually comes from a theme or plugin that maintains its own physical stylesheet.
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
Fix the component that owns the named path, then correct ownership and permissions on that file and every parent directory. Use the safe baseline of 644 for ordinary files and 755 for directories. Do not “solve” the problem by making a theme or uploads directory world-writable with 777.
As an Amazon Associate I earn from qualifying purchases.
Free tools Windows power users keep installed
One-click scans. No signup required.
What the error actually means
The wording is easy to misread because WordPress has two different ways to hold custom CSS.
| CSS source | Where it is stored | What a save operation writes |
|---|---|---|
| Customizer’s Additional CSS | A custom_css post in the WordPress database, indexed to the active theme’s stylesheet |
The post content; WordPress renders it through its custom-CSS output functions |
| Theme or plugin custom-CSS feature | A physical stylesheet in that component’s directory, often with a name such as style-custom.css |
The file on disk and, when applicable, its parent directories |
The core setting uses the edit_css capability and the postMessage transport. It was introduced in WordPress 4.7. When CSS is saved, WordPress updates the existing post for that stylesheet or creates one if necessary. The post title identifies the stylesheet, and revisions are enabled for this post type.
Because the lookup uses the active theme’s get_stylesheet() value, each child theme has a separate custom-CSS post. CSS saved for a parent theme is not automatically the CSS used while its child theme is active. Before WordPress 4.7, theme-specific custom CSS was stored as a theme modification instead of the current post type.
Start with the exact message and path
Do not change permissions until you know which code produced the error. Copy the complete message, including the filename and directory. A message that names style-custom.css inside a theme or plugin is evidence that that component is trying to write a physical file; it is not the normal storage path used by Additional CSS.
Read the path as a clue
- Theme directory: the active theme, a parent theme, or a child theme probably contains a file-writing custom-CSS feature.
- Plugin directory: the plugin is likely generating or compiling a stylesheet of its own.
- Uploads directory: a plugin or theme may be using an upload-based asset workflow rather than core Additional CSS.
- No path, only “Additional CSS”: check the Customizer, the user’s capability, and the selected theme before assuming a filesystem fault.
Record the active theme
In the dashboard, open Appearance → Themes and note whether a child theme is active. Then check Appearance → Customize → Additional CSS. If that screen is the one producing the error but the message names a physical file, look for a theme-specific panel or plugin control that may be intercepting the save.
Find the component that owns the file
Open the directory shown in the error with your host’s file manager or SFTP. The parent folder usually identifies the owner. A file under wp-content/themes/ belongs to a theme; one under wp-content/plugins/ belongs to a plugin.
Rank #2
Check the theme or plugin settings
Search that component’s settings for labels such as Custom CSS, Compiled CSS, Generate stylesheet, or Save CSS to file. Some legacy themes write a generated file instead of printing database content directly. If the component offers an option to print CSS inline or use the WordPress Customizer, that avoids the physical-file write, but make the change only after confirming what the component supports.
Do not edit generated files as a permanent fix
A generated stylesheet can be overwritten the next time the theme or plugin rebuilds its assets. If you must inspect or temporarily edit it for diagnosis, make a backup first and treat the owning component’s configuration as the lasting fix.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errorsCheck permissions on the complete path
WordPress needs permission to traverse every parent directory and to write the target file. A writable file inside a non-traversable directory still fails, as does a writable directory whose file is owned by an account the web process cannot use.
Safe baseline modes
| Object | Baseline mode | Reason |
|---|---|---|
| Ordinary CSS file | 644 |
Owner can read and write; other users can read |
| Theme or plugin directory | 755 |
Owner can write; the web process can traverse and read |
Use your host’s file manager to inspect the named file and each directory above it. If you have shell access, an example for a known file is:
Rank #3
chmod 644 wp-content/themes/your-theme/style-custom.css
chmod 755 wp-content/themes/your-theme
Replace the example path with the exact path from your error. Apply a mode change only to the confirmed target and its required parent directory; do not recursively loosen an entire WordPress installation.
Why changing 755 alone may not work
A file can show a seemingly permissive mode while still being owned by the wrong system account. This is common after a migration, a manual upload, a restore, or a deployment performed by a different user. The web server or PHP process must be able to write as the account that owns, or is granted access to, the file.
If the owner is wrong, ask the hosting provider to correct ownership for the WordPress account and the web process. Avoid guessing a username and running a recursive ownership command: assigning the wrong owner can prevent updates, lock you out of SFTP, or create a broader security problem.
Test the write without using 777
- Back up the named CSS file and the relevant theme or plugin settings.
- Confirm the file’s owner and mode, then inspect every parent directory for matching ownership and a
755-style mode. - Save the custom-CSS setting again from the same dashboard screen that produced the error.
- Reload the file manager or SFTP listing and check whether the file timestamp or contents changed.
- If the save succeeds, verify that the owning component still loads the generated stylesheet and that the CSS is attached to the active theme.
Never set a theme, plugin, or uploads directory to 777 as a shortcut. It allows any local process that can reach the directory to write there and masks the ownership problem that caused the failure.
Rank #4
If permissions look correct but writing still fails
Investigate ownership after a migration
Compare the owner of the failing file with other files that WordPress can update, such as a recently installed plugin file or a newly uploaded media item. A mismatch points to an ownership problem rather than a numeric mode problem. Your host can repair ownership without exposing the directory to every system user.
Ask about a read-only filesystem
Some managed, containerized, or hardened environments mount theme and plugin paths read-only. In that case, no chmod change can make the write succeed. Ask the host whether the path is read-only, whether a deployment process must publish generated assets, or whether the component should write to a designated writable directory.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Check disk and account limits with the host
A full filesystem or a hosting account that has reached its file or inode limit can reject a write even when ownership and modes are correct. The host can confirm these limits from server logs and restore service without changing WordPress permissions broadly.
Separate a core Additional CSS problem from a file-writer problem
Use this decision path when the error source is unclear:
Best Value
- The message names a physical CSS file. Identify the theme or plugin at that path and follow its file-write workflow.
- The message appears while editing Additional CSS but names no file. Confirm that the user has the
edit_csscapability and that the active theme is the one you intend to customize. - The CSS field saves, but the field later appears empty. Check the active theme and its child-theme relationship, then inspect revisions for the theme’s
custom_csspost before concluding that the CSS was deleted. - The CSS exists in the database but is not visible on the site. Verify that the same theme whose stylesheet key owns the post is active. A post belonging to another theme is retained but is not the CSS currently emitted.
Recover CSS that appears to have disappeared
Switching themes can make Additional CSS appear blank because each theme has its own post. First identify the theme that was active when the CSS was written. Re-activate that theme temporarily, open Appearance → Customize → Additional CSS, and inspect the field and its revisions. Revisions are enabled for the custom_css post type, so an earlier saved version may be available even when the current field is empty.
Do not paste recovered CSS into a generated style-custom.css file unless the owning theme explicitly requires that workflow. For core Additional CSS, saving it in the Customizer keeps it associated with the correct theme and avoids a future generated-file overwrite.
Recommended Free Tools
When a child theme is involved
A child theme has its own stylesheet identity, so its Additional CSS is separate from the parent theme’s CSS post. If you moved from a parent theme to its child, copy the required rules into the child theme’s Additional CSS while the child is active. If you later return to the parent, its previous CSS post may still exist, but the child’s rules will not automatically follow.
For a physical file error, inspect both the child and parent directories. A child theme can call a parent component that still tries to write a generated file, and a plugin can write outside either theme directory. The path in the error, not the visual location of a dashboard control, determines which owner must be fixed.
Common wrong turns
- Changing only the file to 755: the parent directory or owner may still block the web process.
- Making everything 777: this removes an important security boundary and does not address read-only mounts or host policy.
- Assuming Additional CSS is in uploads: core Additional CSS is database content tied to a theme stylesheet, not a normal uploads file.
- Editing a generated file and stopping there: the next regeneration can erase the edit.
- Blaming deletion when a field is empty: a theme change can select a different
custom_csspost; check the original theme and revisions. - Changing unrelated directories: broad permission changes increase risk and make the original failure harder to diagnose.
What to give your hosting provider
Provide the exact error text, the complete path, the active theme and whether it is a child theme, the component that owns the path, the file’s current owner and mode, and the time the failure occurred. Ask the host to check web-process ownership, read-only mounts, disk or inode limits, and server logs for the attempted write. This information lets the host correct the specific account or filesystem restriction instead of recommending an unsafe global permission change.
Quick Recap
A reliable fix checklist
- Copy the complete error and named path.
- Determine whether the path belongs to a theme or plugin.
- Distinguish a physical-file writer from core Additional CSS.
- Back up the target file and settings.
- Check ownership and traversal of every parent directory.
- Use
644for the CSS file and755for its directories. - Do not use
777. - Retest the save and confirm the generated stylesheet is loaded.
- If the write still fails, have the host check ownership, read-only restrictions, and account limits.
- If CSS appears missing, check the correct theme’s
custom_csspost and its revisions.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.




