WordPress cannot write the file to disk: find and fix the blockage

Understand where writing fails

You upload an image or document, then WordPress says it cannot write the file to disk. The transfer may already have started, older media remains visible and administration seems to work. The desired result is simple: save a new file in the media library without unnecessarily changing permissions on the rest of the site.

A standard upload passes through two locations. PHP, the software that runs WordPress on the server, first receives the file in a temporary directory. WordPress can then move it into the final media directory. Failure at the first stage and failure at the second require different checks. The word “disk” therefore does not necessarily refer to the uploads directory.

This procedure concerns saving the file. If the message instead reports an exceeded maximum size, prohibited format or image-processing failure after receipt, use the corresponding diagnosis. Increasing memory or allowing a new format does not repair a location that has become unwritable.

Record the message before choosing a repair

Copy the complete error text, the time with your time zone and the screen used. A translation, plugin or form can change the wording. Support can locate the corresponding request more easily with these details than with a screenshot showing only a red bar.

When the PHP code is available in a private diagnostic, code 6, UPLOAD_ERR_NO_TMP_DIR, indicates a missing temporary directory. Code 7, UPLOAD_ERR_CANT_WRITE, indicates a write failure during PHP reception. WordPress handles these errors before moving the file to its final destination. Do not therefore conclude that media-library permissions are responsible.

A message saying that the file cannot be moved to a path, or that the path cannot be created, points toward the destination. You still need to distinguish full storage, incorrect ownership and refused access. The wording alone does not tell you which new permission value to choose.

Run a limited test and retain the clues

Keep your original on the computer. Prepare a small file without personal data, already readable locally and of a type normally accepted on this site. Give it a recognizable name to avoid confusing it with an existing publication. Under Media, use Add New Media File or the equivalent label in your interface.

Upload it once, then examine the result. Before another attempt, search for that name in the media library: a general message can appear even though part of the operation succeeded. Repeated tests mainly risk accumulating duplicates.

If the small file fails in the same way, keep that result for diagnosis. If it succeeds, do not regard the server as definitively healthy: nearly exhausted capacity may still accept a small file. Then compare the original file’s message. If only a form fails while Media works, report that entry point to the form maintainer; its settings may use another location.

Read the PHP reception code for one reference file

If the media library gives an overly general message, the maintainer can record the PHP code received by native processing. On an authorized copy, prepare a small, valid PNG without personal data named bpc-ecriture-731.png. The snippet targets the asynchronous POST used to add media in administration for the configured test site, account and filename. It returns the original array and logs only a fixed marker and the numeric code. The web process’s PHP log must be accessible only to authorized people.

On the copy, put the snippet in wp-content/plugins/bpc-trace-ecriture/bpc-trace-ecriture.php. Replace 7 and 42 with the site ID and the ID of the test account authorized to upload. On a single site, the site ID is generally 1. The maintainer can confirm both values before the test. Activate the plugin for the affected site only. From Media > Add New Media File, use the standard uploader and send the reference file once. Look for BPC ecriture recette in the log at the test time. Code 6 or 7 points toward temporary reception. Code 0 means PHP reported receipt without an error. Then check moving or processing if WordPress still reports failure.

If there is no line, check the name, IDs and site log. In the Network panel, the path expected by this example is a POST to wp-admin/async-upload.php. A fallback form, REST request or plugin may take another path. An upstream rejection, such as exceeding post_max_size and leaving $_FILES empty, can prevent the filter from being called. After the test, deactivate the test plugin, remove its file from the copy and retain only the useful time and code. If the reference file entered Media, remove it after checking its uses.

<?php
/**
 * Plugin Name: BPC Trace écriture de recette
 */

defined('ABSPATH') || exit;

add_filter('wp_handle_upload_prefilter', static function (array $file): array {
    global $pagenow;

    $site_id = 7;
    $user_id = 42;

    if ('async-upload.php' !== ($pagenow ?? '')
        || 'POST' !== ($_SERVER['REQUEST_METHOD'] ?? '')
        || 'upload-attachment' !== ($_POST['action'] ?? '')
        || $site_id !== get_current_blog_id()
        || $user_id !== get_current_user_id()
        || 'bpc-ecriture-731.png' !== ($file['name'] ?? '')
        || ! is_int($file['error'] ?? null)
    ) {
        return $file;
    }

    error_log('[BPC ecriture recette] code PHP ' . $file['error']);
    return $file;
}, 1);

Choose the approach and check your access

On self-hosted WordPress, site administration and the host’s panel are two distinct access points. A WordPress administrator account does not automatically permit changing PHP configuration, file ownership or quotas. Prepare access to the correct hosting account before following a procedure.

