Linux File Permissions (644, 755, 777) Explained for Shared Hosting and VPS

If you run a website on Linux-based shared hosting or a VPS, file permissions are one of those topics that seem minor… until something breaks or gets hacked. A single wrong setting like 777 on the wrong folder can turn your hosting account into an easy target, while overly strict permissions can cause white screens, 500 errors, or broken uploads. In daily support at dchost.com, we constantly see the same pattern: developers or site owners trying to quickly fix a problem by making everything writable, and unintentionally opening a big security hole. The good news is that you do not need to be a Linux guru to get this right. Once you understand what 644, 755 and 777 actually mean, and how ownership works on shared hosting versus a VPS, secure configuration becomes straightforward. In this article, we will walk through how Linux permissions work, how to choose safe defaults for typical web apps like WordPress and Laravel, and how to fix ownership and permission problems without breaking your site.

Why Linux File Permissions Matter on Hosting Accounts

On your local computer, wrong file permissions usually cause small annoyances. On a shared hosting or VPS server, they are a core security control and directly affect:

• Who can read your application code (database passwords, API keys, business logic)
• Who can modify your files (inject malware, backdoors, phishing pages)
• Which processes can execute scripts (PHP, shell scripts, binaries)

On shared hosting, many customers share the same physical server. The hosting provider isolates accounts at the OS and web server level, but your own file permissions are still the last line of defense against another compromised account, buggy plugin, or insecure script running under your user.

On a VPS, you usually have full root access. That gives you flexibility, but also full responsibility: if you misconfigure ownership or set 777 on critical paths, an attacker who gets in via one app can jump to others or escalate privileges.

If you want a broader picture of how web hosting layers fit together (domain, DNS, server and SSL), you can also read our guide on how web hosting, domain, DNS and SSL work together. File permissions sit right inside that stack, at the application and OS level, and they are just as important as your SSL or firewall.

How Linux File Permissions Work: User, Group, Others

Linux permissions revolve around three questions:

• Who is trying to access this file? (user, group, others)
• What kind of access are they asking for? (read, write, execute)
• Does the permission allow it? (yes/no)

User, Group and Others

Every file and folder in Linux has an owner user and an owner group. When a process (like PHP-FPM or Apache) tries to access the file, Linux checks permissions in this order:

1. If the process runs as the owner user, use the user permissions.
2. Else if the process belongs to the owner group, use the group permissions.
3. Otherwise, use the others permissions (everyone else on the system).

On shared hosting, your account files are typically owned by a user like username:username, and the web server/ PHP process runs as that same user or a tightly bound group. On a VPS you might see ownerships like deploy:www-data or root:nginx, depending on your design.

Read, Write, Execute and the Numbers 4, 2, 1

Each of user, group and others get a combination of three basic permissions:

• r (read = 4) – can view file content or list directory contents
• w (write = 2) – can modify file content or create/delete files in a directory
• x (execute = 1) – can run a file as a program; for directories, can enter and traverse

The numeric permission you see (like 644 or 755) is just the sum of these values:

• 7 = 4 + 2 + 1 = rwx (read, write, execute)
• 6 = 4 + 2 = rw- (read, write)
• 5 = 4 + 1 = r-x (read, execute)
• 4 = 4 = r– (read only)

So a three-digit permission like 755 means:

• User: 7 → rwx
• Group: 5 → r-x
• Others: 5 → r-x

Remember one key point for web hosting: directories need execute (x) to be enterable. Without x, PHP or the web server cannot traverse into the directory to serve files, even if read permission is present.

Understanding 644, 755 and 777 in Real Hosting Scenarios

Now let’s translate the three most common modes into everyday web hosting use cases.

What 644 Really Means

644 breaks down as:

• User: 6 → rw- (read + write)
• Group: 4 → r– (read only)
• Others: 4 → r– (read only)

In text form, that’s: owner can read and write; everyone else can only read.

This is the classic permission for normal web files such as:

• PHP files (except very sensitive ones)
• HTML, CSS, JS files
• Public images and assets

