В этом материале
Если GPU доступен root-контейнеру, но недоступен rootless запуску, проверьте отдельно daemon configuration, user namespace и способ device injection. Rootless не является обычным rootful Docker с другим пользователем клиента. Переход на privileged не объясняет исходную границу доступа.
Если 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.
Разделите права и инъекцию
NVIDIA документирует специальную rootless configuration для своего runtime. CDI также улучшает совместимость с rootless-сценариями, но требует корректной спецификации и поддержки engine. Сохраните device nodes, их ownership и разрешённые группы, а также container UID mapping. Видимость пути /dev не равна разрешению открыть устройство. Не переносите частную настройку no-cgroups из одного documented режима на все runtime без понимания: она меняет управление доступом и связана с архитектурой конкретного запуска.
Разберите ошибку конфигурации
В учебном случае 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 | Устройство корректно описано и передано |
| Процесс | Права позволяют открыть его |
Выберите поддерживаемую настройку
Следуйте инструкции для конкретного 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; hardware security.