LiveChat 
Support 
How to Change a Directory’s Owner in Linux (chown): A Troubleshooter’s Guide
You deploy an app, point your web server at it, and the logs fill up with the same line over and over: permission denied. You run `chmod 777` in frustration, the error goes away, and you tell yourself you’ll “fix it properly later.” Stop right there. That error almost certainly wasn’t a permissions problem at all. It was an ownership problem, and the real fix is `chown`, not loosening permissions until something gives.
This is the diagnostic guide I wish more people read before they reach for the nuclear option. We’ll cover what ownership actually is, how to change a directory’s owner in Linux, and how to read the symptoms so you isolate the *real* cause instead of papering over it.
Key Takeaways
• Every file and directory in Linux has both an owning user and an owning group — `ls -l` shows both.
• `chown user dir` changes the owner; `chown user:group dir` changes both; `chown :group dir` changes only the group.
• The `-R` flag applies ownership recursively down a whole directory tree — essential for web roots and app directories.
• Most “permission denied” errors on a server are an ownership mismatch, not a permissions one. The process (like `www-data`) doesn’t own the files.
• Always run `ls -l` to diagnose *before* you change anything. Changing owners needs `root`/`sudo`.
What does it mean for a directory to have an “owner”?
In Linux, every file and every directory carries two pieces of identity metadata: a user that owns it and a group that owns it. Together with permissions, this is how the kernel decides who is allowed to do what.
You can see ownership instantly with `ls -l`:
“`bash ls -l /var/www “`
“` drwxr-xr-x 4 www-data www-data 4096 Jun 18 09:22 site drwxr-xr-x 2 root root 4096 May 02 14:10 oldsite “`
Read the columns from left to right. After the permission string (`drwxr-xr-x`) and the link count, the third column is the owning user and the fourth column is the owning group. So `site` is owned by user `www-data` and group `www-data`, while `oldsite` is owned by `root` and group `root`.
That difference is the whole story behind a huge share of server errors. If your web server runs as `www-data` but a directory is owned by `root`, the server may not be able to write to it — and you’ll see permission denied.
The diagnostic habit to build: when something can’t read or write a file, the *first* command you run is `ls -l`, not `chmod`. Look at who owns the thing and ask, “Is this the user my process actually runs as?”
How do you change a directory’s owner with chown?
The tool is `chown` (short for change owner). Its job is to reassign the owning user and/or owning group of a file or directory. Changing ownership is a privileged operation, so you’ll almost always need `sudo`.
The basic forms:
“`bash
sudo chown alice /srv/project
sudo chown alice:developers /srv/project
sudo chown :developers /srv/project “`
Here is the syntax laid out so you can match the form to your goal:
| Command form | What it changes | Example |
|---|---|---|
| `chown user dir` | Owning user only | `sudo chown www-data /var/www/site` |
| `chown user:group dir` | Owning user and group | `sudo chown www-data:www-data /var/www/site` |
| `chown :group dir` | Owning group only | `sudo chown :www-data /var/www/site` |
| `chown -R user:group dir` | User + group, recursively through the whole tree | `sudo chown -R www-data:www-data /var/www/site` |
Notice the `:` separator. `user:group` sets both. A leading colon (`:group`) means “leave the user alone, change only the group.” A trailing form is the same idea in reverse but rarely needed in practice.
Why does the -R recursive flag matter for directories?
When you `chown` a directory without `-R`, you change the owner of *only that directory entry* — not the files and subdirectories inside it. For an empty directory that’s fine. For a web root with hundreds of nested files, it’s almost never what you want.
The `-R` (recursive) flag walks the entire tree and applies the new ownership to every file and subdirectory underneath:
“`bash sudo chown -R www-data:www-data /var/www/site “`
That single command is the backbone of fixing deployment permission issues. After you upload a site, clone a repo, or extract an archive, the files often land owned by whatever user did the upload (frequently `root` or your login user). The web server, running as a *different* user, then can’t write uploads, cache, or session files. Recursive `chown` realigns the whole tree to the user the application actually runs as.
Here’s the insight most tutorials bury: the overwhelming majority of “permission denied” errors on a real server are not permission problems — they’re ownership problems. The file or directory is owned by the wrong user (usually `root`, because that’s who ran the deploy), while the process that needs access runs as a different user (like `www-data` or `nginx`). The correct fix is to *reassign the owner* with `sudo chown -R www-data:www-data /path`, not to loosen permissions with `chmod 777`. Setting `777` “works” only because it grants everyone access, which is exactly why it’s dangerous — you’ve made the directory world-writable to mask a one-line ownership fix. Read `ls -l` first. If the owner is wrong, `chown` is your answer.
When should you actually change ownership?
A few concrete, recurring scenarios where `chown` is the right tool:
- Web server can’t write. Your CMS can’t save uploads or write cache files. `ls -l` shows the directory owned by `root:root` but the server runs as `www-data`. Fix: `sudo chown -R www-data:www-data /var/www/site`.
- Files extracted or copied as root. You ran a deploy script with `sudo`, and now everything is owned by `root`. The app, running as a service user, is locked out.
- A user needs to manage a project directory. You want `alice` to own her project folder so she can edit freely without `sudo`: `sudo chown -R alice:alice /home/alice/project`.
- Moving files between users. Files copied from another account retain the original owner’s UID, which may not even map to a name on the new system.
In every case, the symptom is the same — something can’t read or write — and the diagnosis is the same: check the owner with `ls -l`, compare it to the user the process runs as, and correct the mismatch.
How do ownership and permissions work together?
This trips people up constantly, so let’s be precise. Ownership (`chown`) decides *who* owns a file — which user and group. Permissions (`chmod`) decide *what* the owner, the group, and everyone else are allowed to do — read, write, execute.
They are two halves of the same access-control system. Permissions are meaningless without knowing who the owner is, because the permission bits are applied *relative to* the owner and group. A directory might have perfectly reasonable permissions (`rwxr-xr-x`) and still be unusable by your web server — simply because the web server is neither the owner nor in the owning group, so it falls into the “others” bucket with no write access.
So the troubleshooting order is:
- Run `ls -l`. Identify the current owner and group.
- Identify the user your process runs as (e.g., `www-data` for many web servers).
- If they don’t match, fix ownership with `chown` — this resolves the majority of cases.
- Only then, if access is still wrong, adjust permissions with `chmod`.
For the permissions side of this — what `chmod 644`, `chmod 755`, and the read/write/execute bits actually mean — see our companion guide.
How do you verify the change worked?
Never assume. After any `chown`, run `ls -l` again and confirm the owner and group are now what you expected:
“`bash sudo chown -R www-data:www-data /var/www/site ls -l /var/www “`
“` drwxr-xr-x 4 www-data www-data 4096 Jun 20 11:05 site “`
If you want to verify deep inside the tree (because `-R` should have touched everything), spot-check a nested file:
“`bash ls -l /var/www/site/wp-content/uploads “`
Every entry should now show the new owner. If some files still show the old owner, your `-R` either missed them (wrong path) or you forgot the flag.
A warning about recursive chown on the wrong path
The `-R` flag is powerful, and power cuts both ways. A recursive `chown` on the wrong path can break your system. The classic disaster is a stray space or a wrong target:
“`bash
sudo chown -R www-data:www-data / var/www/site # note the space after / “`
That accidental space tells `chown` to recurse from `/` — the entire filesystem — handing `www-data` ownership of system directories and leaving you with an unbootable mess. Before you run any recursive `chown`:
- Double-check the path. Read it out loud. No stray spaces, no leading slash where you meant a relative path.
- Be specific. Target `/var/www/site`, not `/var` or `/`.
- Run `ls -l` on the target first so you know exactly what you’re about to change.
Hosting with the access to set ownership correctly
Fixing ownership properly requires one thing many environments don’t give you: root access. If you can’t run `sudo chown`, you can’t realign a web root to the user your services run as — you’re stuck working around the problem.
DarazHost gives you that control. Our VPS and dedicated server plans include full root access, so you can set correct ownership on web roots and application directories — `sudo chown -R www-data:www-data /var/www/yoursite` — and let your services read and write exactly as they should, without resorting to insecure `chmod 777` workarounds. Prefer not to touch the command line at all? Our cPanel-based shared hosting manages file ownership for you automatically, so uploads and app directories are owned correctly out of the box. Either way, you get reliable infrastructure and 24/7 support from people who actually understand Linux ownership and permissions — so when you do hit a permission-denied wall, there’s someone to help you isolate the real cause.
Frequently asked questions
Why do I get “Operation not permitted” when I run chown? Changing a file’s owner is a privileged action — only `root` can give a file away to another user. Prefix the command with `sudo` (e.g., `sudo chown www-data:www-data /var/www/site`). If you’re already root and still see this, the file may be on a filesystem mounted read-only or with restrictive options.
What’s the difference between chown and chmod? `chown` changes *who owns* a file (the user and group). `chmod` changes *what those owners are allowed to do* (read, write, execute). They work together: ownership decides which permission bits apply to a given process. If access is wrong, check ownership with `chown` first, then permissions with `chmod`. See our .
Does chown change files inside a directory automatically? No. By default, `chown` changes only the directory entry itself. To change every file and subdirectory inside it, add the `-R` (recursive) flag: `sudo chown -R user:group /path/to/dir`.
My web server still gets permission denied after I ran chmod 777. Why? Because the problem is probably ownership, not permissions. `chmod 777` makes a directory world-writable, but if a parent directory in the path denies access, or if SELinux/AppArmor contexts are wrong, you’ll still be blocked. The cleaner fix is almost always `sudo chown -R www-data:www-data` on the directory — then revert the `777` back to a safe value like `755`.
How do I find out which user my web server runs as? Check the process list (`ps aux | grep nginx` or `ps aux | grep apache`) and look at the user column, or inspect the server config (`user www-data;` in Nginx, `User www-data` in Apache). That user is the one your web directories should typically be owned by.