Under Tools, Site Health, Info, record the WordPress and PHP versions, then review the directories and filesystem-permissions sections. These details are clues. A main directory reported as accessible does not guarantee that its monthly subdirectory, temporary storage or all account limits are suitable.

• Start with approach 1 when a storage indicator is full or several write operations fail.
• Choose approach 2 if the message or diagnosis concerns the PHP temporary directory or error code 7.
• Follow approach 3 if the error identifies creation of the media directory or moving a file into it.

Approach 1: identify the capacity that is actually exhausted

Open the hosting panel and select the account hosting this domain. Look for Disk Usage, Storage or Resources. In cPanel, Disk Usage describes the space used by the account. Record consumption and the limit rather than just a colored bar, along with the time of inspection.

Separately check the number of files or inodes when displayed. Here, an inode represents a storage entry for a file or directory. Reaching a limit can prevent new creation while gigabytes remain available. Capacity in bytes and file count answer different questions.

The quota is your account’s allocation. The disk hosting it also has its own limits, and the temporary directory may use another location. A reassuring dashboard is therefore not enough to rule out all saturation. Ask support to check space and inodes at the locations actually used for temporary reception and the destination.

Record the results separately. If the host confirms that shared infrastructure is full, its team must intervene; your WordPress settings will not free that storage.

Recover capacity without sacrificing media

When an account limit is confirmed, identify what occupies the relevant resource. A known old migration archive preserved elsewhere may be a candidate for removal. A gallery still published is not. Removing a large archive mainly reduces occupied space; a multitude of small files may mainly account for inode usage.

Before removal, check the copy outside the account and its contents. Do not start a new full backup in storage that is already full: its creation may fail and consume the remaining margin. Have support validate technical files whose purpose you do not know. Shared temporary directories and session files are not a reserve to empty manually.

If no dispensable item is identified, request a targeted capacity adjustment or an appropriate storage solution. After intervention, wait for the counter to update or have the actual value confirmed, then repeat the limited test. If capacity is available again but the same error persists, continue with the indicated location. Do not repeatedly delete files for a permission problem.

Approach 2: check PHP’s temporary directory

This approach concerns the initial receipt of the file. The upload_tmp_dir setting identifies the temporary directory for PHP uploads. If unset, PHP uses the system temporary directory. An empty value is therefore not, by itself, an anomaly.

The directory must be writable by the identity running PHP. If the configured directory is not writable, PHP tries the system temporary directory. An open_basedir restriction, which limits paths accessible to PHP, must also allow the fallback location. Examine the effective configuration, rather than merely noting that a directory named tmp exists somewhere in the account.

Request this check for the PHP serving the affected domain. A check performed only with command-line PHP may use another configuration. Give support the error code and test time; they can check the path used, process identity and storage state at that stage.

Do not create a public phpinfo() page or visitor-accessible test script to obtain this information. Use the panel’s private diagnostics or the host’s support.

Correct the temporary directory through the intended setting

upload_tmp_dir is a system-level setting. Adding an ini_set() call in WordPress or a line in .user.ini is not a valid fix for this setting. If your panel offers this option, first verify with the host that it affects the domain’s PHP.

The correction must restore an authorized, available directory usable by the service. The provider may repair the existing location or supply a dedicated path. The latter must be protected from public access: receiving temporary files in an exposed site directory is not good troubleshooting.

Do not confuse this setting with WP_TEMP_DIR. That constant influences the temporary location used for certain internal WordPress operations. It does not replace PHP’s file-reception configuration. Defining it randomly in wp-config.php risks leaving the original error intact while adding configuration to maintain.

• Record the previous setting and the path proposed by the provider.
• Apply only its procedure for this domain, including a service reload if needed and authorized.
• Have the effective value confirmed, then test an upload from Media.
• If it fails, send the new message and have the previous configuration restored if the change is not retained.

Approach 3: find the exact media destination

This approach assumes that the error concerns directory creation or moving the received file. Take the indicated path, then open File Manager for the correct domain. Do not assume that all sites in the account use the same public directory.

In a typical installation, media resides under wp-content/uploads, possibly organized by year and month. This path can be customized. A multisite network or external-storage solution may also organize files differently. Have the actual path confirmed before creating a directory or changing its properties.

Check whether the final directory exists and whether its parent exists. A failure at the change of month may coincide with creation of a new subdirectory; this is a lead, not proof. Compare its properties with those of a working neighboring directory without automatically copying them.

After migration, an old absolute path may also remain in a custom configuration. Have the identified setting corrected by the person who installed it. Artificially creating the old directory tree or changing database options randomly would conceal the cause.

Distinguish ownership from permissions

