{"id":3391,"date":"2025-12-26T15:34:35","date_gmt":"2025-12-26T12:34:35","guid":{"rendered":"https:\/\/www.dchost.com\/blog\/linux-file-permissions-644-755-777-explained-for-shared-hosting-and-vps\/"},"modified":"2025-12-26T15:34:35","modified_gmt":"2025-12-26T12:34:35","slug":"linux-file-permissions-644-755-777-explained-for-shared-hosting-and-vps","status":"publish","type":"post","link":"https:\/\/www.dchost.com\/blog\/en\/linux-file-permissions-644-755-777-explained-for-shared-hosting-and-vps\/","title":{"rendered":"Linux File Permissions (644, 755, 777) Explained for Shared Hosting and VPS"},"content":{"rendered":"<div class=\"dchost-blog-content-wrapper\"><p>If you run a website on Linux-based shared hosting or a <a href=\"https:\/\/www.dchost.com\/vps\">VPS<\/a>, file permissions are one of those topics that seem minor\u2026 until something breaks or gets hacked. A single wrong setting like <strong>777<\/strong> 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 <strong>644, 755 and 777<\/strong> 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.<\/p>\n<div id=\"toc_container\" class=\"toc_transparent no_bullets\"><p class=\"toc_title\">\u0130&ccedil;indekiler<\/p><ul class=\"toc_list\"><li><a href=\"#Why_Linux_File_Permissions_Matter_on_Hosting_Accounts\"><span class=\"toc_number toc_depth_1\">1<\/span> Why Linux File Permissions Matter on Hosting Accounts<\/a><\/li><li><a href=\"#How_Linux_File_Permissions_Work_User_Group_Others\"><span class=\"toc_number toc_depth_1\">2<\/span> How Linux File Permissions Work: User, Group, Others<\/a><ul><li><a href=\"#User_Group_and_Others\"><span class=\"toc_number toc_depth_2\">2.1<\/span> User, Group and Others<\/a><\/li><li><a href=\"#Read_Write_Execute_and_the_Numbers_4_2_1\"><span class=\"toc_number toc_depth_2\">2.2<\/span> Read, Write, Execute and the Numbers 4, 2, 1<\/a><\/li><\/ul><\/li><li><a href=\"#Understanding_644_755_and_777_in_Real_Hosting_Scenarios\"><span class=\"toc_number toc_depth_1\">3<\/span> Understanding 644, 755 and 777 in Real Hosting Scenarios<\/a><ul><li><a href=\"#What_644_Really_Means\"><span class=\"toc_number toc_depth_2\">3.1<\/span> What 644 Really Means<\/a><\/li><li><a href=\"#What_755_Really_Means\"><span class=\"toc_number toc_depth_2\">3.2<\/span> What 755 Really Means<\/a><\/li><li><a href=\"#What_777_Really_Means_and_Why_Its_Dangerous\"><span class=\"toc_number toc_depth_2\">3.3<\/span> What 777 Really Means (and Why It\u2019s Dangerous)<\/a><\/li><\/ul><\/li><li><a href=\"#Ownership_on_Shared_Hosting_vs_VPS_Who_Should_Own_Your_Files\"><span class=\"toc_number toc_depth_1\">4<\/span> Ownership on Shared Hosting vs VPS: Who Should Own Your Files?<\/a><ul><li><a href=\"#Shared_Hosting_Usually_Simple_but_Easy_to_Break\"><span class=\"toc_number toc_depth_2\">4.1<\/span> Shared Hosting: Usually Simple, but Easy to Break<\/a><\/li><li><a href=\"#VPS_You_Design_the_Model\"><span class=\"toc_number toc_depth_2\">4.2<\/span> VPS: You Design the Model<\/a><\/li><\/ul><\/li><li><a href=\"#Safe_Default_Permissions_for_Typical_Web_Applications\"><span class=\"toc_number toc_depth_1\">5<\/span> Safe Default Permissions for Typical Web Applications<\/a><ul><li><a href=\"#General_Web_Root_Recommendations\"><span class=\"toc_number toc_depth_2\">5.1<\/span> General Web Root Recommendations<\/a><\/li><li><a href=\"#Example_WordPress_on_Shared_Hosting\"><span class=\"toc_number toc_depth_2\">5.2<\/span> Example: WordPress on Shared Hosting<\/a><\/li><li><a href=\"#Example_Laravel_or_Custom_PHP_App_on_a_VPS\"><span class=\"toc_number toc_depth_2\">5.3<\/span> Example: Laravel or Custom PHP App on a VPS<\/a><\/li><\/ul><\/li><li><a href=\"#How_to_Inspect_and_Change_Permissions_Safely\"><span class=\"toc_number toc_depth_1\">6<\/span> How to Inspect and Change Permissions Safely<\/a><ul><li><a href=\"#Step_1_Inspect_with_ls_-l\"><span class=\"toc_number toc_depth_2\">6.1<\/span> Step 1: Inspect with ls -l<\/a><\/li><li><a href=\"#Step_2_Fix_Ownership_if_Needed\"><span class=\"toc_number toc_depth_2\">6.2<\/span> Step 2: Fix Ownership (if Needed)<\/a><\/li><li><a href=\"#Step_3_Apply_Safe_Defaults_with_find\"><span class=\"toc_number toc_depth_2\">6.3<\/span> Step 3: Apply Safe Defaults with find<\/a><\/li><li><a href=\"#Changing_Permissions_from_a_Control_Panel\"><span class=\"toc_number toc_depth_2\">6.4<\/span> Changing Permissions from a Control Panel<\/a><\/li><\/ul><\/li><li><a href=\"#Common_Permission_Mistakes_We_See_and_How_to_Avoid_Them\"><span class=\"toc_number toc_depth_1\">7<\/span> Common Permission Mistakes We See (and How to Avoid Them)<\/a><ul><li><a href=\"#1_Recursively_Setting_777_on_public_html\"><span class=\"toc_number toc_depth_2\">7.1<\/span> 1. Recursively Setting 777 on public_html<\/a><\/li><li><a href=\"#2_Making_Config_Files_World-Readable\"><span class=\"toc_number toc_depth_2\">7.2<\/span> 2. Making Config Files World-Readable<\/a><\/li><li><a href=\"#3_Leaving_Backup_Archives_in_public_html\"><span class=\"toc_number toc_depth_2\">7.3<\/span> 3. Leaving Backup Archives in public_html<\/a><\/li><li><a href=\"#4_Mixing_Root-Owned_and_User-Owned_Files\"><span class=\"toc_number toc_depth_2\">7.4<\/span> 4. Mixing Root-Owned and User-Owned Files<\/a><\/li><\/ul><\/li><li><a href=\"#Beyond_Permissions_Other_Security_Layers_You_Should_Not_Ignore\"><span class=\"toc_number toc_depth_1\">8<\/span> Beyond Permissions: Other Security Layers You Should Not Ignore<\/a><ul><li><a href=\"#1_Secure_File_Transfer_Use_SFTP_Instead_of_FTP\"><span class=\"toc_number toc_depth_2\">8.1<\/span> 1. Secure File Transfer (Use SFTP Instead of FTP)<\/a><\/li><li><a href=\"#2_Application-Level_Hardening\"><span class=\"toc_number toc_depth_2\">8.2<\/span> 2. Application-Level Hardening<\/a><\/li><li><a href=\"#3_Server-Level_Hardening_and_Monitoring_on_VPS\"><span class=\"toc_number toc_depth_2\">8.3<\/span> 3. Server-Level Hardening and Monitoring on VPS<\/a><\/li><\/ul><\/li><li><a href=\"#Wrapping_Up_A_Simple_Safe_Rulebook_for_644_755_and_777\"><span class=\"toc_number toc_depth_1\">9<\/span> Wrapping Up: A Simple, Safe Rulebook for 644, 755 and 777<\/a><\/li><\/ul><\/div>\n<h2><span id=\"Why_Linux_File_Permissions_Matter_on_Hosting_Accounts\">Why Linux File Permissions Matter on Hosting Accounts<\/span><\/h2>\n<p>On your local computer, wrong file permissions usually cause small annoyances. On a shared hosting or VPS server, they are a <strong>core security control<\/strong> and directly affect:<\/p>\n<ul>\n<li><strong>Who can read your application code<\/strong> (database passwords, API keys, business logic)<\/li>\n<li><strong>Who can modify your files<\/strong> (inject malware, backdoors, phishing pages)<\/li>\n<li><strong>Which processes can execute scripts<\/strong> (PHP, shell scripts, binaries)<\/li>\n<\/ul>\n<p>On <strong>shared hosting<\/strong>, 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.<\/p>\n<p>On a <strong>VPS<\/strong>, 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.<\/p>\n<p>If you want a broader picture of how <a href=\"https:\/\/www.dchost.com\/web-hosting\">web hosting<\/a> layers fit together (domain, DNS, server and SSL), you can also read our guide <a href=\"https:\/\/www.dchost.com\/blog\/en\/web-hosting-nedir-domain-dns-sunucu-ve-ssl-nasil-birlikte-calisir\/\">on how web hosting, domain, DNS and SSL work together<\/a>. File permissions sit right inside that stack, at the application and OS level, and they are just as important as your SSL or firewall.<\/p>\n<h2><span id=\"How_Linux_File_Permissions_Work_User_Group_Others\">How Linux File Permissions Work: User, Group, Others<\/span><\/h2>\n<p>Linux permissions revolve around three questions:<\/p>\n<ul>\n<li><strong>Who<\/strong> is trying to access this file? (user, group, others)<\/li>\n<li><strong>What kind<\/strong> of access are they asking for? (read, write, execute)<\/li>\n<li><strong>Does the permission allow it?<\/strong> (yes\/no)<\/li>\n<\/ul>\n<h3><span id=\"User_Group_and_Others\">User, Group and Others<\/span><\/h3>\n<p>Every file and folder in Linux has an <strong>owner user<\/strong> and an <strong>owner group<\/strong>. When a process (like PHP-FPM or Apache) tries to access the file, Linux checks permissions in this order:<\/p>\n<ol>\n<li>If the process runs as the <strong>owner user<\/strong>, use the <strong>user<\/strong> permissions.<\/li>\n<li>Else if the process belongs to the <strong>owner group<\/strong>, use the <strong>group<\/strong> permissions.<\/li>\n<li>Otherwise, use the <strong>others<\/strong> permissions (everyone else on the system).<\/li>\n<\/ol>\n<p>On shared hosting, your account files are typically owned by a user like <code>username:username<\/code>, and the web server\/ PHP process runs as that same user or a tightly bound group. On a VPS you might see ownerships like <code>deploy:www-data<\/code> or <code>root:nginx<\/code>, depending on your design.<\/p>\n<h3><span id=\"Read_Write_Execute_and_the_Numbers_4_2_1\">Read, Write, Execute and the Numbers 4, 2, 1<\/span><\/h3>\n<p>Each of user, group and others get a combination of three basic permissions:<\/p>\n<ul>\n<li><strong>r (read = 4)<\/strong> \u2013 can view file content or list directory contents<\/li>\n<li><strong>w (write = 2)<\/strong> \u2013 can modify file content or create\/delete files in a directory<\/li>\n<li><strong>x (execute = 1)<\/strong> \u2013 can run a file as a program; for directories, can enter and traverse<\/li>\n<\/ul>\n<p>The numeric permission you see (like 644 or 755) is just the sum of these values:<\/p>\n<ul>\n<li><strong>7<\/strong> = 4 + 2 + 1 = <strong>rwx<\/strong> (read, write, execute)<\/li>\n<li><strong>6<\/strong> = 4 + 2 = <strong>rw-<\/strong> (read, write)<\/li>\n<li><strong>5<\/strong> = 4 + 1 = <strong>r-x<\/strong> (read, execute)<\/li>\n<li><strong>4<\/strong> = 4 = <strong>r&#8211;<\/strong> (read only)<\/li>\n<\/ul>\n<p>So a three-digit permission like <strong>755<\/strong> means:<\/p>\n<ul>\n<li>User: 7 \u2192 rwx<\/li>\n<li>Group: 5 \u2192 r-x<\/li>\n<li>Others: 5 \u2192 r-x<\/li>\n<\/ul>\n<p>Remember one key point for web hosting: <strong>directories need execute (x) to be enterable<\/strong>. Without <code>x<\/code>, PHP or the web server cannot traverse into the directory to serve files, even if read permission is present.<\/p>\n<h2><span id=\"Understanding_644_755_and_777_in_Real_Hosting_Scenarios\">Understanding 644, 755 and 777 in Real Hosting Scenarios<\/span><\/h2>\n<p>Now let\u2019s translate the three most common modes into everyday web hosting use cases.<\/p>\n<h3><span id=\"What_644_Really_Means\">What 644 Really Means<\/span><\/h3>\n<p><strong>644<\/strong> breaks down as:<\/p>\n<ul>\n<li>User: 6 \u2192 <strong>rw-<\/strong> (read + write)<\/li>\n<li>Group: 4 \u2192 <strong>r&#8211;<\/strong> (read only)<\/li>\n<li>Others: 4 \u2192 <strong>r&#8211;<\/strong> (read only)<\/li>\n<\/ul>\n<p>In text form, that\u2019s: <strong>owner can read and write; everyone else can only read<\/strong>.<\/p>\n<p>This is the classic permission for <strong>normal web files<\/strong> such as:<\/p>\n<ul>\n<li>PHP files (except very sensitive ones)<\/li>\n<li>HTML, CSS, JS files<\/li>\n<li>Public images and assets<\/li>\n<\/ul>\n<p>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.<\/p>\n<p>To apply it on a file from SSH:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">chmod 644 index.php<\/code><\/pre>\n<h3><span id=\"What_755_Really_Means\">What 755 Really Means<\/span><\/h3>\n<p><strong>755<\/strong> is:<\/p>\n<ul>\n<li>User: 7 \u2192 <strong>rwx<\/strong> (read + write + execute)<\/li>\n<li>Group: 5 \u2192 <strong>r-x<\/strong> (read + execute)<\/li>\n<li>Others: 5 \u2192 <strong>r-x<\/strong> (read + execute)<\/li>\n<\/ul>\n<p>Here, the owner can do everything; others can read and enter\/execute.<\/p>\n<p>This is the <strong>default for directories<\/strong> in web hosting, especially:<\/p>\n<ul>\n<li><code>public_html<\/code> or <code>www<\/code> root<\/li>\n<li>Subdirectories like <code>wp-content<\/code>, <code>themes<\/code>, <code>plugins<\/code><\/li>\n<li>Laravel <code>public<\/code>, <code>storage<\/code> (with group tweaking), <code>bootstrap\/cache<\/code><\/li>\n<\/ul>\n<p>Directories need <strong>execute (x)<\/strong> so the web server and PHP can traverse into them. Without <code>x<\/code>, your site will show 403 or 500 errors because the server cannot enter the directory even though it can read the files.<\/p>\n<p>Example command:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">chmod 755 public_html<\/code><\/pre>\n<h3><span id=\"What_777_Really_Means_and_Why_Its_Dangerous\">What 777 Really Means (and Why It\u2019s Dangerous)<\/span><\/h3>\n<p><strong>777<\/strong> is:<\/p>\n<ul>\n<li>User: 7 \u2192 rwx<\/li>\n<li>Group: 7 \u2192 rwx<\/li>\n<li>Others: 7 \u2192 rwx<\/li>\n<\/ul>\n<p>In words: <strong>anyone can read, write and execute<\/strong>.<\/p>\n<p>This is extremely dangerous on <strong>shared hosting<\/strong>, 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.<\/p>\n<p>Even on a <strong>VPS<\/strong>, 777 is almost never necessary for web apps if ownership and groups are configured properly. The correct solution is usually:<\/p>\n<ul>\n<li>Fixing <strong>ownership<\/strong> (who owns the files), not just permissions<\/li>\n<li>Using a shared <strong>group<\/strong> for web server and app user (e.g. <code>deploy:www-data<\/code>)<\/li>\n<li>Using <strong>770<\/strong> or <strong>750<\/strong> where needed instead of 777<\/li>\n<\/ul>\n<p>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: <strong>avoid 777<\/strong>. If you find yourself tempted to use it to &#8220;make uploads work&#8221;, it\u2019s a sign to fix user\/group ownership instead.<\/p>\n<h2><span id=\"Ownership_on_Shared_Hosting_vs_VPS_Who_Should_Own_Your_Files\">Ownership on Shared Hosting vs VPS: Who Should Own Your Files?<\/span><\/h2>\n<p>Permissions only make sense if <strong>ownership<\/strong> is correct. A secure setup answers two questions clearly:<\/p>\n<ul>\n<li>Which user owns the application code?<\/li>\n<li>Which user or group does the web server\/PHP run as?<\/li>\n<\/ul>\n<h3><span id=\"Shared_Hosting_Usually_Simple_but_Easy_to_Break\">Shared Hosting: Usually Simple, but Easy to Break<\/span><\/h3>\n<p>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:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">username:username  public_html\/index.php<\/code><\/pre>\n<p>If you upload via cPanel\/DirectAdmin File Manager or SFTP using your main account, ownership stays correct automatically. Problems usually appear when:<\/p>\n<ul>\n<li>You restore a backup taken from another server with different users<\/li>\n<li>You change ownership manually with <code>chown<\/code> from SSH (and set wrong users)<\/li>\n<li>You mix files created by scripts running as different users (on misconfigured setups elsewhere)<\/li>\n<\/ul>\n<p>On our shared hosting, you generally <strong>do not need<\/strong> to touch <code>chown<\/code> at all. Focus on using 755 for directories and 644 for files, and let the panel manage ownership.<\/p>\n<h3><span id=\"VPS_You_Design_the_Model\">VPS: You Design the Model<\/span><\/h3>\n<p>On a VPS, you or your admin decide the model. A common, secure pattern is:<\/p>\n<ul>\n<li>Create a <strong>deploy or app user<\/strong> (e.g. <code>deploy<\/code>)<\/li>\n<li>Use a <strong>web server group<\/strong> (e.g. <code>www-data<\/code> for Nginx\/Apache on Debian\/Ubuntu, <code>nginx<\/code> or <code>apache<\/code> on other distros)<\/li>\n<li>Set ownership like <code>deploy:www-data<\/code> on application directories<\/li>\n<\/ul>\n<p>Then you can use permissions like:<\/p>\n<ul>\n<li>Directories: <strong>775<\/strong> (user and group can write; others read\/execute only if needed)<\/li>\n<li>Writable directories (cache, logs, uploads): <strong>770<\/strong> or <strong>775<\/strong>, with web server in the group<\/li>\n<li>Sensitive config files: <strong>640<\/strong> or <strong>600<\/strong> (readable by user, and maybe by group)<\/li>\n<\/ul>\n<p>If you are setting up a new VPS and not sure where to start, our guide <a href=\"https:\/\/www.dchost.com\/blog\/en\/yeni-vpste-ilk-24-saat-guncelleme-guvenlik-duvari-ve-kullanici-hesaplari\/\">on the first 24 hours on a new VPS (updates, firewall and users)<\/a> is a great companion to this article.<\/p>\n<h2><span id=\"Safe_Default_Permissions_for_Typical_Web_Applications\">Safe Default Permissions for Typical Web Applications<\/span><\/h2>\n<p>Let\u2019s turn these concepts into practical defaults you can apply right away.<\/p>\n<h3><span id=\"General_Web_Root_Recommendations\">General Web Root Recommendations<\/span><\/h3>\n<p>For most PHP-based websites (custom PHP, WordPress, small CMSs) on shared hosting or a basic VPS, these defaults work very well:<\/p>\n<ul>\n<li><strong>All directories:<\/strong> 755<\/li>\n<li><strong>All normal files:<\/strong> 644<\/li>\n<li><strong>Executable scripts (rare):<\/strong> 755 (if truly needed)<\/li>\n<li><strong>Private configuration files:<\/strong> 600 or 640<\/li>\n<\/ul>\n<p>You can roughly achieve this from the web root with:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">find . -type d -exec chmod 755 {} ;\nfind . -type f -exec chmod 644 {} ;<\/code><\/pre>\n<p>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.<\/p>\n<h3><span id=\"Example_WordPress_on_Shared_Hosting\">Example: WordPress on Shared Hosting<\/span><\/h3>\n<p>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:<\/p>\n<ul>\n<li><code>public_html<\/code>, <code>wp-admin<\/code>, <code>wp-includes<\/code>, <code>wp-content<\/code> \u2192 <strong>755<\/strong><\/li>\n<li>All <code>.php<\/code>, <code>.js<\/code>, <code>.css<\/code>, template files \u2192 <strong>644<\/strong><\/li>\n<li><code>wp-config.php<\/code> \u2192 <strong>600<\/strong> or <strong>640<\/strong><\/li>\n<li><code>wp-content\/uploads<\/code> and its subdirectories \u2192 <strong>755<\/strong> directories, <strong>644<\/strong> files<\/li>\n<\/ul>\n<p>If a plugin cannot create directories or upload files with this configuration, it\u2019s usually a symptom of:<\/p>\n<ul>\n<li>Wrong ownership (files not owned by your account user)<\/li>\n<li>Third-party security plugin or WAF blocking the action<\/li>\n<li>Disk quota or inode limits reached<\/li>\n<\/ul>\n<p>For a deeper, WordPress-specific perspective on securing file permissions, XML-RPC, and more, our <a href=\"https:\/\/www.dchost.com\/blog\/en\/wordpress-guvenlik-sertlestirme-kontrol-listesi-dosya-izinleri-salt-keys-xml-rpc-ufw-fail2ban-nasil-tatli-tatli-kurulur\/\">WordPress hardening checklist<\/a> goes step by step through a production-ready setup.<\/p>\n<h3><span id=\"Example_Laravel_or_Custom_PHP_App_on_a_VPS\">Example: Laravel or Custom PHP App on a VPS<\/span><\/h3>\n<p>On a VPS, modern frameworks like Laravel have a few directories that must be writable by the web server (or queue worker):<\/p>\n<ul>\n<li><code>storage\/<\/code> (logs, cache, sessions)<\/li>\n<li><code>bootstrap\/cache\/<\/code><\/li>\n<li>Sometimes <code>public\/uploads<\/code> or similar<\/li>\n<\/ul>\n<p>A typical secure pattern (with owner <code>deploy<\/code>, group <code>www-data<\/code>) looks like:<\/p>\n<ul>\n<li>Application code: <code>chown -R deploy:www-data \/var\/www\/app<\/code><\/li>\n<li>Code directories and files: directories 755, files 644<\/li>\n<li>Writable dirs: <code>chmod -R 770 storage bootstrap\/cache<\/code><\/li>\n<li><code>.env<\/code> file: <code>chmod 600 .env<\/code><\/li>\n<\/ul>\n<p>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 <a href=\"https:\/\/www.dchost.com\/blog\/en\/laravel-prod-ortam-optimizasyonu-nasil-yapilir-php%e2%80%91fpm-opcache-octane-queue-horizon-ve-redisi-el-ele-calistirmak\/\">on Laravel production optimization<\/a> is a useful next step.<\/p>\n<h2><span id=\"How_to_Inspect_and_Change_Permissions_Safely\">How to Inspect and Change Permissions Safely<\/span><\/h2>\n<p>Knowing the theory is one thing; actually fixing a broken site with wrong permissions is another. Here\u2019s a practical workflow you can reuse.<\/p>\n<h3><span id=\"Step_1_Inspect_with_ls_-l\">Step 1: Inspect with ls -l<\/span><\/h3>\n<p>From SSH, navigate to your web root and run:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">cd public_html\nls -l<\/code><\/pre>\n<p>You\u2019ll see output like:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">-rw-r--r-- 1 username username  1234 Jan  1 12:00 index.php\ndrwxr-xr-x 5 username username  4096 Jan  1 12:00 wp-content<\/code><\/pre>\n<p>Breakdown of the columns:<\/p>\n<ul>\n<li><strong>First column<\/strong>: type and permissions (e.g. <code>-rw-r--r--<\/code>)<\/li>\n<li><strong>Third column<\/strong>: owner user (e.g. <code>username<\/code>)<\/li>\n<li><strong>Fourth column<\/strong>: owner group (e.g. <code>username<\/code>)<\/li>\n<\/ul>\n<p>Convert permissions to numbers mentally:<\/p>\n<ul>\n<li><code>-rw-r--r--<\/code> \u2192 644<\/li>\n<li><code>drwxr-xr-x<\/code> \u2192 755<\/li>\n<\/ul>\n<h3><span id=\"Step_2_Fix_Ownership_if_Needed\">Step 2: Fix Ownership (if Needed)<\/span><\/h3>\n<p>On shared hosting, talk to support if you suspect ownership problems; we can re-align ownership safely across your account.<\/p>\n<p>On a VPS (as root), you can fix ownership with:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">chown -R deploy:www-data \/var\/www\/app<\/code><\/pre>\n<p>Be extremely careful with <code>-R<\/code> (recursive). Make sure you are in the right directory and using the right user and group, otherwise you might break system files.<\/p>\n<h3><span id=\"Step_3_Apply_Safe_Defaults_with_find\">Step 3: Apply Safe Defaults with find<\/span><\/h3>\n<p>On SSH, once ownership is correct, you can use <code>find<\/code> to reset directories and files:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\"># From inside your web root\nfind . -type d -exec chmod 755 {} ;\nfind . -type f -exec chmod 644 {} ;<\/code><\/pre>\n<p>Then handle special cases:<\/p>\n<ul>\n<li>Set <code>wp-config.php<\/code> or <code>.env<\/code> stricter (600 or 640)<\/li>\n<li>Set writable dirs like <code>storage<\/code> to 770 or 775 if needed<\/li>\n<\/ul>\n<h3><span id=\"Changing_Permissions_from_a_Control_Panel\">Changing Permissions from a Control Panel<\/span><\/h3>\n<p>If you do not use SSH, cPanel and DirectAdmin file managers allow you to:<\/p>\n<ul>\n<li>Right-click a file or folder<\/li>\n<li>Choose &#8220;Permissions&#8221; or &#8220;Change Permissions&#8221;<\/li>\n<li>Tick boxes for read\/write\/execute for user, group, others<\/li>\n<\/ul>\n<p>Be careful with &#8220;apply to all files and subdirectories&#8221; 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.<\/p>\n<p>If your panel access itself needs hardening (IP blocks, 2FA, brute-force protection), our <a href=\"https:\/\/www.dchost.com\/blog\/en\/cpanel-guvenlik-sertlestirme-kontrol-listesi\/\">cPanel security hardening checklist<\/a> covers the most important settings to review.<\/p>\n<h2><span id=\"Common_Permission_Mistakes_We_See_and_How_to_Avoid_Them\">Common Permission Mistakes We See (and How to Avoid Them)<\/span><\/h2>\n<h3><span id=\"1_Recursively_Setting_777_on_public_html\">1. Recursively Setting 777 on public_html<\/span><\/h3>\n<p>This is the most dangerous quick fix. It might temporarily make uploads work, but it also:<\/p>\n<ul>\n<li>Makes all your code, themes, plugins and config world-writable<\/li>\n<li>Lets any exploited script modify any part of your app<\/li>\n<li>Often survives migrations because people forget to fix it later<\/li>\n<\/ul>\n<p>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.<\/p>\n<h3><span id=\"2_Making_Config_Files_World-Readable\">2. Making Config Files World-Readable<\/span><\/h3>\n<p>Files like <code>wp-config.php<\/code>, <code>.env<\/code>, database config, or backup scripts often store:<\/p>\n<ul>\n<li>Database names, users and passwords<\/li>\n<li>API keys and secrets<\/li>\n<li>Mail server credentials<\/li>\n<\/ul>\n<p>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.<\/p>\n<h3><span id=\"3_Leaving_Backup_Archives_in_public_html\">3. Leaving Backup Archives in public_html<\/span><\/h3>\n<p>Another subtle risk: leaving <code>.zip<\/code> or <code>.sql<\/code> 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.<\/p>\n<p>Better practices:<\/p>\n<ul>\n<li>Store backups <strong>outside<\/strong> the web root<\/li>\n<li>Or protect backup URLs with authentication and random names<\/li>\n<li>Use offsite backups (object storage, remote VPS) with encryption<\/li>\n<\/ul>\n<p>We explain broader backup strategy and retention policies in our guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/yedekleme-stratejisi-nasil-planlanir-blog-e-ticaret-ve-saas-siteleri-icin-rpo-rto-rehberi\/\">how to design a backup strategy with RPO\/RTO in mind<\/a>.<\/p>\n<h3><span id=\"4_Mixing_Root-Owned_and_User-Owned_Files\">4. Mixing Root-Owned and User-Owned Files<\/span><\/h3>\n<p>On a VPS, it\u2019s easy to accidentally create files as <code>root<\/code> inside your web root (for example, by editing via <code>sudo nano<\/code> or deploying with a root-only script). Afterwards, your deploy user or web server may not be able to modify or delete those files.<\/p>\n<p>To avoid this:<\/p>\n<ul>\n<li>Do not develop or deploy as <code>root<\/code> inside app directories<\/li>\n<li>Use a dedicated deploy user for Git pulls, Composer installs, etc.<\/li>\n<li>After changes, run <code>chown -R deploy:www-data \/var\/www\/app<\/code> once, not on every request<\/li>\n<\/ul>\n<h2><span id=\"Beyond_Permissions_Other_Security_Layers_You_Should_Not_Ignore\">Beyond Permissions: Other Security Layers You Should Not Ignore<\/span><\/h2>\n<p>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:<\/p>\n<h3><span id=\"1_Secure_File_Transfer_Use_SFTP_Instead_of_FTP\">1. Secure File Transfer (Use SFTP Instead of FTP)<\/span><\/h3>\n<p>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.<\/p>\n<p>If you are still on plain FTP, we strongly recommend switching. Our step-by-step article <a href=\"https:\/\/www.dchost.com\/blog\/en\/ftp-yerine-sftp-kullanmanin-zamani-geldi\/\">on moving from FTP to SFTP for secure file transfer<\/a> walks through the migration on both shared hosting and VPS environments.<\/p>\n<h3><span id=\"2_Application-Level_Hardening\">2. Application-Level Hardening<\/span><\/h3>\n<p>Even with good permissions, vulnerable plugins, themes or outdated frameworks can be exploited. Combine OS-level hygiene with:<\/p>\n<ul>\n<li>Regular updates of CMS, themes, plugins and libraries<\/li>\n<li>Web Application Firewall (WAF) rules for common attack patterns<\/li>\n<li>Strong admin passwords and multi-factor authentication<\/li>\n<\/ul>\n<p>Our guide <a href=\"https:\/\/www.dchost.com\/blog\/en\/paylasimli-hostingde-wordpress-guvenligi-eklentiler-waf-2fa-ve-yedekler\/\">on WordPress security on shared hosting<\/a> shows a practical combination of plugins, WAF and backups that works well for most small to medium sites.<\/p>\n<h3><span id=\"3_Server-Level_Hardening_and_Monitoring_on_VPS\">3. Server-Level Hardening and Monitoring on VPS<\/span><\/h3>\n<p>If you manage your own VPS, do not stop at permissions. Review:<\/p>\n<ul>\n<li>SSH hardening (key-based auth, non-default ports, Fail2ban)<\/li>\n<li>Firewall rules (UFW, nftables, or other)<\/li>\n<li>Regular updates and security patches<\/li>\n<li>Basic monitoring and alerts for CPU, RAM, disk and HTTP errors<\/li>\n<\/ul>\n<p>We have a practical checklist on <a href=\"https:\/\/www.dchost.com\/blog\/en\/vps-sunucu-guvenligi-nasil-saglanir-kapiyi-acik-birakmadan-yasamanin-sirri\/\">how to secure a VPS server without drama<\/a> that fits nicely alongside the permission and ownership best practices described in this article.<\/p>\n<h2><span id=\"Wrapping_Up_A_Simple_Safe_Rulebook_for_644_755_and_777\">Wrapping Up: A Simple, Safe Rulebook for 644, 755 and 777<\/span><\/h2>\n<p>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:<\/p>\n<ul>\n<li><strong>Directories:<\/strong> 755 (or 750\/770 on VPS with a shared app\/webserver group)<\/li>\n<li><strong>Normal files:<\/strong> 644<\/li>\n<li><strong>Secrets (.env, wp-config.php):<\/strong> 600 or 640<\/li>\n<li><strong>Writable app directories (cache, logs, uploads):<\/strong> 770\/775 with correct group ownership<\/li>\n<li><strong>Avoid 777<\/strong> in production; fix ownership instead<\/li>\n<\/ul>\n<p>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 <code>ls -l<\/code>, confirm ownership and reset permissions to the safe baseline.<\/p>\n<p>If you would like an environment where these best practices are easier to maintain, our Linux-based shared hosting, VPS, <a href=\"https:\/\/www.dchost.com\/dedicated-server\">dedicated server<\/a> 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.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":"<p>If you run a website on Linux-based shared hosting or a VPS, file permissions are one of those topics that seem minor\u2026 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, [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":3392,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[26],"tags":[],"class_list":["post-3391","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-teknoloji"],"_links":{"self":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/3391","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/comments?post=3391"}],"version-history":[{"count":0,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/3391\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media\/3392"}],"wp:attachment":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media?parent=3391"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/categories?post=3391"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/tags?post=3391"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}