WordPress installation blocked: the directory is not writable

Recognize the blockage before starting again

You are installing WordPress and the host’s tool refuses to create a directory or copy files. Another case: the files are already present, but WordPress’s native setup wizard cannot save its configuration. These are different stages. Repeating the process with the same parameters does not resolve the refusal: identify the directory concerned, the tool used and the account attempting to write there.

This guide concerns a new, self-hosted installation. A refusal while updating a plugin or uploading an image calls for a different diagnosis. On WordPress.com, the normal site-creation process does not involve manually installing core: use platform support if its creation process fails.

Keep the exact message, time, chosen domain and failing stage. Distinguish “cannot create directory” from “cannot write wp-config.php.” The second case can sometimes be solved by preparing that file manually, without opening permissions across the whole directory.

If this domain already displayed your site before the incident, stop the installation. A setup wizard appearing after migration does not prove that WordPress needs reinstalling. First find the correct installation, its configuration and database. Adding a new site in the same location could complicate that recovery.

Choose the path matching the message

Approach 1 is suitable when the selected directory seems incorrect or several domains share the hosting account. It consists of finding the directory actually associated with the domain and checking its contents. You do not need to change permissions to correct a wrongly selected destination.

Approach 2 targets a confirmed write refusal at the correct location. It separates permissions, file ownership and available resources. Some corrections are the host’s responsibility: your management account and the installer do not necessarily operate under the same server identity.

Approach 3 concerns only a WordPress wizard unable to produce wp-config.php while the files are already correctly in place. A configuration prepared with the right data lets this specific case proceed. It fixes neither full storage nor a directory owned by the wrong account.

Keep the same goal throughout testing: finish a single installation in the intended directory, without exposing its secrets or modifying other sites in the account. After each correction, repeat only the relevant stage and examine the result before continuing.

Preserve existing content and check your access

A directory presented as available may contain an old page, configuration, hidden files or another site. Examine its contents before replacing anything. If you do not recognize some items, ask the account manager to identify them. A familiar directory name does not authorize clearing it.

If resuming an interrupted installation, keep a copy of existing files and note any database already created. For a location already in use, have the corresponding files and data preserved before any intervention. Do not delete a database simply because the installer offers to create another.

You need authorized access to the hosting panel or to files through a secure protocol provided by the host. A WordPress administrator account does not automatically grant those rights. Check that access targets the correct subscription, especially when an agency manages several clients or a domain recently moved accounts.

For an unfinished manual installation, have hosting temporarily restrict access to its directory: a visitor must not be able to finish the wizard in your place. Use a valid HTTPS address before entering database details. Keep access private until your administrator account has been created and end-of-installation checks completed.

Keep notes and configuration copies in a private location. Do not put a file renamed wp-config.php.bak in the public directory. A copy with another extension may no longer be processed as PHP and could expose its contents. A site directory is not the place to archive its secrets.

Approach 1: find the directory actually associated with the domain

In the hosting panel, open the sites or domains section, then the relevant domain’s details. Find the document root: the directory whose files the server uses to respond at that address. Its name depends on the host; public_html is not a universal destination for every domain.

With cPanel, the Domains section lists the account’s domains and their information. Record the root shown for the correct domain, then find that path in File Manager. Visible features may vary according to options enabled by the provider.

Compare this path with the destination shown in the installer. Also check any subdirectory field. Installing in a blog directory generally means preparing a site at that sub-address, rather than at the domain root. Do not remove that part without checking where files will be placed.

Take a fictional example: the account contains site-client-a and site-client-b directories. The second client’s domain should target the second directory. The first may be writable, but successfully installing there would not be a repair: you would simply have installed WordPress in the wrong place.

Correct the destination without moving an existing site

If the installer targets a directory other than the intended one, correct its destination field before running it again. Then return to the summary screen: domain, subdirectory and selected database must match the project. Changing only the destination field does not require moving other domains’ files.

If the expected directory is missing, have its creation confirmed through the panel or hosting administrator. Avoid creating several similarly named directories to find one that works. You must be able to unambiguously connect the browser address, server path and site record.