A file’s owner is an account in the hosting operating system, not the author displayed in WordPress. Permissions then define what that owner, its group and other accounts can do. The PHP service needs appropriate rights to create a file at the destination.

Successful SFTP access therefore does not prove that PHP can write in the same place: the two operations may use different identities. Conversely, reading older images in a browser does not demonstrate the ability to create new ones. Present these observations as separate clues.

A directory restored by another account may have apparently ordinary permissions but an unsuitable owner. In that case, ask the host to correct its association with the intended account or group. Broadening rights to compensate for incorrect ownership leaves the underlying problem in place.

The common values 0755 for directories and 0644 for files are not a universal prescription. Operation depends on the PHP identity and server policy. Never apply 777 to bypass the error, even temporarily.

Apply only the confirmed permission correction

If the owner is correct and the host confirms a permission value for a specific directory, you can make that change with authorized access. In cPanel, open File Manager, select only that directory, then Permissions. Other panels offer a similar command in properties.

Photograph or note the current value, path and expected value. Check that no option to apply to subdirectories and files is selected. A recursive change affects an entire tree: it exceeds the need if only one directory was created incorrectly.

Save the correction, then repeat the limited upload. If the error remains identical, restore the previous value unless support explicitly instructs you to retain the new one. Send the result instead of successively trying more open permissions. Changing ownership is generally the provider’s responsibility when your account lacks that right.

When permissions and identity are correct, ask whether storage has become read-only or a server-specific access rule prevents writing. These situations require infrastructure diagnosis. Do not disable a global protection or modify every site directory to bypass them.

Adapt the procedure to WordPress.com and multisite

On WordPress.com, start in the hosting dashboard, select the site, then review its overview and storage. Capabilities and technical access depend on the plan. File access, when available, does not mean you can administer the PHP service’s temporary directory.

If permitted space is available and the write error persists, send the case to platform support. Avoid adding settings intended for a server you administer yourself. The storage limit and an infrastructure fault must be examined separately.

In a multisite network, involve the network administrator. The subsite may reach its media allocation while the server still has space. Network upload settings and any site-specific settings must be checked before intervening on the filesystem.

Specify which subsite is affected and whether others are too. This comparison helps focus the investigation without justifying a shared change. Paths and identities still need confirmation for this network; changing permissions across the entire installation for one subsite is not a targeted repair.

Verify saving after the correction

First use the small reference file, then a file representative of the initial need. Check that each upload produces a single Media entry, that the file opens at its URL and that it displays correctly in a draft preview. Do not overwrite an existing image for this check.

If the original file is accessible but its variants are not created, initial writing has progressed; record the new message and continue with image-processing diagnosis. A different error does not justify declaring the whole path repaired, but it prevents endlessly revisiting the same stage.

Remove only reference files you can identify and that are used nowhere. Keep a note of the setting that actually worked, its scope and the date. Changes with no effect must have been undone or explicitly approved by the provider before closing the incident.

Send useful evidence and prevent recurrence

If no cause is confirmed, send support a compact record of observations. Ask where writing fails and which identity attempts the operation. A reply limited to “check permissions” is not enough: you need to know the affected directory and the correction compatible with this hosting environment.

After resolution, enable storage alerts offered by the provider and check backup destinations. Have the expected owner and any particular temporary-directory configuration retained in migration notes. This information will let you compare a future failure with a known state without opening access further.

• State the domain, any subsite, the screen used and the exact time with its time zone.
• Include the complete message, PHP code if known and the limited test result.
• Specify WordPress and PHP versions, along with any recent migration, restoration or hosting change.
• Add available space and inode measurements, examined paths and changes already reversed or retained.
• Send internal paths and log excerpts in the private ticket, removing unnecessary personal data, tokens and credentials.

Compare available space with available file capacity

On a GNU/Linux server with SSH, the person responsible can record two different limits without deleting data. Have the existing destination-directory path and the temporary-directory path used by web PHP confirmed. Replace both examples below; do not assume the terminal’s temporary directory is the one used by PHP-FPM.

The first reading concerns filesystem space; the second concerns inodes, meaning its capacity to reference files. It is possible to run out of inodes while gigabytes still appear available. Two paths may belong to different partitions: examine each result with the time of the failed upload.

These figures do not replace the account’s individual quota, the host’s imposed limit or remote-storage logs. A reassuring result does not rule out insufficient permissions either. If the commands are unavailable, support can provide the same readings.

The expected result is to confirm or rule out a precise saturation before choosing an action. Do not turn this check into automatic deletion of temporary files: other operations may be using them. No rollback is needed for these reads; freeing space must follow a separate, verified procedure.

df -h -- '/chemin/uploads' '/chemin/temporaire-confirme'
df -i -- '/chemin/uploads' '/chemin/temporaire-confirme'