Ошибка su: файл занят (в английской локали — device or resource busy либо text file busy) появляется при попытке заменить, удалить или перезаписать исполняемый файл su, который в этот момент используется запущенным процессом. Чаще всего с ней сталкиваются при обновлении бинарника суперпользователя на Android-устройстве с root-доступом или при ручной правке системных файлов в Linux. Пока хотя бы один процесс держит файл открытым или выполняет его, ядро блокирует запись — это штатный защитный механизм, а не признак поломки.
Проблема решается без переустановки системы: нужно определить, какой процесс удерживает файл, корректно завершить его и только потом повторить операцию. Ниже разберём причины ошибки, способы диагностики и безопасный порядок действий для разных сценариев.
Почему система сообщает, что файл su занят
Ядро Linux не позволяет изменять исполняемый файл, пока он загружен в память как работающая программа или открыт другим процессом. Это касается и бинарника su, который на рутированном Android постоянно задействован фоновыми службами: демоном суперпользователя, приложениями с root-правами, скриптами инициализации.
Типичные ситуации, приводящие к ошибке:
- 🔒 Запущенный демон su — фоновый процесс суперпользователя удерживает бинарник в памяти, и любая попытка перезаписи блокируется ядром.
- 📱 Активное приложение с root-доступом — файловый менеджер, терминал или твикер выполняет команду через
suпрямо в момент замены файла. - 🛡️ Системный монт в режиме только для чтения — раздел
/systemили/system/xbinсмонтирован как ro, и запись невозможна независимо от занятости файла. - ⚙️ Ограничения SELinux — принудительный режим (enforcing) запрещает изменение системных исполняемых файлов даже при наличии root-прав.
Важно различать две похожие ошибки. Сообщение text file busy (код ETXTBSY) означает именно выполнение файла процессом, а device or resource busy (EBUSY) чаще указывает на занятую точку монтирования или открытый дескриптор. Диагностика в обоих случаях схожая, но второй вариант иногда требует перемонтирования раздела.
Как определить, какой процесс удерживает файл
Прежде чем что-либо менять, нужно выяснить, кто именно держит бинарник. Для этого в Linux и Android (через эмулятор терминала или adb shell) есть штатные инструменты. Работать с ними безопасно — команды только читают информацию о процессах.
Основная команда для поиска процессов, открывших файл:
fuser -v /system/xbin/suПуть может отличаться в зависимости от устройства и способа получения root: встречаются варианты /system/bin/su, /system/xbin/su, /sbin/su или расположение внутри структуры менеджера root-доступа. Уточнить фактическое расположение помогает команда which su, выполненная в терминале с правами суперпользователя.
Если утилита fuser недоступна (на «голом» Android её часто нет), альтернативой служит просмотр открытых дескрипторов через lsof либо ручной поиск по каталогу /proc. Также полезно проверить список процессов командой ps и найти в нём демоны с упоминанием su или daemonsu.
Безопасный порядок действий при замене бинарника su
Универсального скрипта не существует: расположение файлов, названия демонов и структура разделов зависят от версии Android, прошивки и используемого решения для root (Magisk, SuperSU и их аналоги работают по-разному). Поэтому ниже — общий безопасный алгоритм, который нужно адаптировать под конкретное устройство по официальной документации вашего root-решения.
☑️ Порядок замены бинарника su
Логика каждого шага такова. Сначала вы локализуете файл и выясняете, кто его использует — это исключает действия вслепую. Затем корректно останавливаете демон суперпользователя: у большинства менеджеров root есть штатный способ перезапуска службы, описанный в их документации. Грубое принудительное завершение через kill — крайняя мера, так как обрыв демона на полуслове может оставить систему без работающего root до перезагрузки.
Далее проверяется режим монтирования раздела. Если раздел смонтирован только для чтения, его необходимо перемонтировать с правом записи:
mount -o remount,rw /system⚠️ Внимание: на современных версиях Android с динамическими разделами и механизмом AVB/dm-verity прямая запись в системный раздел может быть заблокирована на уровне загрузчика, а её принудительный обход способен нарушить целостность проверки и привести к невозможности загрузки устройства. Предпочтительный путь — использовать штатные механизмы обновления вашего root-решения, которые работают через systemless-подход и не изменяют системный раздел.
После успешной замены обязательно проверьте результат: выполните в терминале команду su -c id и убедитесь, что в ответ приходит строка с uid=0. Если ответа нет или появляется новая ошибка — немедленно верните резервную копию файла на место.
Особенности ошибки в настольных Linux-дистрибутивах
В обычных дистрибутивах Linux бинарник su поставляется пакетом (как правило, из состава util-linux) и обновляется штатно через пакетный менеджер. Ошибка занятости здесь возникает реже и почти всегда означает, что в момент обновления или ручной замены файла кто-то выполняет su — например, открыта сессия с повышенными правами в другом терминале или работает скрипт.
Диагностика стандартная: fuser или lsof по пути /bin/su (либо /usr/bin/su — зависит от дистрибутива) покажут номера процессов. Завершите открытые su-сессии командой exit в соответствующих терминалах и повторите операцию. Если процесс завис и не завершается штатно, его можно завершить по PID, но сначала убедитесь, что это не критичная системная задача.
Отдельный случай — обновление пакета, содержащего su, через пакетный менеджер. Здесь не нужно ничего удалять вручную: менеджер пакетов сам корректно заменяет файлы. Если обновление прерывается ошибкой занятости, достаточно закрыть активные su-сессии и запустить обновление повторно.
Частые ошибки, которые усугубляют проблему
Пытаясь быстро избавиться от сообщения, пользователи нередко предпринимают действия, которые превращают легко решаемую ситуацию в потерю root-доступа или нестабильную систему. Ниже — то, чего делать не стоит.
| Действие | Чем грозит | Правильная альтернатива |
|---|---|---|
| Принудительное удаление занятого su | Потеря root-доступа до восстановления файла | Сначала завершить процессы, потом заменять |
| Убийство всех процессов подряд через kill -9 | Зависание системы, повреждение данных | Точечное завершение по PID из fuser |
| Перезапись файла без резервной копии | Невозможность отката при неудаче | Копия исходника в пользовательский раздел |
| Игнорирование режима монтирования ro | Повторная ошибка записи, путаница в причинах | Проверка mount и перемонтирование в rw |
| Отключение SELinux ради одной операции | Снижение защиты всей системы | Использование штатных механизмов root-решения |
⚠️ Внимание: никогда не удаляйте бинарник su «чтобы потом поставить новый». Если установка нового файла по какой-то причине не завершится (сбой записи, разряд батареи, ошибка в скрипте), устройство останется без работающего суперпользователя, и восстановление может потребовать перепрошивки. Замену выполняйте атомарно: сначала положите новый файл рядом под другим именем, проверьте его, и только затем переименуйте.
Если ошибка возникает внутри root-приложения или скрипта
Иногда сообщение о занятом файле выдаёт не терминал, а приложение с root-правами — файловый менеджер, бэкап-утилита или скрипт автоматизации. В этом случае конфликт обычно происходит между самим приложением и демоном su: программа пытается модифицировать системный файл, который в этот момент обслуживает её же root-запросы.
Порядок действий здесь мягче. Закройте все приложения, которым выданы root-права, затем в настройках вашего менеджера root-доступа перезапустите его службу, если такая функция предусмотрена. После этого повторите операцию в одном приложении, не запуская параллельно другие root-инструменты. Одновременная работа двух программ, конкурирующих за один и тот же системный файл, — частый, но редко озвучиваемый источник ошибки.
Если ошибка воспроизводится стабильно при одном и том же действии, проверьте логи: на Android их можно посмотреть через logcat, в Linux — через journalctl или системный журнал. Записи рядом с моментом ошибки часто указывают конкретный процесс или запрет SELinux, который её вызвал.
Что означает код ETXTBSY и почему ядро блокирует запись
Код ошибки ETXTBSY («text file busy») возвращается системным вызовом, когда процесс пытается открыть на запись файл, который в данный момент выполняется как программа. Исторически «text» здесь означает сегмент кода исполняемого файла. Ядро удерживает страницы памяти работающей программы связанными с файлом на диске; если разрешить запись в этот файл, выполняющийся код изменится прямо во время работы, что привело бы к падению процесса или непредсказуемому поведению. Поэтому блокировка — осознанная мера защиты, и обходить её нужно через корректное завершение процесса, а не через обходные трюки.
Восстановление, если замена прошла неудачно
Если после манипуляций команда su перестала работать — не запускается, выдаёт ошибку сегментации или отказывает в правах, — первым делом верните резервную копию. Если копия сохранялась в пользовательском разделе, потребуется любой способ записи в системный раздел: работающий root из другого источника, кастомное рекавери (если оно установлено и поддерживает монтирование разделов) или перепрошивка root-решения заново.
Когда root утерян полностью и ни один способ записи недоступен, наиболее надёжный путь — повторная установка вашего root-решения по его официальной инструкции: для Magisk это, как правило, прошивка пропатченного образа загрузки, для других решений — их штатные процедуры. Конкретные шаги зависят от модели устройства и версии прошивки, поэтому сверяйтесь с документацией именно вашего устройства.
Часто задаваемые вопросы
Можно ли удалить занятый файл su принудительно?
Технически удаление (unlink) иногда возможно, даже когда запись заблокирована, но делать этого не стоит: запущенные процессы продолжат использовать старый файл из памяти, а новый root-доступ вы не получите до установки рабочего бинарника. Если установка сорвётся, устройство останется без su. Правильный путь — завершить удерживающие процессы и выполнить замену корректно.
Почему ошибка возникает сразу после перезагрузки?
Демон суперпользователя и root-приложения с автозапуском стартуют вместе с системой и сразу «захватывают» бинарник. Если вы заменяете su сразу после загрузки, дождитесь полного завершения автозапуска и закройте все приложения с root-правами перед операцией.
Ошибка «файл занят» и «только для чтения» — это одно и то же?
Нет. Read-only file system означает, что раздел смонтирован без права записи — решается перемонтированием в режим rw (если это позволяет конфигурация устройства). File busy означает, что файл используется процессом — решается завершением процесса. Возможна и комбинация обеих проблем, тогда устранять их нужно последовательно.
Как узнать точный путь к бинарнику su на моём устройстве?
Выполните в терминале команду which su от имени суперпользователя. Также можно проверить типичные расположения: /system/bin, /system/xbin, /sbin. У systemless-решений файл может находиться в виртуальной структуре, создаваемой менеджером root, — в этом случае ориентируйтесь на документацию вашего решения.
Поможет ли сброс устройства до заводских настроек?
Сброс данных (factory reset) не восстанавливает системный раздел и не вернёт повреждённый или удалённый бинарник su — он лишь очищает пользовательские данные. Для восстановления системных файлов требуется перепрошивка или переустановка root-решения по официальной инструкции для вашей модели.