When WordPress files are already present, check whether they belong to the interrupted attempt or an earlier installation. A warning about existing files is not necessarily a permission error. Do not tick an overwrite option to dismiss that warning without identifying what will be replaced.

Then rerun the failing stage just once. If the same path is still refused, the destination is now confirmed: move on to examining access. If installation starts in a different directory from the intended one, stop it through the tool’s normal mechanism and have that discrepancy clarified.

Approach 2: distinguish permissions and ownership

Permissions specify which operations an account can perform on a file or directory. On Unix-like hosting, they distinguish, in particular, owner, group and other users. To create a file in a directory, the process must be able to write to and traverse that directory, as well as traverse its parent directories. Directory traversal permission does not mean that every file must be executable.

The owner is the account to which the item belongs. A permission value suitable for one environment may fail in another if files were uploaded by a different account. This can happen after extracting an archive or after work performed with administrative server rights.

Values of 755 for a directory and 644 for a file are common, but they are not a universal fix. Other modes may be needed depending on the identity used by PHP and the provider’s setup. The configuration file also deserves protection appropriate to its sensitive contents.

Ask support which identity runs the installation and which values are expected for that precise path. Successfully creating a file in the manager or over SFTP does not prove that PHP has the same access. Do not replace this check with 777, which permits writing much more widely. Nor should you assign the same value to every file and directory: their needs differ.

Apply a limited correction through File Manager

If the provider has confirmed an incorrect permission that your account can change, select only the relevant item. In cPanel’s File Manager, use Permissions, record the current value, then apply the confirmed value with Change Permissions. Check the selected item’s name before confirming.

Note the path, old value and new one. Reject recursive application to all subdirectories unless it is part of a specifically justified intervention. A correction to the installation directory must not affect private archives, other sites or the account’s configuration files.

Return to the wizard and repeat the refused action. If the result does not change, do not progressively increase permissions at random. Restore the original value if required by the planned intervention, then report the failure with the path and time. Another cause must then be checked.

If the panel refuses the change or ownership is wrong, go through the host. Do not seek administrator access to the server merely to apply a command copied elsewhere. On a shared account, the provider should correct ownership of the relevant path without broadening rights across the subscription.

Examine storage and account restrictions

A directory may have suitable permissions and still be impossible to fill because no space remains. Check storage indicators in the panel. In cPanel, Disk Usage helps identify space used by files and directories. A quota-exceeded message indicates a different problem from permission refusal.

Also check other limits stated by your host, including file count when such a ceiling exists. A compressed archive may occupy little space before extraction, then produce many files. Support should confirm the effective limit preventing the operation rather than have you change unrelated permissions.

Do not free space by deleting unfamiliar account directories. Have obsolete items identified and preserve necessary backups outside the server before targeted cleanup. If more capacity is offered, examine the cost and why storage filled up; an upgrade does not automatically replace diagnosis.

Support may also discover read-only storage, a security restriction or an installer-specific limit. Request a check of the exact operation. A server rule should not be globally disabled simply to see whether installation works; a correction must match the observed cause.

Approach 3: prepare wp-config.php when only this file is missing

This method applies to a new manual installation whose WordPress files are already in the right place. The wizard has received the necessary details but cannot write wp-config.php. If that file already exists and belongs to an earlier site, do not replace it: have the existing configuration examined. Also have the immediate parent directory checked: WordPress can load a configuration there under certain conditions. Do not move or delete that configuration to force a new installation.

When the wizard displays the content to copy after its write refusal, you can copy it in full into a private local file. This content contains secrets: do not paste it into a forum or public service. WordPress also lets you start from wp-config-sample.php, included in its official package. In a text editor, then fill in the required values: database name, user, password and database server.

The database account differs from the future WordPress administrator. Have its access to the intended database confirmed without granting global server privileges. Do not assume its address is always localhost. Preserve PHP syntax and unique security keys; an apostrophe or backslash in a value must be represented correctly. If you are not comfortable writing this, use the content produced by the wizard or have the provider prepare the file, without simplifying the password. A word processor that transforms quotation marks is unsuitable.

Also confirm that the database and table prefix are intended for this new installation. A dedicated database avoids confusion. If several installations intentionally share a database, their prefixes must differ. Do not change an existing site’s prefix to make a new wizard appear, and do not reuse an unfamiliar set of tables.

