# GPU доступен root, но не rootless-контейнеру: runtime и права устройств

Диагностика: GPU доступен root, но не rootless-контейнеру: runtime и права устройств. Признаки, последовательность проверки, рабочий пример и критерии восстановления.

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/rootless-nvidia-cdi-permissions/
Language: ru

Если GPU доступен root-контейнеру, но недоступен rootless запуску, проверьте отдельно daemon configuration, user namespace и способ device injection. Rootless не является обычным rootful Docker с другим пользователем клиента. Переход на privileged не объясняет исходную границу доступа.

## Подтвердите выбранный daemon

Сохраните Docker context, endpoint и режим сервера, к которому обращается команда. Rootless daemon может иметь собственный пользовательский config, отличный от /etc/docker/daemon.json. Успешная настройка rootful runtime не гарантирует применение к пользовательскому daemon. Запишите effective runtime и версии, не выводя лишние credentials context. Перед сравнением убедитесь, что две команды действительно создают контейнеры в разных ожидаемых средах, а не случайно используют один общий rootful endpoint.


[Официальный источник 1](https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/latest/install-guide.html).

## Разделите права и инъекцию

NVIDIA документирует специальную rootless configuration для своего runtime. CDI также улучшает совместимость с rootless-сценариями, но требует корректной спецификации и поддержки engine. Сохраните device nodes, их ownership и разрешённые группы, а также container UID mapping. Видимость пути /dev не равна разрешению открыть устройство. Не переносите частную настройку no-cgroups из одного documented режима на все runtime без понимания: она меняет управление доступом и связана с архитектурой конкретного запуска.


[Официальный источник 2](https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/latest/cdi-support.html).

## Разберите ошибку конфигурации

В учебном случае nvidia-ctk настроил системный Docker daemon, а тест выполняется через пользовательский rootless daemon. GPU на хосте доступен, но нужный runtime пользовательской среде не задан. Сравнение config paths и фактического engine обнаруживает различие. Во втором тесте CDI name найден, однако процесс не имеет требуемого device access. Здесь изменение списка устройств не заменяет проверку UID/GID и разрешений. Это два разных сценария, а не один рецепт «запускать sudo».

| Область | Нужное подтверждение |
| --- | --- |
| Engine | Rootless endpoint действительно выбран |
| Runtime | Конфигурация применяется этому daemon |
| CDI/device | Устройство корректно описано и передано |
| Процесс | Права позволяют открыть его |


[Официальный источник 3](https://docs.docker.com/engine/security/rootless/).

## Выберите поддерживаемую настройку

Следуйте инструкции для конкретного container engine и NVIDIA mode. Изменения делайте в правильном config path и перезапускайте соответствующий user service, если это требуется. Сохраните предыдущие значения и проверьте соседние workload. Не отключайте SELinux, seccomp и cgroups одновременно ради одного успешного запуска: тогда причина останется неизвестной, а доступ расширится сразу на нескольких слоях. Требуемые права должны быть минимальными и связаны с наблюдаемой операцией устройства.

## Повторите проверку без root

Создайте новый тестовый контейнер из закреплённого образа и подтвердите UUID, затем небольшой compute result. Сохраните daemon endpoint, injection mode и process identity. Успешный rootful тест остаётся контрольным наблюдением, а не подтверждением rootless configuration. После обновления engine или Toolkit повторите scope проверки, особенно CDI refresh и доступ к nodes. Итоговый артефакт должен позволять повторить запуск нужным пользователем без скрытой зависимости от интерактивного sudo или случайного выбора другого daemon.

Связанные разборы: [gpu containers vs vms](/ru/journal/gpu-containers-vs-vms/); [hardware security](/ru/journal/hardware-security/).