После восстановления у файлов чужой владелец: сверяем UID и GID

Архив восстановили успешно: файлы на месте, размеры совпадают, однако сервис не может читать данные. В ls появился незнакомый владелец или просто число. Содержимое архива могло быть совершенно исправным. Проверять нужно соответствие числовых идентификаторов пользователей между машинами.

Смотреть числа рядом с именами

ls -ln /srv/report-data
stat -c '%n uid=%u gid=%g user=%U group=%G' /srv/report-data/index.db
id reportbot
getent passwd 1042
getent group 1042

Файловая система хранит UID и GID, а отображаемое имя получается через базу учётных записей. Если на исходной машине UID 1042 принадлежал reportbot, а на целевой — другому пользователю, тот же файл будет показан под другим именем. Совпадение имени reportbot при разных UID тоже не означает совпадения владельца.

Составьте небольшую таблицу соответствия до изменения: исходный UID/GID, назначение учётной записи, целевой UID/GID, каталог данных. Источник истины — сохранённый инвентарь старой системы или проверенные метаданные резервной копии. Не выводите назначение неизвестного UID из одного названия файла.

Выбрать стратегию переноса

Для нового окружения иногда удобнее заранее создать сервисные учётные записи с согласованными идентификаторами. На уже используемой машине менять UID пользователя сложнее: под старым числом могут существовать файлы в других местах, задания и работающие процессы. Требуется отдельный план, а не редактирование одного поля.

Если переносится только дерево данных приложения, можно переназначить владельцев в его границах. Сначала остановите запись и проверьте, что путь действительно относится к нужному тому. Ссылки, вложенные монтирования и общие каталоги требуют внимания: широкое рекурсивное chown способно изменить чужие данные.

Сузить изменение

find /srv/report-data -xdev -uid 1042 -print
find /srv/report-data -xdev -gid 1042 -print

Это предварительный просмотр выбранных объектов. -xdev удерживает обход внутри одной файловой системы, но не делает выбор автоматически правильным. Просмотрите результат, число объектов и несколько ACL. После согласования применяйте переназначение только к проверенной выборке с подходящими параметрами утилиты. Сохраните исходные атрибуты для отката.

Если приложение использует именованные ACL, простого изменения owner недостаточно: в ACL тоже участвуют идентификаторы пользователей и групп. Проверьте getfacl на характерных объектах. Права владельца, группы и отдельных записей должны соответствовать одной политике доступа.

Проверить доступ приложения

После изменения сравните числовые атрибуты и выполните штатную операцию сервиса: открыть базу, создать новый отчёт, переименовать временный файл. Чтение от root не подтверждает права reportbot. Новые файлы покажут, правильно ли настроены пользователь запуска, группа каталога и режим создания.

Например, старый index.db получил 1107:1107, новый report.csv тоже создаётся с нужным владельцем, а сервис выполняет запись. Это завершённое восстановление доступа. Если старые файлы работают, а новые опять получают чужую группу, расследуйте источник создания, не повторяйте chown по расписанию.

Откройте программу Linux и Bash для DevOps-инженеров. Настройка пользователей, прав и проверка восстановления входят в подтверждённые результаты курса: это основа переноса данных с сохранением работоспособного доступа.

Ещё по теме

• Общий каталог работает только со старыми файлами: задаём default ACL
• Сверка двух списков в awk: почему NR == FNR ломается на пустом справочнике