Save the file with the exact name wp-config.php as UTF-8 text without a BOM marker or an extra .txt extension, then transfer it to the confirmed WordPress directory. Keep its permissions in line with the provider’s instructions. Do not add copies containing credentials to public locations to make tests easier.

The following fictional excerpt serves only to identify the four connection definitions. It is not a complete wp-config.php file: keep the template’s other lines, unique keys and confirmed prefix. The database name corresponds to DB_NAME, the SQL user to DB_USER, its secret to DB_PASSWORD and the server address to DB_HOST, with the port or socket required by the provider. The four uppercase texts must be replaced privately; do not upload these example values as they stand.

1. Keep a private local copy of the complete file before changing its values.
2. Find each of the four existing lines in the template or wizard-provided content; change its value in place without adding a second definition with the same name.
3. Check straight quotes, parentheses and semicolons before saving and transferring the complete file as described above.
4. Resume the wizard: the wp-config.php creation refusal should disappear. A connection error leads to the next path; a syntax error calls for correcting the edit from the private copy without overwriting an older site configuration.

define( 'DB_NAME', 'NOM_BASE_CONFIRME' );
define( 'DB_USER', 'UTILISATEUR_SQL_CONFIRME' );
define( 'DB_PASSWORD', 'SECRET_CONFIRME_A_SAISIR_EN_PRIVE' );
define( 'DB_HOST', 'HOTE_PORT_OU_SOCKET_FOURNI' );

Resume installation and interpret the next result

After transferring the configuration file, resume the wizard at the address matching this installation. The wp-admin/install.php path sits beneath the WordPress root; if WordPress is installed in a subdirectory, that prefix forms part of the URL. Check the domain before entering the future site’s details.

If a database connection message now appears, installation has reached a different stage. Do not return to directory permissions to address this new message. Compare the configuration with the hosting details and use the diagnosis dedicated to database connection.

If the configuration file cannot even be transferred, this method will not bypass the write refusal. Return to diagnosis of the path, account and resources. If the browser offers to download PHP or shows its contents, stop the procedure and have the provider block the relevant public access while correcting PHP processing. If they detect exposed credentials or keys, or consider them potentially compromised, have them replaced and update the configuration before resuming; do not share their contents in a public screenshot.

Installation must end with creation of the intended site and normal access to its administration area. The first warning disappearing is not enough. Check the displayed address, new site title and absence of changes to other sites managed in the same account.

Check operation and close the intervention

Once signed in, open the home page and an administration page. On a new site, create a checking draft and reopen it to verify saving. Then try a small, non-confidential media item if the project will receive media. This distinguishes a completed installation from an environment still unable to write necessary files.

If media upload fails, record its precise message: do not automatically apply the installation-directory fix across the whole library. Upload may be stopped by a size ceiling, quota or separate processing stage. The guide matching this new symptom will be more useful.

Confirm with the provider which permissions to retain after installation. Remove identified temporary items that are no longer needed without deleting standard WordPress files or the active configuration. Keep the intervention record and private safety copy according to your usual procedures.

To request help, provide the affected domain, refused path, time, tool used, exact stage and corrections already tried. A screenshot of the message is often enough to begin; it must not show a password. Ask for an answer covering the confirmed cause, applied correction and check performed. You will then have an installation you understand, not merely a screen that eventually let you through.

Identify the terminal account without confusing it with PHP

A developer with SSH can start with an observation without modifying permissions. In the authorized hosting account’s terminal, run:

The output identifies this process’s user and groups. Keep it in the private diagnostic folder and ask support to compare it with the effective identity of the PHP process serving this domain. A file created through your SSH connection may belong to a different user from PHP: successful creation in the terminal therefore does not prove that WordPress can write at the same location.

The useful result is a comparison of three precise elements: target directory owner, authorized group and web PHP identity. Also request checks of parent directories, ACLs and any read-only mount. The command does not provide that latter information or decide which permission to apply.

If you do not have SSH, send support the path already recorded and this comparison request; no additional plugin is necessary. Observation changes nothing and requires no rollback. Any ownership correction remains a separate operation, targeted at confirmed files and prepared with the host.

id