{"id":5276,"date":"2026-03-24T14:15:53","date_gmt":"2026-03-24T17:15:53","guid":{"rendered":"https:\/\/awp.agency\/?p=5276"},"modified":"2026-02-25T19:53:35","modified_gmt":"2026-02-25T22:53:35","slug":"how-to-fix-the-error-could-not-access-filesystem-in-wordpress-could-not-access-the-filesystem","status":"publish","type":"post","link":"https:\/\/awp.agency\/en\/blog\/como-solucionar-el-error-could-not-access-filesystem-en-wordpress-no-se-ha-podido-acceder-al-sistema-de-archivos\/","title":{"rendered":"How to fix \u00abCould not access filesystem\u00bb error in WordPress (Could not access filesystem)"},"content":{"rendered":"<div class=\"container\">\n<div class=\"intro\">\n<p>Imagine the situation: You're ready to update your plugins, install a new theme, or perform that critical WordPress core update. You click the update button and, instead of seeing the progress bar, you're met with an annoying popup asking for FTP connection credentials. Or worse, you see the error message: <strong>\u00abThe file system could not be accessed.\u00bb<\/strong> (or in English: <em>Could not access WordPress filesystem<\/em>).<\/p>\n<p>In my experience as a senior WordPress developer, this is one of the most common crashes faced by beginners and intermediate system administrators alike. Although it seems like a complex server issue, the reality is that it boils down to a matter of permissions and security. In this article, I will guide you step-by-step to fix this problem for good, ensuring that you can manage your website without interruption.<\/p>\n<\/div>\n<h2>Why does WordPress ask for FTP credentials? The Root Cause<\/h2>\n<p>Before applying any \u00abpatches\u00bb, it is critical to understand what is going on under the hood. When you see the error \u00abCould not access filesystem WordPress\u00bb, the system is telling you that the PHP script running WordPress does not have the necessary permissions to write or modify files on the server directly.<\/p>\n<p>WordPress has a built-in file abstraction system. When you try to write to the <code>\/wp-content<\/code> (to upload a plugin, for example), performs a security check. It verifies whether the user running the web server (commonly called the <code>www-data<\/code> in Apache\/Nginx) is the same user who owns the files in your installation.<\/p>\n<ul>\n<li><strong>The conflict:<\/strong> If your web server is running under a user (ex. <code>apache<\/code>) and your files belong to another user (e.g. your personal FTP user), WordPress detects a security discrepancy.<\/li>\n<li><strong>Reaction:<\/strong> To avoid modifying files that \u00abdon't belong to you\u00bb, WordPress switches to a secure method and asks you for your FTP credentials to perform the operation as if you were the one uploading the files.<\/li>\n<\/ul>\n<div class=\"critical-note\"><strong>Expert's note:<\/strong> Although entering FTP credentials works temporarily, it does not solve the underlying server configuration problem and significantly slows down the automatic update processes.<\/div>\n<h2>Solution 1: Quick correction with FS_METHOD (Recommended for most)<\/h2>\n<p>For 90% users who are on shared hosting or who need an immediate solution, the most effective way to resolve the \u00abCould not access filesystem WordPress\u00bb error is to define a constant in the global configuration file.<\/p>\n<p>We can instruct WordPress to bypass the strict security check and use the file system directly. This is done by editing the <code>wp-config.php<\/code>.<\/p>\n<h3>Steps to implement FS_METHOD: direct<\/h3>\n<ol>\n<li>Access your website files through an FTP client (such as FileZilla) or through your cPanel's File Manager.<\/li>\n<li>Locate the file <code>wp-config.php<\/code> in the root folder (usually <code>public_html<\/code>).<\/li>\n<li>Download a backup copy of the file (always a good practice).<\/li>\n<li>Edit the file and look for the line that says <code>\/* That's all, stop editing! Happy publishing. *\/<\/code>.<\/li>\n<li>Just above that line, paste the following code:<\/li>\n<\/ol>\n<div class=\"code-block\">\n<pre><code>define('FS_METHOD', 'direct');<\/code><\/pre>\n<\/div>\n<p>By saving and uploading this file back to the server, you are telling WordPress: \u00abI trust the environment, write the files directly without asking for passwords\u00bb.<\/p>\n<div class=\"warning\"><strong>Safety Warning:<\/strong> Use <code>FS_METHOD direct<\/code> on misconfigured servers could allow malicious scripts to modify files. However, on most modern, managed hostings, this configuration is safe and standard.<\/div>\n<p>For more technical details about the configuration constants, you can consult the <a href=\"https:\/\/wordpress.org\/documentation\/article\/editing-wp-config-php\/\" target=\"_blank\" rel=\"noopener noreferrer\">official WordPress documentation on wp-config.php<\/a>.<\/p>\n<h2>Solution 2: Correction of Permissions and Ownership (Chown and Chmod)<\/h2>\n<p>If you manage your own VPS server (DigitalOcean, Linode, AWS) or have SSH access, the above solution is a \u00abbypass\u00bb. The solution <strong>correct<\/strong> and more secure is to fix the ownership of the files to match the web server user.<\/p>\n<p>In my workflow developing high traffic sites, I prefer to ensure that permissions are strict rather than forcing the direct method if the environment allows it. Here's how to do it.<\/p>\n<h3>Identify the web server user<\/h3>\n<p>Generally, on Linux systems (Ubuntu\/Debian) with Apache or Nginx, the user is <code>www-data<\/code>. On CentOS systems it can be <code>apache<\/code>.<\/p>\n<h3>Change owner (Chown)<\/h3>\n<p>Access your terminal via SSH and navigate to the directory where WordPress is installed. Run the following command to assign ownership of all files to the web server:<\/p>\n<div class=\"code-block\">\n<pre><code>sudo chown -R www-data:www-data \/var\/www\/html\/tusitio<\/code><\/pre>\n<\/div>\n<p><em>Be sure to change <code>\/var\/www\/html\/tusitio<\/code> by the actual path of your installation.<\/em><\/p>\n<h3>Correct read\/write permissions (Chmod)<\/h3>\n<p>Once the owner is correct, we must make sure that the directories and files have the proper permissions. The golden rule in WordPress is: <strong>755 for folders and 644 for files<\/strong>.<\/p>\n<p>Execute these commands in your terminal inside the root folder of your site:<\/p>\n<div class=\"code-block\">\n<pre># Change all directories to 755\nsudo find . -type d -exec chmod 755 {} ;\n\n# Change all files to 644\nsudo find . -type f -exec chmod 644 {} {};\n<\/pre>\n<\/div>\n<div class=\"good-practice\"><strong>Good Practice:<\/strong> Never assign 777 permissions (full write to all) to your folders, not even to \u00abtest\u00bb if it fixes the error. This leaves your site completely exposed to hackers.<\/div>\n<h2>Solution 3: FTP\/SSH credentials configuration in wp-config.php<\/h2>\n<p>There are scenarios where your hosting provider has very restrictive security settings that prevent the direct method (`FS_METHOD direct`) and you do not have SSH access to change owners. In these cases, to prevent the popup window from appearing every time, you can hardcode the credentials in the configuration file.<\/p>\n<p>WordPress allows you to define the FTP connection constants directly in <code>wp-config.php<\/code>. In this way, the CMS will use these credentials automatically in the background.<\/p>\n<p>Add the following lines to your file <code>wp-config.php<\/code>:<\/p>\n<div class=\"code-block\">\n<pre>define('FTP_USER', 'your_ftp_user');\ndefine('FTP_PASS', 'your_ftp_password');\ndefine('FTP_HOST', 'ftp.yoursite.com');\ndefine('FTP_SSL', false); \/\/ Set true if your server supports SSL\n<\/pre>\n<\/div>\n<h3>Use of SSH keys (More secure)<\/h3>\n<p>If your server allows it, it is much more secure to use SSH keys instead of plain FTP passwords. WordPress supports this natively:<\/p>\n<div class=\"code-block\">\n<pre>define('FTP_PUBKEY', '\/home\/user\/.ssh\/id_rsa.pub');\ndefine('FTP_PRIKEY', '\/home\/user\/.ssh\/id_rsa');\ndefine('FTP_USER', 'user_ssh');\ndefine('FTP_HOST', '127.0.0.1.1:22');\n<\/pre>\n<\/div>\n<h2>Environment-specific solutions<\/h2>\n<p>The \u00abCould not access filesystem WordPress\u00bb error manifests itself differently depending on where your site is hosted. Here I break down the specifics for local vs. production environments.<\/p>\n<h3>On Localhost (XAMPP, MAMP, Docker)<\/h3>\n<p>It is extremely common to see this error when developing locally, especially on macOS or Linux, due to how these systems handle user permissions versus the user running XAMPP or Docker.<\/p>\n<ul>\n<li><strong>XAMPP\/MAMP:<\/strong> The solution is almost always to use <code>define('FS_METHOD', 'direct');<\/code>. Since it is a local environment, the security risks are minimal. Do not complicate yourself by trying to set up a local FTP server.<\/li>\n<li><strong>Docker:<\/strong> If you use containers, the problem is usually that the mounted volume belongs to your system user (UID 1000) and the container is expecting <code>www-data<\/code> (UID 33). The ideal solution is to configure your <code>Dockerfile<\/code> to adjust the permissions when building the image, or use the direct method in development environment (DEV).<\/li>\n<\/ul>\n<h3>On Shared Hosting (cPanel, Plesk)<\/h3>\n<p>On quality shared hostings (SiteGround, Bluehost, etc.), the server is usually configured with suPHP or FastCGI, which allows PHP scripts to run with the same user as the owner of the files. If you see this error here, it is usually because:<\/p>\n<ol>\n<li>Files were migrated manually and the original permissions were lost.<\/li>\n<li>The hosting has a very old or restrictive security configuration (DSO handler).<\/li>\n<\/ol>\n<p>If after applying the <code>FS_METHOD<\/code> If you continue to have problems with shared hosting, I recommend you contact technical support. Sometimes, the provider needs to apply a <code>chown<\/code> recursive from their side that you cannot perform.<\/p>\n<h2>Frequently Asked Questions about file system access<\/h2>\n<h3>Is it safe to leave FS_METHOD set to \u2018direct\u2019?<\/h3>\n<p>Yes, in the vast majority of modern cases it is safe, as long as the rest of your server is properly configured. This is the standard on most managed WordPress hostings.<\/p>\n<h3>Why does this happen after a migration?<\/h3>\n<p>When you move a site from server A to server B (for example, using a migration plugin or moving zip files), the files may be unpacked with the \u00abroot\u00bb user or the system user, instead of the specific user of your hosting account, generating the \u00abCould not access filesystem\u00bb conflict.<\/p>\n<h3>I have tried everything and it still fails, what do I do?<\/h3>\n<p>Check if you have disk space. Sometimes a \u00abcannot write\u00bb error is mistaken for permissions, when in fact the server is full (Disk Quota Exceeded).<\/p>\n<div class=\"intro\">\n<p>Resolving the error <strong>\u00abCould not access filesystem WordPress\u00bb<\/strong> is a rite of passage for any webmaster. Whether you opt for the quick fix of the <code>wp-config.php<\/code> or the granular correction of permissions via terminal, the important thing to understand is that you are managing the security of how your server allows modifications.<\/p>\n<p>If you follow these steps, not only will you eliminate that annoying FTP pop-up, but you'll have a more robust WordPress installation ready for frictionless automatic updates.<\/p>\n<\/div>\n<\/div>","protected":false},"excerpt":{"rendered":"<p>Imagina la situaci\u00f3n: Est\u00e1s listo para actualizar tus plugins, instalar un nuevo tema o realizar esa actualizaci\u00f3n cr\u00edtica del n\u00facleo de WordPress. Haces clic en el bot\u00f3n de actualizar y, en lugar de ver la barra de progreso, te encuentras con una ventana emergente molesta que te pide credenciales de conexi\u00f3n FTP. O peor a\u00fan, [&hellip;]<\/p>\n","protected":false},"author":3,"featured_media":5619,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-5276","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/awp.agency\/en\/wp-json\/wp\/v2\/posts\/5276","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/awp.agency\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/awp.agency\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/awp.agency\/en\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/awp.agency\/en\/wp-json\/wp\/v2\/comments?post=5276"}],"version-history":[{"count":1,"href":"https:\/\/awp.agency\/en\/wp-json\/wp\/v2\/posts\/5276\/revisions"}],"predecessor-version":[{"id":5281,"href":"https:\/\/awp.agency\/en\/wp-json\/wp\/v2\/posts\/5276\/revisions\/5281"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/awp.agency\/en\/wp-json\/wp\/v2\/media\/5619"}],"wp:attachment":[{"href":"https:\/\/awp.agency\/en\/wp-json\/wp\/v2\/media?parent=5276"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/awp.agency\/en\/wp-json\/wp\/v2\/categories?post=5276"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/awp.agency\/en\/wp-json\/wp\/v2\/tags?post=5276"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}