On a typical shared hosting account, if your PHP code and static assets use 644, your site will work fine and the web server (running as your user) can read these files, but random users on the system cannot modify them.

To apply it on a file from SSH:

chmod 644 index.php

What 755 Really Means

755 is:

• User: 7 → rwx (read + write + execute)
• Group: 5 → r-x (read + execute)
• Others: 5 → r-x (read + execute)

Here, the owner can do everything; others can read and enter/execute.

This is the default for directories in web hosting, especially:

• public_html or www root
• Subdirectories like wp-content, themes, plugins
• Laravel public, storage (with group tweaking), bootstrap/cache

Directories need execute (x) so the web server and PHP can traverse into them. Without x, your site will show 403 or 500 errors because the server cannot enter the directory even though it can read the files.

Example command:

chmod 755 public_html

What 777 Really Means (and Why It’s Dangerous)

777 is:

• User: 7 → rwx
• Group: 7 → rwx
• Others: 7 → rwx

In words: anyone can read, write and execute.

This is extremely dangerous on shared hosting, because it makes the directory or file world-writable. If another account on the same server gets compromised, malware or a malicious user could potentially write into your directories that are set to 777, planting backdoors or changing your code.

Even on a VPS, 777 is almost never necessary for web apps if ownership and groups are configured properly. The correct solution is usually:

• Fixing ownership (who owns the files), not just permissions
• Using a shared group for web server and app user (e.g. deploy:www-data)
• Using 770 or 750 where needed instead of 777

There are very narrow cases where 777 might be used temporarily inside an isolated container or local dev environment, but for anything on public internet hosting, the safe rule is: avoid 777. If you find yourself tempted to use it to “make uploads work”, it’s a sign to fix user/group ownership instead.

Ownership on Shared Hosting vs VPS: Who Should Own Your Files?

Permissions only make sense if ownership is correct. A secure setup answers two questions clearly:

• Which user owns the application code?
• Which user or group does the web server/PHP run as?

Shared Hosting: Usually Simple, but Easy to Break

On shared hosting plans at dchost.com, we make sure your files are owned by your account user, and the web server/PHP engine runs in a way that respects that isolation. Typical ownership looks like:

username:username  public_html/index.php

If you upload via cPanel/DirectAdmin File Manager or SFTP using your main account, ownership stays correct automatically. Problems usually appear when:

• You restore a backup taken from another server with different users
• You change ownership manually with chown from SSH (and set wrong users)
• You mix files created by scripts running as different users (on misconfigured setups elsewhere)

On our shared hosting, you generally do not need to touch chown at all. Focus on using 755 for directories and 644 for files, and let the panel manage ownership.

VPS: You Design the Model

On a VPS, you or your admin decide the model. A common, secure pattern is:

• Create a deploy or app user (e.g. deploy)
• Use a web server group (e.g. www-data for Nginx/Apache on Debian/Ubuntu, nginx or apache on other distros)
• Set ownership like deploy:www-data on application directories

Then you can use permissions like:

• Directories: 775 (user and group can write; others read/execute only if needed)
• Writable directories (cache, logs, uploads): 770 or 775, with web server in the group
• Sensitive config files: 640 or 600 (readable by user, and maybe by group)

If you are setting up a new VPS and not sure where to start, our guide on the first 24 hours on a new VPS (updates, firewall and users) is a great companion to this article.

Safe Default Permissions for Typical Web Applications

Let’s turn these concepts into practical defaults you can apply right away.

General Web Root Recommendations

For most PHP-based websites (custom PHP, WordPress, small CMSs) on shared hosting or a basic VPS, these defaults work very well:

• All directories: 755
• All normal files: 644
• Executable scripts (rare): 755 (if truly needed)
• Private configuration files: 600 or 640

You can roughly achieve this from the web root with:

find . -type d -exec chmod 755 {} ;
find . -type f -exec chmod 644 {} ;

Run these carefully and preferably on a staging copy first. On shared hosting, File Manager in your control panel offers a graphical way to apply similar recursive changes.

