Команда ./script.sh в терминале OpenWrt возвращает -ash: ./script.sh: Permission denied, хотя файл точно существует и путь указан верно — это классический симптом отсутствия бита исполнения, а не «сломанной» системы. Та же строка Permission denied появляется при подключении по SSH, при попытке записи в файл и при обращении к USB-накопителю, но в каждом случае причина своя.
В этой статье разберём, почему OpenWrt отказывает в доступе, как отличить проблему прав файла от проблемы аутентификации, и какие команды помогут локализовать источник ошибки. Материал ориентирован на стандартную прошивку OpenWrt с оболочкой ash (BusyBox), но общие принципы применимы к любой Linux-системе на роутере.
Что означает ошибка Permission denied в OpenWrt
Сообщение Permission denied («отказано в доступе») ядро Linux возвращает, когда процесс пытается выполнить действие, на которое у него нет полномочий: прочитать чужой файл, записать в защищённый каталог или запустить файл без флага исполнения. В OpenWrt чаще всего работа идёт под пользователем root, поэтому ошибка обычно указывает не на «чужой» файл, а на отсутствие атрибута исполнения, файловую систему, смонтированную только для чтения, или ограничения на уровне монтирования.
Важно различать три типовые ситуации. Первая — отказ при запуске скрипта или бинарника. Вторая — отказ при входе по SSH (здесь Permission denied выдаёт уже сервер dropbear, и речь об аутентификации). Третья — отказ при записи или удалении файла. Диагностика для каждого случая разная, поэтому первый шаг — точно понять, в какой момент появляется сообщение.
Диагностика: какие команды выполнить в первую очередь
Прежде чем что-то менять, соберите информацию. Проверьте права на файл, тип файловой системы и текущего пользователя — этого достаточно, чтобы в большинстве случаев понять причину.
ls -l /путь/к/файлу
whoami
mount | grep " / "
df -h
Вывод ls -l покажет владельца и права в формате вида -rw-r--r--. Если в строке нет буквы x — файл не исполняемый, и попытка запуска через ./файл закономерно даст отказ. Команда mount покажет, не смонтирован ли раздел с флагом ro (read-only) или noexec, а df -h — не переполнен ли раздел, что иногда приводит к сбоям записи.
- 🔍
ls -l— владелец и права доступа к файлу или каталогу - 👤
whoami— под каким пользователем вы работаете сейчас - 💾
mount— режим монтирования разделов (ro, noexec) - 📊
df -h— свободное место на разделах - 🧩
file /путь/к/бинарнику— подходит ли архитектура исполняемого файла
Ошибка при запуске скрипта или программы
Самая частая причина — у файла нет бита исполнения. Это происходит, когда скрипт скопирован через SCP/WinSCP с Windows-машины, распакован из архива или создан текстовым редактором. Исправляется одной командой:
chmod +x /путь/к/скрипту.shВторая по распространённости причина — раздел смонтирован с опцией noexec. На OpenWrt это типично для съёмных носителей: даже с выставленным chmod +x запуск с такого раздела будет отклонён. Проверить можно командой mount | grep /mnt. Решение — перемонтировать без noexec или перенести исполняемый файл в системный раздел, например в /root или /usr/bin.
Третий сценарий — бинарник собран под другую архитектуру или другую стандартную библиотеку. OpenWrt использует musl вместо glibc, поэтому программа, собранная под обычный десктопный Linux, на роутере может не запуститься. Правда, в этом случае чаще встречается ошибка not found, но на части сборок проявляется и отказ в доступе. Проверяйте, что пакет установлен через opkg именно для вашей версии прошивки.
Permission denied при подключении по SSH
Когда ssh root@192.168.1.1 отвечает Permission denied, please try again или Permission denied (publickey), проблема в аутентификации, а не в правах файловой системы. Здесь есть несколько типовых вариантов.
Во-первых, неверный пароль — в том числе из-за раскладки клавиатуры или пароля, который ещё не был задан. В свежей прошивке до установки пароля SSH-доступ может быть ограничен: сначала зайдите через веб-интерфейс LuCI и задайте пароль root. Во-вторых, если настроен вход по ключу, сервер dropbear ищет публичный ключ в файле /etc/dropbear/authorized_keys. Отсутствие ключа в этом файле или неверные права на него приводят к отказу publickey.
# На роутере проверьте наличие и права файла ключей
ls -l /etc/dropbear/authorized_keys
При необходимости выставьте права
chmod 600 /etc/dropbear/authorized_keys
Ещё одна возможная причина — в настройках dropbear отключён вход по паролю (PasswordAuth) или по ключу, либо ограничен интерфейс, на котором слушает сервер. Эти параметры видны в LuCI в разделе настроек SSH или в файле /etc/config/dropbear. Сверяйте их с тем, как именно вы подключаетесь.
⚠️ Внимание: не отключайте проверку ключей и не открывайте SSH на WAN-интерфейсе «для проверки». Доступ к управлению роутером из внешней сети без необходимости — прямой риск компрометации устройства.
Отказ при записи файлов и установке пакетов
Если opkg install завершается ошибками записи, а редактор не может сохранить файл, проверьте три вещи: не переполнен ли раздел, не перешла ли файловая система в режим только для чтения из-за ошибок, и не пытаетесь ли вы писать в область, которая по задумке доступна только для чтения (например, части /rom).
OpenWrt использует оверлейную файловую систему: базовый образ в /rom неизменяем, а все изменения пишутся в overlay. Если раздел overlay заполнен, запись начнёт отказывать — очистка места через удаление ненужных пакетов и логов часто полностью снимает проблему. Посмотреть заполнение можно командой df -h /overlay.
При подозрении на ошибки файловой системы загляните в журнал ядра:
dmesg | tail -30
logread | tail -30
Строки про I/O error или перемонтирование в ro укажут на проблемы с флеш-памятью или накопителем. В таком случае сначала сохраните важные данные, а уже потом предпринимайте дальнейшие шаги.
☑️ Быстрая проверка при Permission denied
Ошибки доступа к USB-накопителям и сетевым шарам
При подключении флешки или внешнего диска к OpenWrt отказ в доступе часто связан с типом файловой системы. Разделы NTFS и exFAT требуют отдельных пакетов (например, драйверов соответствующих ФС), а права на файлы в них не управляются стандартным chmod — поддержка POSIX-прав зависит от драйвера и опций монтирования. На FAT32 атрибутов исполнения нет в принципе, поэтому запуск скриптов с такого носителя невозможен без перемонтирования с особыми опциями.
Для сетевых ресурсов (NFS, SMB) добавляется ещё один слой: права проверяются и на стороне сервера. Если на роутере файл выглядит доступным, но запись отклоняется, проверяйте настройки шары и пользователя, под которым выполнено монтирование.
| Ситуация | Вероятная причина | Что проверить |
|---|---|---|
| Запуск скрипта | Нет бита исполнения | ls -l, затем chmod +x |
| Запуск с USB | Опция noexec или FAT32 | mount, тип файловой системы |
| Вход по SSH | Пароль или ключ не принят | /etc/dropbear/authorized_keys, настройки dropbear |
| Запись файла | Раздел ro или переполнен | df -h, dmesg |
| Установка пакета | Нет места в overlay | df -h /overlay |
Чего делать не стоит
Распространённая ошибка — «лечить» любой отказ командой chmod 777 на всё подряд. Это не только не решает корневую причину (например, noexec она не снимет), но и открывает лишние права на системные файлы. Выставляйте права точечно и только после того, как поняли, какой именно атрибут мешает.
⚠️ Внимание: не меняйте права и владельца каталогов/etc,/rom,/libрекурсивно. Некорректные права на системные файлы могут привести к тому, что роутер перестанет загружаться, и восстановление потребует failsafe-режима или перепрошивки.
Также не стоит сразу перепрошивать устройство при первой ошибке доступа. В подавляющем большинстве случаев проблема решается диагностикой за несколько минут, а перепрошивка — крайняя мера при повреждении файловой системы.
Когда стандартные методы не помогают
Если права корректны, место есть, файловая система в порядке, а отказ сохраняется, остаются менее частые причины: повреждённый файл (перекачайте или переустановите пакет), несовместимость бинарника с версией прошивки, сбой флеш-памяти. Для пакетов помогает переустановка через opkg install --force-reinstall имя_пакета.
При подозрении на аппаратные проблемы с флеш-памятью ориентируйтесь на записи в dmesg и поведение устройства: повторяющиеся ошибки ввода-вывода — повод сделать резервную копию конфигурации (sysupgrade -b) и готовиться к замене устройства или перепрошивке. Точные процедуры восстановления зависят от модели роутера, поэтому сверяйтесь с официальной документацией OpenWrt для вашего устройства.
Как сохранить конфигурацию перед серьёзными действиями
Выполните команду sysupgrade -b /tmp/backup.tar.gz и скопируйте получившийся архив на компьютер через SCP. В нём содержатся все настройки из /etc/config, и после перепрошивки конфигурацию можно будет восстановить.
Частые вопросы
Почему chmod +x не помогает запустить скрипт?
Скорее всего, раздел смонтирован с опцией noexec — это типично для USB-накопителей. Проверьте вывод mount и либо перемонтируйте раздел без этой опции, либо перенесите скрипт в системный раздел, например в /root.
SSH пишет Permission denied (publickey), хотя ключ добавлен. Что не так?
Проверьте, что публичный ключ находится именно в /etc/dropbear/authorized_keys (а не в ~/.ssh/, как в OpenSSH), и что права на файл — 600. Также убедитесь, что в настройках dropbear не отключён вход по ключу.
Можно ли исправить Permission denied, выставив chmod 777?
Технически иногда это снимает симптом, но делать так не стоит: чрезмерные права создают риски безопасности и не устраняют реальную причину (например, noexec или переполнение раздела). Используйте минимально необходимые права.
Ошибка появляется при установке пакетов через opkg. В чём дело?
Чаще всего переполнен раздел overlay — проверьте df -h /overlay и удалите ненужные пакеты или логи. Реже причина в ошибках файловой системы, которые видны в dmesg.
Скрипт запускается через sh, но не запускается через ./ — это нормально?
Да. Вызов через sh script.sh не требует бита исполнения, а прямой запуск ./script.sh — требует. Если chmod +x выставлен, но запуск всё равно отклонён, проверьте опцию noexec на разделе.