Пользователь внутри контейнера не существует на хосте, то, что совместно используется двумя средами, - это UID / GID.Таким образом, внутри контейнера UID может отображаться на appuser, а на вашем хосте тот же UID может отображаться на polkitd.Если вы посмотрите на файл / etc / passwd на хосте и в контейнере, то увидите, что они, вероятно, не совпадают.Это действительно заметно только при использовании монтирования хоста, поскольку в этом сценарии на хосте видны владельцы файлов.
Одно из возможных решений, которое вы можете попробовать, - это монтировать / etc / passwd и / etc / group с хоста.к контейнеру, чтобы у вас были одни и те же пользователи и группы на каждой стороне, но это имеет недостаток в том, что образ может быть создан с пользователем, которого нет на хосте, или, если он существует, он может быть с другим UIDЗначения / GID, при которых файлы в файловой системе принадлежат не тем пользователям.
Мое личное решение - настроить UID / GID внутри контейнера так, чтобы он соответствовал пользователю на хосте, используя скрипт, который я запускаю внутри своей точки входа.,Он сравнивает владельца файла или каталога, который вы монтируете как том, с пользователем в контейнере, и, когда они не совпадают, пользователь контейнера изменяется.Для этого вам нужно запустить контейнер как root, но вы можете перейти от root к вашему appuser в конце точки входа, чтобы выполнить команду контейнера (обычно я использую exec + gosu для этого).Вы можете найти скрипт для этого, fix-perms, а также пример в моем репозитории с базовым изображением на https://github.com/sudo-bmitch/docker-base.