What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
A Linux upload fails with Permission denied when the account performing the upload cannot traverse the path or cannot write to the destination directory. The account you use over SSH may not be the account running the web application. Inspect both identities and every directory in the path, then grant write access only to the required upload directory. Do not solve the problem with chmod 777.
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
Why Linux refuses the upload
Linux evaluates an operation using the effective user and group IDs of the process. For a path such as /var/www/example/uploads, that process must be able to cross /var, /var/www, /var/www/example, and finally uploads. A directory’s permissions have distinct meanings: read permits listing entries, write permits creating or deleting entries, and execute permits crossing or searching the directory. The Debian Handbook explains directory rights in these terms.
As an Amazon Associate I earn from qualifying purchases.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchThat means a writable-looking file does not prove that an upload can succeed. Creating a new file requires write and execute permission on the destination directory. Deleting or replacing an existing file also depends on the containing directory. A parent directory without execute permission causes denial before Linux reaches the target.
The identity is often the surprise. Your interactive shell might be logged in as deploy, while a web server or application worker runs as www-data on Debian and Ubuntu. Other distributions commonly use a different account, such as apache. Documentation for web applications such as Nextcloud’s source installation also stresses verifying the actual service user instead of assuming one universal name.
#1 Best Overall
Diagnose before changing permissions
Run the inspection as the user who sees the failure, and substitute your real site and upload path. These commands reveal the acting identity, permissions on every path component, ownership, and any access-control lists:
id
namei -l /var/www/example/uploads
ls -ld /var/www /var/www/example /var/www/example/uploads
stat -c '%A %U:%G %n' /var/www /var/www/example /var/www/example/uploads
getfacl -p /var/www/example/uploadsid shows the account and supplementary groups for the current shell. namei -l is particularly valuable because it displays each component rather than only the final directory. In the ls or stat output, check the owner, group, and whether the relevant class has x on every directory and wx on the upload directory. getfacl exposes ACL entries that ordinary mode bits do not show.
Free tools Windows power users keep installed
One-click scans. No signup required.
Do not test only as your SSH user. Test with the service identity that actually handles the HTTP request. On a Debian or Ubuntu system where the configured account is www-data:
sudo -u www-data touch /var/www/example/uploads/.perm-test
sudo -u www-data rm /var/www/example/uploads/.perm-testA successful create-and-remove test confirms that the service account can traverse the path and modify the directory. A failure tells you the web process still lacks an effective permission, regardless of what your own account can do. Replace www-data with the account configured for your server; using the wrong name can produce a misleading diagnosis.
Choose the narrowest access model
There are three common approaches. The first two can be made narrow and auditable; the third is intentionally included only to explain why it is unsafe.
| Approach | Identity receiving access | Write scope | New-file inheritance | Auditability and risk |
|---|---|---|---|---|
| Deploy owner plus web-server group | The deploy account owns the tree; the configured web account uses the shared group. | Only directories such as uploads or cache are group-writable. |
Setgid directories can make new entries inherit the directory group, but filesystem and mount behavior must be verified. | Simple to inspect and reverse. A compromised web process can write only where the group is granted write permission. |
| ACL exception | A named service account receives an ACL entry without changing the principal owner or group. | Can be limited to one directory or even a particular operation. | Default ACLs can be applied so descendants inherit the intended entry. | Fine-grained, but administrators must inspect ACLs with getfacl; mode bits alone are incomplete. |
World-writable mode (chmod 777) |
Every local user and process. | Any process that can reach the directory may create, replace, or delete files. | Broad access persists unless manually removed. | Hard to audit and exposes the site to unrelated users and a compromised web process. Do not use it as a fix. |
The deploy-user-plus-group layout is usually the easiest to maintain. Use an ACL when changing the main group would affect other workflows or when only one service needs an exception.
Apply a deploy-user and web-group layout
The following sequence is a concrete baseline. Replace deploy, www-data, and /var/www/example with the accounts and path on your host. Review the path before running recursive commands; ownership changes affect the entire tree.
- Assign the site to the deployment owner and web group.
sudo chown -R deploy:www-data /var/www/exampleThis makes the deploy account the owner while allowing the web service to use group permissions. If your service runs as
apache, use that group instead. - Set directory and regular-file modes separately.
sudo find /var/www/example -type d -exec chmod 2755 {} + sudo find /var/www/example -type f -exec chmod 644 {} +The leading
2sets the setgid bit on directories, while755gives the owner full access and read/execute access to group and other. Regular files receive644, so they are not accidentally executable. Applyingchmod -R 755would mark ordinary files executable; applyingchmod -R 644would remove directory traversal and break access. - Open only the upload directory for group writing.
sudo chmod 2775 /var/www/example/uploadsHere
775gives the owner and group read, write, and execute rights, and the leading2preserves setgid so newly created entries normally use the directory’s group. If the application also writes a cache, temporary directory, or generated media directory, grant the same treatment only to those named directories, not to the whole document root.Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy. - Test as the service account, then remove the test file.
sudo -u www-data touch /var/www/example/uploads/.perm-test sudo -u www-data rm /var/www/example/uploads/.perm-testIf both commands succeed, retry the application upload. If they fail, return to
namei -landgetfacl; the effective path or ACL still needs attention.
Setgid inheritance is not a promise that every filesystem and mount configuration will behave identically. Confirm the result after a real test by checking the new file’s group with stat or ls -l, rather than assuming it inherited the expected group.
Use an ACL when ownership should not change
If another account must remain the owner, grant the service account a narrowly scoped ACL on the upload directory:
sudo setfacl -m u:www-data:rwx /var/www/example/uploads
sudo setfacl -d -m u:www-data:rwx /var/www/example/uploads
getfacl -p /var/www/example/uploadsThe first command grants the current service account read, write, and execute access to that directory. The second adds a default ACL so newly created children can inherit an entry for the service account. A default ACL also has a mask and base entries; inspect the complete result with getfacl and adjust the mask or default group/other entries if they are broader than your policy. Apply the same ACL to each additional directory the application must write, not to /var/www indiscriminately.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →ACLs are easy to overlook during later troubleshooting because ls -l shows only a summary (often a + after the mode). Always include getfacl when an apparent owner/group fix has no effect. The Debian Handbook’s rights-management guidance covers the relationship between traditional modes and ACLs.
Rank #4
If you cannot change the owner
When policy prevents a recursive chown, add the service account to the existing owning group through your system’s account-management procedure, then make only the required upload directory group-writable. Re-run id for the service account (or restart the service so it receives updated supplementary groups) and verify the directory’s group and mode. Do not make the entire site world-writable merely to avoid an ownership decision.
An ACL is the alternative when adding group membership is undesirable. It leaves the principal owner and group intact while recording exactly which service account receives access. Keep the ACL limited to the upload, cache, or other generated-content directories and document it so a later administrator does not remove it accidentally.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Fix the common failure modes
The target directory looks writable, but the upload still fails
Inspect every parent with namei -l. A missing execute/search bit on /var/www or the site directory blocks traversal even if uploads itself shows rwx. Correct the parent permission for the required owner or group, then repeat the service-account test.
The SSH test works but the application test fails
Your SSH account and the web worker are different identities. Confirm the configured service account in the web-server or application configuration, then use sudo -u with that exact account. On Debian and Ubuntu it is commonly www-data; other distributions may use apache or another dedicated user.
A recursive mode change broke the site
Directory and file modes are not interchangeable. Restore directories with traversal permission and regular files with non-executable modes, using separate find -type d and find -type f operations. Reapply group write only to directories that genuinely need it.
Best Value
chown itself returns an error
chown can fail with EACCES, EPERM, or EROFS. The Linux chown(2) documentation notes causes including insufficient privilege, a read-only filesystem, immutable or append-only attributes, and NFS UID mapping. Resolve the underlying filesystem or identity issue before attempting more permission changes. If the filesystem maps numeric IDs differently over NFS, an apparently matching username may not represent the same owner on the server.
New files receive an unexpected group
Setgid usually causes group inheritance on directories, but filesystem and mount behavior can affect the result. Create a harmless test file as the service account and inspect its owner and group with stat. If the group is wrong, verify the setgid bit, the effective service identity, ACL defaults, and the filesystem’s documented behavior instead of widening permissions.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problemsAn ACL appears to be ignored
Run getfacl -p on the directory and its parents. Check the ACL mask as well as the named-user entry: a restrictive mask can limit the effective rights displayed for www-data. Also confirm that the request is handled by the account to which the ACL was granted.
Keep uploads safe after the fix
- Grant write access only to directories that must receive generated or uploaded content; keep application code and configuration owned by the deploy account and non-writable by the web process where practical.
- Use setgid or default ACLs deliberately, then verify the owner and group of newly created files.
- Record any ACL exception and periodically inspect it with
getfacl. - Retain the service-account create-and-remove test as a diagnostic, but remove the test file immediately.
- Never treat
chmod 777as a routine repair. It gives every local user and compromised process write access and hides whether the real problem was ownership, traversal, an ACL, or the wrong service identity. The troubleshooting guidance at CubePath likewise recommends diagnosing the path before changing modes.
For mode syntax and special bits such as setgid, see the GNU Coreutils mode-structure documentation.
Quick Recap
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.