Example: WordPress on Shared Hosting

WordPress is often where people are tempted to use 777 when plugins or themes cannot write files. In almost every case, the correct setup is instead:

• public_html, wp-admin, wp-includes, wp-content → 755
• All .php, .js, .css, template files → 644
• wp-config.php → 600 or 640
• wp-content/uploads and its subdirectories → 755 directories, 644 files

If a plugin cannot create directories or upload files with this configuration, it’s usually a symptom of:

• Wrong ownership (files not owned by your account user)
• Third-party security plugin or WAF blocking the action
• Disk quota or inode limits reached

For a deeper, WordPress-specific perspective on securing file permissions, XML-RPC, and more, our WordPress hardening checklist goes step by step through a production-ready setup.

Example: Laravel or Custom PHP App on a VPS

On a VPS, modern frameworks like Laravel have a few directories that must be writable by the web server (or queue worker):

• storage/ (logs, cache, sessions)
• bootstrap/cache/
• Sometimes public/uploads or similar

A typical secure pattern (with owner deploy, group www-data) looks like:

• Application code: chown -R deploy:www-data /var/www/app
• Code directories and files: directories 755, files 644
• Writable dirs: chmod -R 770 storage bootstrap/cache
• .env file: chmod 600 .env

Here, only the deploy user and web server group can write to storage and cache, and nothing is left world-writable. For a full Laravel production tune-up, including PHP-FPM and OPcache, our detailed guide on Laravel production optimization is a useful next step.

How to Inspect and Change Permissions Safely

Knowing the theory is one thing; actually fixing a broken site with wrong permissions is another. Here’s a practical workflow you can reuse.

Step 1: Inspect with ls -l

From SSH, navigate to your web root and run:

cd public_html
ls -l

You’ll see output like:

-rw-r--r-- 1 username username  1234 Jan  1 12:00 index.php
drwxr-xr-x 5 username username  4096 Jan  1 12:00 wp-content

Breakdown of the columns:

• First column: type and permissions (e.g. -rw-r--r--)
• Third column: owner user (e.g. username)
• Fourth column: owner group (e.g. username)

Convert permissions to numbers mentally:

• -rw-r--r-- → 644
• drwxr-xr-x → 755

Step 2: Fix Ownership (if Needed)

On shared hosting, talk to support if you suspect ownership problems; we can re-align ownership safely across your account.

On a VPS (as root), you can fix ownership with:

chown -R deploy:www-data /var/www/app

Be extremely careful with -R (recursive). Make sure you are in the right directory and using the right user and group, otherwise you might break system files.

Step 3: Apply Safe Defaults with find

On SSH, once ownership is correct, you can use find to reset directories and files:

# From inside your web root
find . -type d -exec chmod 755 {} ;
find . -type f -exec chmod 644 {} ;

Then handle special cases:

• Set wp-config.php or .env stricter (600 or 640)
• Set writable dirs like storage to 770 or 775 if needed

Changing Permissions from a Control Panel

If you do not use SSH, cPanel and DirectAdmin file managers allow you to:

• Right-click a file or folder
• Choose “Permissions” or “Change Permissions”
• Tick boxes for read/write/execute for user, group, others

Be careful with “apply to all files and subdirectories” options. Make sure you apply 755 only to directories and 644 only to files. When in doubt, do it step-by-step instead of one large recursive change.

If your panel access itself needs hardening (IP blocks, 2FA, brute-force protection), our cPanel security hardening checklist covers the most important settings to review.

Common Permission Mistakes We See (and How to Avoid Them)

1. Recursively Setting 777 on public_html

This is the most dangerous quick fix. It might temporarily make uploads work, but it also:

• Makes all your code, themes, plugins and config world-writable
• Lets any exploited script modify any part of your app
• Often survives migrations because people forget to fix it later

Instead of 777, fix ownership so that your web server runs as the same user or group that owns writable directories. Use 755/644 as defaults, and 770/775 only where write access is truly required.

2. Making Config Files World-Readable

Files like wp-config.php, .env, database config, or backup scripts often store:

• Database names, users and passwords
• API keys and secrets
• Mail server credentials

Leaving them with broad permissions like 644 is acceptable on tightly isolated shared hosting, but on a VPS with many users or services, it is safer to use 600 or 640. Combined with correct ownership, this prevents other users or low-privilege processes from dumping your secrets.

3. Leaving Backup Archives in public_html

Another subtle risk: leaving .zip or .sql backups in your web root with 644 permissions. If someone guesses the URL (or if a search engine indexes it before you notice), they can download your entire source code and database.

Better practices:

• Store backups outside the web root
• Or protect backup URLs with authentication and random names
• Use offsite backups (object storage, remote VPS) with encryption

We explain broader backup strategy and retention policies in our guide on how to design a backup strategy with RPO/RTO in mind.

4. Mixing Root-Owned and User-Owned Files

On a VPS, it’s easy to accidentally create files as root inside your web root (for example, by editing via sudo nano or deploying with a root-only script). Afterwards, your deploy user or web server may not be able to modify or delete those files.

To avoid this:

• Do not develop or deploy as root inside app directories
• Use a dedicated deploy user for Git pulls, Composer installs, etc.
• After changes, run chown -R deploy:www-data /var/www/app once, not on every request

Beyond Permissions: Other Security Layers You Should Not Ignore

Even perfectly set 644/755 permissions are only one part of a secure hosting stack. To protect your site end-to-end, combine them with:

1. Secure File Transfer (Use SFTP Instead of FTP)

FTP sends your credentials and data in clear text, which can be intercepted on insecure networks. SFTP (SSH File Transfer Protocol) encrypts everything, and lets you manage permissions and ownership safely from the same SSH account.

If you are still on plain FTP, we strongly recommend switching. Our step-by-step article on moving from FTP to SFTP for secure file transfer walks through the migration on both shared hosting and VPS environments.

2. Application-Level Hardening

Even with good permissions, vulnerable plugins, themes or outdated frameworks can be exploited. Combine OS-level hygiene with:

• Regular updates of CMS, themes, plugins and libraries
• Web Application Firewall (WAF) rules for common attack patterns
• Strong admin passwords and multi-factor authentication

Our guide on WordPress security on shared hosting shows a practical combination of plugins, WAF and backups that works well for most small to medium sites.

3. Server-Level Hardening and Monitoring on VPS

If you manage your own VPS, do not stop at permissions. Review:

• SSH hardening (key-based auth, non-default ports, Fail2ban)
• Firewall rules (UFW, nftables, or other)
• Regular updates and security patches
• Basic monitoring and alerts for CPU, RAM, disk and HTTP errors

We have a practical checklist on how to secure a VPS server without drama that fits nicely alongside the permission and ownership best practices described in this article.

Wrapping Up: A Simple, Safe Rulebook for 644, 755 and 777

Once you understand how Linux evaluates user, group and others, the famous numbers 644, 755 and 777 become much less mysterious. For most websites on shared hosting and VPS, you can follow a small rulebook:

• Directories: 755 (or 750/770 on VPS with a shared app/webserver group)
• Normal files: 644
• Secrets (.env, wp-config.php): 600 or 640
• Writable app directories (cache, logs, uploads): 770/775 with correct group ownership
• Avoid 777 in production; fix ownership instead

On dchost.com shared hosting and VPS plans, we configure sensible defaults out of the box, but as you install CMSs, frameworks and plugins, it is still crucial to keep an eye on how permissions evolve over time. Whenever you restore backups, migrate between servers, or change panels, take a minute to run ls -l, confirm ownership and reset permissions to the safe baseline.

If you would like an environment where these best practices are easier to maintain, our Linux-based shared hosting, VPS, dedicated server and colocation options are designed with security and isolation in mind. You can start small on shared hosting, move to a VPS when you need more control, and keep using the same simple permission model you learned here. And if you are unsure whether a particular directory really needs write access or not, our support team at dchost.com is always happy to review your setup and suggest the safest option that keeps your site working smoothly.