Скорее всего ошибка в имени файла, который выгрузка пытается записать на диск. В конфигураторе 1С найти кусок кода:
ИмяПоНоменклатуре = Строка(Номенклатура.УникальныйИдентификатор());
ИмяПоХранилищу = Строка(ХранилищеСсылка.УникальныйИдентификатор());
ИмяФайлаКартинки = ИмяПоНоменклатуре + «_» + ИмяПоХранилищу + «.» + НРег(РасширениеФайлаКартинки);
КаталогПоИмени = Лев(ИмяПоНоменклатуре, 2);
КаталогКартинки = мКаталогНаДиске + «\» + мПодкаталогФайлов + «\» + КаталогПоИмени;
СоздатьКаталог(КаталогКартинки);
ПолноеИмяФайлаКартинки = КаталогКартинки + «\» + ИмяФайлаКартинки;
Попытка
Картинка.Записать(ПолноеИмяФайлаКартинки);
Исключение
СообщитьОбИсключительнойОшибке(Истина, «Не удалось записать файл картинки на диск. Номенклатура: » + Номенклатура);
Возврат Результат;
КонецПопытки;
Результат = мПодкаталогФайлов + «/» + КаталогПоИмени + «/» + ИмяФайлаКартинки;
Поставить точку останова и посмотреть какое система генерирует ПолноеИмяФайлаКартинки.
Пытаюсь перенести сайт на 1С-Битрикс на виртуальный сервер VPS, панель управления Vesta. Сделал резервную копию. Кинул её файлы и restore.php (скачал по ссылке из официального урока) в нужную папку виртуального сервера. Права на родительскую папку — 751, на файлы — 644. Владелец — root. Другой сайт с такими же правами функционирует нормально.
Когда захожу из браузера https://***.ru/restore.php , меня вместо страницы приветствует сообщение об ошибке:
Не могу записать файл /home/***/public_html/restore.php. Место на диске: 13.56Gb
-
Вопрос задан
-
1425 просмотров
Пригласить эксперта
Если у вас хостинг и нет возможности сделать бэкап средствами хостинга, то сделайте бэкап средствами битрикс с пропуском логов и кеша без пароля.
Из папки /bitrix/backup скачайте архив на компьютер, пересоберите архив: распакуйте архив, соберите все части в Тотал Коммандер, например, упакуйте в zip и залейте его в корень сайта, средствами админки Vesta распакуйте zip.
Запустите restore.php, выберите, что архив уже распакован, и там же выберите импортировать БД.
Инструмент бэкапа через restore.php иногда криво работает с файлами.
Найти информацию про распаковку битриксовского архива можно тут
https://qna.habr.com/q/373442
-
Показать ещё
Загружается…
22 сент. 2023, в 07:00
5000 руб./за проект
22 сент. 2023, в 06:12
25000 руб./за проект
22 сент. 2023, в 05:50
40000 руб./за проект
Минуточку внимания
Добрый день уважаемые читатели блога про битрикс, итак сегодня я расскажу вам о том, как перенести действующий сайт на другой хостинг или развернуть бекап из облачного сервиса битрикс благодаря скрипту «bitrix restore.php«.
Чтобы восстановить сайт Битрикс из бекапа на новый хостинг или на локальный веб-сервер достаточно создать в корневом каталоге файл restore.php скопировать код или скачать restore.php bitrix:
в уже созданный файл и запустить его из строки своего браузера: site.ru/restore.php, либо скачать его с официального сайта Битрикс по ссылке: www.1c-bitrix.ru/download/scripts/restore.php После чего, его нужно скопировать в корневую папку сайта и запустить. Далее вам откроется окно, где вы выбираете расположение бекапа вашего сайта, он может быть уже закачен вами в корневую папку нового сервера, либо размещен на том хостинге с которого вы хотите его перенести, либо если вы его загрузили к себе на компьютер, то также можно его загрузить с локального диска(далее укажите его местоположение с помощью кнопки Обзор), ну и самое главное, если у вас действующая лицензия bitrix и вы воспользовались функцией регулярного резервного копирования в облако bitrix, то скрипт предложит и этот метод восстановления/ переноса вашего сайта на bitrix. Тут в принципе нечего объяснять, вы и так всё видите. Всё довольно просто, проделаете эту процедуру раз 5 и поймете что восстанавливать сайты из резервных копий не занимает много времени и усилий. Кстати говоря, не забывайте их делать хотя бы каждую неделю — если вы активно работаете над сайтом, и каждый месяц — если редко., либо воспользуйтесь функцией регулярного резервного копирования в облако, я после завершения работ по новому сайту всегда выполняю данную настройку, чтобы не случилось с вашим хостингом, в облаке bitrix бекапы все-таки держать надежнее, причем места под несколько бекапов там там достаточно.
Итак переходим по ссылке site.ru/restore.php
Жмём далее… Указываем откуда будем собственно скачивать бекап
В случае если скачиваем из облака, а это самый предпочтительный вариант, указываем код действующей лицензии сайта на битрикс
Выбираем нужный архив по дате, как я уже говорил, их может быть несколько если вы все правильно настроили в модуле резервного копирования в облако.
Загрузка успешно началась, в этом несомненно нам помогает скрипт bitrix restore.php ))
Вот в принципе и все, загрузка с облака на сервер успешно завершена.
Далее идет распаковка архива на сервере, PS: если в друг что-то далее пойдет не так, то шаг загрузки уже можно пропустить, т.к. архив уже на сервере и его можно только разархивировать
После того как все файлы разархивированы, скрипт restore.php начинает восстанавливать базу данных, здесь немного надо поработать, ведь скрипт не может делать всё за вас))
Восстановление базы данных.
После этого скрипт заберет указанные ваши данные и вернет их в следующее окно. Сервер базы данных так и оставляем: localhost
После этого жмем восстановить БД.
Восстановление базы данных и вообщем сайта успешно завершено благодаря скрипту от bitrix restore.php
И как всегда, спасибо за внимание, ставьте лайки, подписывайтесь))
Источник
Всем привет, такая проблема. Есть бэкап сайта, нужно его как-то восстановить.
50мб) в корень сайта
2. Туда же положил битрикосвый restore.php
3. Запускаю restore.php, жму далее, потом выбираю «Архив загружен в корневую папку сервера» и выбираю там единственный мой бэкап. Жму далее
4. Вижу ошибку:
«Доступны не все части многотомного архива.
Общее число частей: 4″
Сергей Хренасдва
Полностью с вами согласен.
Уже третий рабочий день пытаюсь разобраться как это «чудо инженерной мысли» работает.
Восстановление бэкапа это вообще какой-то бред.
На текущей системе бэкап делался
на только что развернутой чистой, Cent OS обновленной и установленой через ваш баш-скрипт.
Бэкап чистой ситемы завис на 50% после 10 минут и так и не сделался, (ничего не настраивалось ничего не менялось)
Может был какой глюк, но такое повсюду, то работает, то не работает.
Перенести бэкап с одного сервера на другой вообще ад какой-то.
Как вы представляете переносить 30 гигов, выбирая один из трех методов.
1. загрузить с облака
2. загрузить по прямой ссылке
3. загрузить с компьютера
При прямой ссылке можно только вставить одну, ну спасибо и в самом битриксе вы не рекомендуете создавать одним файлом бэкап (а по 100 мб, считайте сколько частей из 30Гб) и то если скормливать системе ссылку она ругается и уходит в редирект
что говорить, если у вас даже форум работает через пень колоду. (пока писал сообщение)
ВСЕ СКАЧЕНО С ВАШЕГО САЙТА, НИКТО НИЧЕГО НЕ ЛОМАЛ В НАСТРОЙКАХ, ПРАВА ДОСТУПА ВЫСТАВЛЕНЫ ПРАВИЛЬНЫЕ/
Источник
Во время восстановление через restore.php выадет ошибку.
Запускаю восстановление бэкапа, но после скачивания архива и во время распаковки выдает ошибку:
Can’t create file: /var/www/tesk/data/www/tesk.pro/18a5ace48a8c.html
Права на папку сайта установил в 777, я даже cделал права на файл restore.php в 777, но все равно не помогает.
Нужна срочная помощь.
места на диске хватает, вот данные хостинга
Память (ОЗУ) 47% от 1400 МБ
Люди, мне срочно нужна помощь, рабочий сайт лежит, заказчик рвет и мечет, а я даже идей ни каких не имею в каком направлении копать.
Отзовитесь кто нибудь, буду очень благодарен за любое предположение, даже самое невероятное!
C бекапом все нормально, сайт локально поднялся без проблем, но на хостинге ни чего не получается.
Цитата |
---|
Сергей Емельянов написал: Заходите по ssh, вытаскивайте БД, создайте параллельно ещё одну БД, распакуйте туда бэкап, переключите сайт на новую БД. |
Этот вариант я рассматриваю на самый крайний случай, если вообще ни чего не получится.
Can’t create file: /var/www/tesk/data/www/tesk.pro/images/sale.png
Цитата |
---|
Настройка прав на сервере хостинг-провайдера может быть индивидуальна, но прежде всего должны быть установлены права на чтение/запись из скрипта для пользователя, под которым запущен веб-сервер Apache. |
Тема конечно устарела, но поиск прислал меня сюда и навел на правильные мысли.
Так что добавлю, что подобная проблема скорей не в правах доступа как таковых, а в том, что файл создан или получил нового владельца. Причиной такого события может быть то, что какие-то скрипты выполняются из CRON’а причем от имени пользователя, отличного от того, под которым запущен Апач с Битриксом.
Если говорить и типовом случае, когда Битрикс работает под Bitrix VM с CentOS, то все файлы Битрикс имеют и должны иметь владельца/группу «bitrix», если по каким-то причинам владелец/группа поменялись, то их можно восстановить командой в SSH консоли:
Источник
Правильное резервное копирование больших проектов Битрикс
Резервные копии больших проектов таких как коробочные версии порталов Битрикс24, на которых хранится большой объем информации не стоит создавать исключительно стандартными средствами системы. Как правило больше всего файлов хранится в папке битрикс upload. Обычно там находятся файлы диска, вложения к задачам, записи телефонных звонков и многое другое.
Может получится так, что вы не сможете их получить вовсе. В этой небольшой статье я расскажу вам как нужно правильно создавать резервную копию большого проекта, когда в папке битрикс upload хранится несколько десятков гигабайт информации.
Итак, действовать мы будем следующим образом: сначала создадим архив с ядром и БД средствами Битрикса (исключим из него папку upload и некоторые другие папки), а папку upload создадим через консоль командной строки, подключившись к порталу по SSH.
Кстати создать архив с помощью системы можно 2 способами: через административную панель сайта или запустив php-скрипт резервного копирования в командной строке. Архивировать в консоли считается более надежным и профессиональным способом – так как меньше шансов, что произойдет какая-нибудь ошибка, нежели при запуске инструмента архивации через браузер. В любом случае выбирать нужно вам.
В обоих случаях резервное копирование битрикс начать стоит с настроек копирования.
Настройки для первого способа можно сделать здесь: Настройки→Инструменты→Резервное копирование→Создание резервной копии (вкладка «Параметры» ). Нужно включить экспертные настройки создания резервной копии.
До параметров резервного копирования для второго способа можно добраться следующим образом: Настройки→Инструменты→Резервное копирование→Регулярное резервное копирование (вкладка «Параметры» ).
Параметры копирования находятся на разных страницах административной панели, но опции для настройки содержат практически одинаковые.
Общие параметры резервного копирования:
Параметры для 2-го способа (запуск скрипта через командную строку):
Если вы выбрали первый способ, то после установки параметров можно смело запускать создание резервной копии bitrix.
Для запуска резервного копирования выполняем следующую команду:
$ php –f /hiome/bitrix/www/ bitrix/modules/main/tools/backup.php
Независимо от того каким образом вы создавали резервную копию, на данный момент у вас есть резервная копия ядра и базы данных, которую вы сможете восстановить с помощью файла битрикс restore.php
Если вдруг вам понадобится восстановить копию, созданную описанным в статье способом, то просто загрузите архив с копией ядра и БД в папку на сервере, где у вас должен размещаться портал (например, /home/bitrix/www ) вместе с файлом restore.php и запустите восстановление в браузере.
После успешного завершения установки, загрузите в ту же папку архив с битрикс upload и выполните распаковку:
После выполнения описанных выше действий по восстановлению резервной копии, вы должны получить работоспособную копию вашего портала. Не забывайте периодически создавать резервные копии ваших проектов, особенно, перед каким-нибудь важными изменениями, такими как установка обновлений или внедрение каких-нибудь новых возможностей на ваших сайтах или порталах. Таким образом вы сможете избежать лишних проблем и сэкономить свое время, которое понадобится вам на восстановление проекта в случае его поломки.
Источник
Во время восстановление через restore.php выадет ошибку.
Запускаю восстановление бэкапа, но после скачивания архива и во время распаковки выдает ошибку:
Can’t create file: /var/www/tesk/data/www/tesk.pro/18a5ace48a8c.html
Права на папку сайта установил в 777, я даже cделал права на файл restore.php в 777, но все равно не помогает.
Нужна срочная помощь.
места на диске хватает, вот данные хостинга
Память (ОЗУ) 47% от 1400 МБ
Люди, мне срочно нужна помощь, рабочий сайт лежит, заказчик рвет и мечет, а я даже идей ни каких не имею в каком направлении копать.
Отзовитесь кто нибудь, буду очень благодарен за любое предположение, даже самое невероятное!
C бекапом все нормально, сайт локально поднялся без проблем, но на хостинге ни чего не получается.
Цитата |
---|
Сергей Емельянов написал: Заходите по ssh, вытаскивайте БД, создайте параллельно ещё одну БД, распакуйте туда бэкап, переключите сайт на новую БД. |
Этот вариант я рассматриваю на самый крайний случай, если вообще ни чего не получится.
Can’t create file: /var/www/tesk/data/www/tesk.pro/images/sale.png
Цитата |
---|
Настройка прав на сервере хостинг-провайдера может быть индивидуальна, но прежде всего должны быть установлены права на чтение/запись из скрипта для пользователя, под которым запущен веб-сервер Apache. |
Тема конечно устарела, но поиск прислал меня сюда и навел на правильные мысли.
Так что добавлю, что подобная проблема скорей не в правах доступа как таковых, а в том, что файл создан или получил нового владельца. Причиной такого события может быть то, что какие-то скрипты выполняются из CRON’а причем от имени пользователя, отличного от того, под которым запущен Апач с Битриксом.
Если говорить и типовом случае, когда Битрикс работает под Bitrix VM с CentOS, то все файлы Битрикс имеют и должны иметь владельца/группу «bitrix», если по каким-то причинам владелец/группа поменялись, то их можно восстановить командой в SSH консоли:
Источник
Вы видите сообщение «Upload: Failed to write file to disk» при загрузке файлов в WordPress? Эта распространенная ошибка может быть очень расстраивающей для начинающих пользователей. В этой статье мы покажем вам, как исправить ошибку «Загрузка: не удалось записать файл на диск» в WordPress.
Какие причины этой ошибки в WordPress?
Эта ошибка может возникнуть по ряду причин. Однако наиболее распространенным является неправильное разрешение папки.
Каждый файл и папка на вашем веб-сайте имеет набор разрешений. Ваш веб-сервер контролирует доступ к файлам на основе этих разрешений.
Неправильные разрешения для папки могут убрать вашу способность записывать файлы на сервер. Это означает, что ваш веб-сервер не может создавать или добавлять новые файлы в эту конкретную папку.
Если вы попытаетесь загрузить изображения или любые другие файлы из области администрирования WordPress, вы получите одно из следующих сообщений об ошибке:
- WordPress не удалось записать на диск
- WordPress не удалось загрузить из-за ошибки записи файла на диск
- Не удалось создать каталог wp-content /uploads/2018/03. Является ли его родительский каталог доступным для записи сервером?
Ошибка “Загрузить: не удалось записать файл на диск” в WordPress
Во-первых, вам нужно подключиться к сайту WordPress с помощью FTP-клиента.
Для этой статьи мы используем бесплатный FTP-клиент FileZilla. Если вы используете какой-либо другой FTP-клиент, это может выглядеть немного иначе.
Как только вы подключитесь, вам нужно щелкнуть правой кнопкой мыши по папке wp-content и выбрать права доступа к файлам.
Это вызовет диалоговое окно разрешения файлов в вашем FTP-клиенте. Он покажет вам права доступа к файлам для владельца, группы и общественности.
Вам нужно ввести 755 в поле числовых значений.
После этого вам нужно установить флажок «Recurse into subdirectories».
Наконец, вам нужно нажать «Применить только к каталогам».
Нажмите кнопку OK, чтобы продолжить.
Теперь ваш FTP-клиент установит права доступа к папке на 755 и применит их ко всем подпапкам внутри wp-content. Сюда входит папка загрузок, в которой хранятся все ваши изображения.
Вы также захотите убедиться, что права на файлы для отдельных файлов в папке wp-content верны.
Еще раз щелкните правой кнопкой мыши папку wp-content и выберите права доступа к файлам. На этот раз мы изменим разрешения для файлов.
Введите 644 в числовое значение, а затем установите флажок «Рекурсия в подкаталоги».
Наконец, вам нужно нажать кнопку «Применить только к файлам».
Нажмите кнопку OK, чтобы продолжить. Теперь ваш FTP-клиент установит права доступа к файлам на 644 для всех файлов в папке wp-content.
Теперь вы можете посетить сайт на WordPress и попробовать загрузить файлы.
Если вы все еще видите ошибку, вам нужно связаться с вашим провайдером хостинга WordPress и попросить их удалить папку временных файлов.
WordPress загружает ваши изображения с помощью PHP, который сначала сохраняет загрузки во временный каталог на вашем веб-сервере. После этого он перемещает их в папку загрузки WordPress.
Если этот временный каталог заполнен или плохо настроен, WordPress не сможет записать файл на диск.
Эта временная папка находится на вашем сервере, и в большинстве случаев вы не можете получить к ней доступ с помощью FTP. Вам нужно будет связаться с вашим веб-хостом и попросить их опорожнить его для вас.
Мы надеемся, что эта статья помогла вам решить проблему «Загрузить: не удалось записать файл на диск» в WordPress.
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.
If your site is encountering the “Upload: Failed to Write File to Disk” error, it can be more than annoying because you’re not able to upload new files until you’ve fixed.
Fortunately, there are a few steps you can take to resolve this WordPress error, so you can properly upload files to your Media Library again. The potential solutions are as simple as adjusting a few settings via File Transfer Protocol (FTP) and making a call to your hosting provider.
In this article, we’ll explain why you may be seeing the “Upload: Failed to Write File to Disk” error on your WordPress site. Then we’ll walk you through three potential solutions to get your workflow back on track.
Let’s get to it!
Why You’re Seeing the “Upload: Failed to Write File to Disk” error in WordPress
Most of the time, the Upload: Failed to Write File to Disk Error is due to a problem with your site’s file permissions. As a security measure, WordPress only enables certain users to modify its files, including the folder that stores uploads.
If the permissions for this folder are set to prevent users from modifying or ‘writing to’ it, then your upload attempts will fail. You can quickly determine if this is the issue by using the Site Health tool.
Navigate to Tools > Site Health in your dashboard, and click on the Info tab. The last dropdown menu will show you the file permissions for a handful of folders, including the uploads directory:
The directory should be set to Writable. If it’s set to Not writable, then you know you’re dealing with a permissions issue.
There are a few other, less common reasons for this problem. When you add a new media file, WordPress stores it in a temporary folder before moving it to the uploads directory. If the temporary folder is full or unavailable, you may see the Upload: Failed to Write File to Disk error.
Additionally, if you’ve used all the disk space on your server that was allotted to you by your hosting plan, you may see this error. In this case, it’s your server’s way of telling you there’s no more room for additional files.
How to Fix the Upload: Failed to Write File to Disk Error in WordPress (3 Potential Solutions)
Fixing the Upload: Failed to Write File to Disk error is fairly simple. Here are three solutions for tackling this issue, based on the root cause.
1. Change the File Permissions of Your Uploads Directory
If you’ve used the Site Health tool to determine that your Upload: Failed to Write File to Disk error is due to incorrect permissions, you’ll need to use File Transfer Protocol (FTP) to fix it. If you’re unfamiliar with this process, we have a full guide on how to get started.
You’ll need an FTP client such as FileZilla installed on your computer (if you want to show hidden files here is the trick). You’ll also require your FTP credentials, which you should be able to find in your hosting account dashboard.
Kinsta customers can find theirs directly in MyKinsta, by navigating to Sites, clicking on the relevant domain, and looking under SFTP/SSH in the Info tab:
Enter your credentials in your FTP client and launch your connection to the server. Then navigate to your uploads directory in public_html > wp-content:
Right-click on the folder, and then select File Permissions:
A numeric system is used to determine the permissions settings for your site’s files. Your uploads directory should be set to 755:
Click on the OK button to save your new permissions settings. Then return to your WordPress site.
If you check the Site Health tool again, your uploads folder should now be listed as Writable:
At this point, you should be able to upload files to your WordPress site without issue.
2. Empty the WordPress Temporary Folder
If file permissions aren’t your problem, you may want to try emptying the temporary folder WordPress uses to upload files to your site. Unfortunately, you can’t access this directory via FTP.
Instead, you’ll need to contact your hosting provider to help you with this task. The support team should be able to access this hidden file on your server and determine if it’s full or otherwise causing the Upload: Failed to Write File to Disk error.
3. Upgrade Your Hosting Plan to Access More Disk Space
It’s also possible that you’ve used up all the disk space provided by your hosting plan (here’s how to check disk usage in WordPress). This is particularly likely if your site is on a shared server and has grown over time through the addition of posts and pages, plugins, themes, and so on.
Most hosting accounts will list how much disk space you’re currently using. Kinsta customers can find this information in their MyKinsta dashboard, under Resource usage:
Fortunately, the solution to this problem is very simple. If you’re maxing out your site’s current allotment of disk space, all you need to do is upgrade to a new hosting plan. Your provider should offer clear documentation on how to switch over to a new package.
Is your site experiencing the “Upload: Failed to Write File to Disk” error? Bummer… but it’s usually an easy fix. Check out these three methods to fix the problem and get back to uploading files again ⬆️📦Click to Tweet
Summary
Resolving the Upload: Failed to Write File to Disk error in WordPress quickly is key to making sure this issue doesn’t slow down your business. To fix this error, here are the three most common potential solutions:
- Check the file permissions of your uploads directory.
- Empty the WordPress temporary folder.
- Upgrade your hosting plan to access more disk space.
Get all your applications, databases and WordPress sites online and under one roof. Our feature-packed, high-performance cloud platform includes:
- Easy setup and management in the MyKinsta dashboard
- 24/7 expert support
- The best Google Cloud Platform hardware and network, powered by Kubernetes for maximum scalability
- An enterprise-level Cloudflare integration for speed and security
- Global audience reach with up to 35 data centers and 275+ PoPs worldwide
Test it yourself with $20 off your first month of Application Hosting or Database Hosting. Explore our plans or talk to sales to find your best fit.
zerat
31.05.16
✎
09:23
Всем привет! Выгружаем данные на сайт, выгрузка не проходит в журнале регистрации следующая ошибка
Интерактивный обмен
30.05.2016 18:32:07 Запуск выгрузки товаров
30.05.2016 18:56:48 Выгрузка на сайт завершилась с ошибками.
Произошла ошибка: Не удалось записать zip-архив на диск!
Произошла ошибка: Не удалось очистить каталог обмена: C:\Users\chmel\AppData\Local\Temp\3\webdata
30.05.2016 18:56:49 Завершена выгрузка товаров
zerat
31.05.16
✎
09:24
Не могу понять где прописан данный путь для сохранения…
Вроде все права на запись есть…
AceVi
31.05.16
✎
09:33
(1) Путь не прописан — это «временные файлы 1С»
файлы там появляються например вот так —
ГдеИскать = КаталогВременныхФайлов();
zerat
31.05.16
✎
10:16
(2) а в чем может быт причина данной ошибки?
AceVi
31.05.16
✎
10:32
(3) База клиент серверная?
проверь права пользователя под которым запускаеться служба 1С — у него нет прав на твою папку значит. просто все действия с файлами выполняются на стороне «сервера» и с правами пользователя запускающего службу 1С.
zerat
31.05.16
✎
10:50
(4) файловая база
AceVi
31.05.16
✎
11:04
(5) А вот так сложно сказать.
Проверяй права, chmel — это же твой пользователь?
у тебя должны быть права на эту папку. попробуй вручную записать туда файл.
If your site is encountering the “Upload: Failed to Write File to Disk” error, it can be more than annoying because you’re not able to upload new files until you’ve fixed.
Fortunately, there are a few steps you can take to resolve this WordPress error, so you can properly upload files to your Media Library again. The potential solutions are as simple as adjusting a few settings via File Transfer Protocol (FTP) and making a call to your hosting provider.
In this article, we’ll explain why you may be seeing the “Upload: Failed to Write File to Disk” error on your WordPress site. Then we’ll walk you through three potential solutions to get your workflow back on track.
Let’s get to it!
Why You’re Seeing the “Upload: Failed to Write File to Disk” error in WordPress
Most of the time, the Upload: Failed to Write File to Disk Error is due to a problem with your site’s file permissions. As a security measure, WordPress only enables certain users to modify its files, including the folder that stores uploads.
If the permissions for this folder are set to prevent users from modifying or ‘writing to’ it, then your upload attempts will fail. You can quickly determine if this is the issue by using the Site Health tool.
Navigate to Tools > Site Health in your dashboard, and click on the Info tab. The last dropdown menu will show you the file permissions for a handful of folders, including the uploads directory:
The directory should be set to Writable. If it’s set to Not writable, then you know you’re dealing with a permissions issue.
There are a few other, less common reasons for this problem. When you add a new media file, WordPress stores it in a temporary folder before moving it to the uploads directory. If the temporary folder is full or unavailable, you may see the Upload: Failed to Write File to Disk error.
Additionally, if you’ve used all the disk space on your server that was allotted to you by your hosting plan, you may see this error. In this case, it’s your server’s way of telling you there’s no more room for additional files.
How to Fix the Upload: Failed to Write File to Disk Error in WordPress (3 Potential Solutions)
Fixing the Upload: Failed to Write File to Disk error is fairly simple. Here are three solutions for tackling this issue, based on the root cause.
1. Change the File Permissions of Your Uploads Directory
If you’ve used the Site Health tool to determine that your Upload: Failed to Write File to Disk error is due to incorrect permissions, you’ll need to use File Transfer Protocol (FTP) to fix it. If you’re unfamiliar with this process, we have a full guide on how to get started.
You’ll need an FTP client such as FileZilla installed on your computer (if you want to show hidden files here is the trick). You’ll also require your FTP credentials, which you should be able to find in your hosting account dashboard.
Kinsta customers can find theirs directly in MyKinsta, by navigating to Sites, clicking on the relevant domain, and looking under SFTP/SSH in the Info tab:
Enter your credentials in your FTP client and launch your connection to the server. Then navigate to your uploads directory in public_html > wp-content:
Right-click on the folder, and then select File Permissions:
A numeric system is used to determine the permissions settings for your site’s files. Your uploads directory should be set to 755:
Click on the OK button to save your new permissions settings. Then return to your WordPress site.
If you check the Site Health tool again, your uploads folder should now be listed as Writable:
At this point, you should be able to upload files to your WordPress site without issue.
2. Empty the WordPress Temporary Folder
If file permissions aren’t your problem, you may want to try emptying the temporary folder WordPress uses to upload files to your site. Unfortunately, you can’t access this directory via FTP.
Instead, you’ll need to contact your hosting provider to help you with this task. The support team should be able to access this hidden file on your server and determine if it’s full or otherwise causing the Upload: Failed to Write File to Disk error.
3. Upgrade Your Hosting Plan to Access More Disk Space
It’s also possible that you’ve used up all the disk space provided by your hosting plan (here’s how to check disk usage in WordPress). This is particularly likely if your site is on a shared server and has grown over time through the addition of posts and pages, plugins, themes, and so on.
Most hosting accounts will list how much disk space you’re currently using. Kinsta customers can find this information in their MyKinsta dashboard, under Resource usage:
Fortunately, the solution to this problem is very simple. If you’re maxing out your site’s current allotment of disk space, all you need to do is upgrade to a new hosting plan. Your provider should offer clear documentation on how to switch over to a new package.
Is your site experiencing the “Upload: Failed to Write File to Disk” error? Bummer… but it’s usually an easy fix. Check out these three methods to fix the problem and get back to uploading files again ⬆️📦Click to Tweet
Summary
Resolving the Upload: Failed to Write File to Disk error in WordPress quickly is key to making sure this issue doesn’t slow down your business. To fix this error, here are the three most common potential solutions:
- Check the file permissions of your uploads directory.
- Empty the WordPress temporary folder.
- Upgrade your hosting plan to access more disk space.