Ошибки и коды · Инструкция
Docker container: Permission denied на bind mount или volume
Выполните `docker inspect <container>` и найдите проблемный mount в `Mounts`, включая источник и RW-флаг. Внутри контейн
Короткий ответ
Проверьте тип mount, RW-режим и UID/GID процесса контейнера относительно владельца файлов; исправляйте владельца или пользователя точечно, а не маскируйте причину `chmod 777`.
Проверка по порядку
- Выполните `docker inspect <container>` и найдите проблемный mount в `Mounts`, включая источник и RW-флаг.
- Внутри контейнера выполните `id` и `ls -ln <mount-path>` для числовых UID/GID.
- На host сравните владельца/права исходного bind-path или volume data с пользователем контейнера.
Исправление
- Если приложение поддерживает заданный UID/GID, согласуйте его с владельцем данных.
- На SELinux-системах проверьте требуемую Docker-маркировку bind mount (`z`/`Z`) по модели совместного доступа.
- Пересоздайте контейнер и проверьте запись тестового файла от того же пользователя приложения.
Как понять, что исправлено
- Процесс внутри container может читать/писать только нужный mount без chmod 777/privileged, владельцы файлов остаются ожидаемыми.
Важно
chmod 777 и privileged скрывают причину permission denied и расширяют доступ. Исправляйте UID/GID, mount options или security labels точечно.
Что учитывать
chmod 777 и privileged скрывают причину permission denied и расширяют доступ. Исправляйте UID/GID, mount options или security labels точечно.
Источники и проверка
Фактическая часть сверена по первичным источникам (в т.ч. Bind mounts). Пример и формулировки — редакция N1RO на 2026-09-17.