Привет, это снова я. Сегодня расскажу про тот самый «страшный» случай, когда после сбоя диска сервер вроде бы ожил, а вот в админку WordPress попасть не получалось — вместо формы входа выдавало жёсткое Forbidden.
Если ты тоже однажды увидишь эту ошибку — не паникуй. Ниже пошаговый разбор, как я всё починил, с готовыми командами и пояснениями.
Что вообще произошло
На сервере стояла Xubuntu. Из-за сбоя диска при загрузке система упала в initramfs и запустила fsck для проверки и исправления ошибок файловой системы. После того как диск «починился» и ОС загрузилась, я пошёл в админку сайта — и получил ошибку 403 Forbidden от Apache.
Важно понимать: это не «неверный пароль». Ошибка 403 означает, что сервер сознательно блокирует доступ к ресурсу. Чаще всего после fsck «слетают» права на файлы, либо срабатывает защита в .htaccess или плагине безопасности.
Шаг 1. Исправление диска в initramfs
Когда видишь приглашение initramfs и запрос Optimize<y>?, самое правильное — подтвердить все исправления, отвечая y на каждый вопрос. e2fsck сам найдёт и исправит ошибки структуры ext4.
После завершения проверки система покажет сводку: сколько ошибок исправлено, сколько блоков освобождено.
# В среде initramfs fsck запускается автоматически. # На все вопросы вида Optimize? отвечаем y.
Шаг 2. Проверка и выход из initramfs
Когда fsck завершён, нужно убедиться, что диск больше не требует проверки.
fsck /dev/sda5
Если видишь сообщение вроде «The filesystem does not require further checking» или «clean» — всё хорошо.
Теперь можно выходить из initramfs:
exit
Если после exit ты снова попадаешь в initramfs, значит, GRUB пытается грузиться с неправильным UUID. В этом случае через blkid узнай актуальный UUID корневого раздела и временно подставь его в параметры загрузки в меню GRUB.
Шаг 3. Ошибка 403 при входе в админку WordPress
Я открыл whitepingvin.ru/wp-login.php и вместо формы входа увидел:
Forbidden. You don’t have permission to access this resource.
Apache Server at whitepingvin.ru Port 443
Это классическая ситуация после сбоя: Apache блокирует доступ к wp-login.php. Причины — сбитые права на файлы, правила в .htaccess или блокировка со стороны плагина безопасности.
Шаг 4. Диагностика на сервере
У меня был SSH-доступ, поэтому я сразу пошёл проверять логи и права.
1. Статус веб-сервера
systemctl status apache2
Нужно убедиться, что статус — active (running).
2. Права на файлы сайта
ls -la /var/www/html/
Папки должны иметь права 755, файлы — 644. Владелец — www-data (или тот пользователь, от имени которого работает Apache).
3. Логи ошибок Apache
sudo tail -n 50 /var/log/apache2/error.log
В логах я искал строки вроде «client denied by server configuration» или упоминания wp-login.php. Именно они подсказывают, кто именно блокирует доступ.
Шаг 5. Быстрое решение: отключаем «лишние» правила
Чтобы быстро локализовать проблему, я сделал два безопасных действия.
1. Переименовал .htaccess
mv /var/www/html/.htaccess /var/www/html/.htaccess.bak
Это отключает все правила перезаписи и блокировки. После этого страница входа в админку открылась.
2. Временно отключил плагины
mv /var/www/html/wp-content/plugins /var/www/html/wp-content/plugins.off
Если после этого вход работает — виновник находится внутри папки plugins.
Перед любыми изменениями делай бэкап или хотя бы запоминай, что меняешь.
Шаг 6. Восстановление и профилактика
Когда доступ к админке был восстановлен, я:
— Вернул папку плагинов на место:
mv /var/www/html/wp-content/plugins.off /var/www/html/wp-content/plugins
— Восстановил .htaccess (или сгенерировал новый через настройки WordPress).
— Проверил, что права на файлы корректны.
— Сделал бэкап базы данных и файлов сайта.
Частые причины 403 после сбоя
— Сбитые права на файлы (особенно если fsck менял владельца).
— Правила в .htaccess, которые блокируют доступ к wp-login.php.
— Блокировка со стороны плагина безопасности (Wordfence, iThemes и т.п.).
— WAF на стороне хостинга, который сработал на «подозрительную активность».
Чек-лист после восстановления
— Проверить права на файлы и папки (755 для папок, 644 для файлов).
— Сделать полный бэкап базы данных и файлов.
— Проверить работу формы входа и отправку почты с сайта.
— Убедиться, что SSL-сертификат активен и сайт открывается по https.