Приветствую.
Столкнулся с непонятно проблемой создания файлов от несуществующих юзеров.
Debian 10, на серваке нет ничего кроме docker и docker-compose.
Права на запуск выставлены по мануалу, все как всегда как и на других серваках на которых нет данной проблемы.
Систему сетапил не я, а админ, поэтому за настройку ничего не могу сказать. Хотя система была передана мне вроде как нулевая. На всех впсках установленных собственноручно, в том числе и локально такого бага нет.
Что конкретно происходит.
В контенерах, на разделах примонтированных с хоста, создаются файлы от несущестующих пользователь с несуществующими uid. В связи с чем они становятся недоступны без прав 777.
На хосте только юзер root и www-data, в докере в контейнерах тоже самое root и www-data.
К примеру Laravel создает файл сессии в папку storage от юзера 13330 (???)
Захожу в контейнер php, в эту же папку и выполняю touch empty.file - файл создается от root.
Если делаю тоже самое через php скрипт (в том же контейнере), создается от www-data, все как и положено.
Какого черта и откуда появляются эти uid. Причем на разных серверах разные uid. Все уже перепробовал. Причем юмор в том, что эти файлы от юзера 13330 недоступны для записи даже на хосте от root. Только после применения chown.
сергей кузьмин, Написал же что они и так соответствуют и uid и имя. root(0), www-data(33).
Дело в чем то другом. На всех многочисленных серваках, настроенных мной, таких проблем нет. Поэтому я слабо представляю даже куда дальше копать.
Почему на хосте может "сбиваться" uid? С поправкой на то что образы настроены 100% верно и на других машинах запускаются без проблем
спасибо за фидбек. вы уверены что uid на хосте где запускается контейнер и внутри один и тот же - то есть создаете юзера вы сами в докерфайле используя переменные которые заплолнятся из $(id -u) (например)?
Нашел не там где ожидал.
Это юзер www-data в fpm образе который почему то из 33 стал 13330, хотя не понятно что fpm пытается писать в раздел с логами, учитывая что он не примонтирован к этой директории (на которую ругается). Чушь какая то.
Посмотрел также www-data в других образах. Например в nginx. В нем www-data вообще 82.
Из за этого и происходит пермишн денайд. Как это пофиксить я понял, нужно задать соответствие юзера на хосте и в контейнере. Но как я без запуска контейнера и без просмотра passwd узнаю какой uid кому соответствует в каждом образе. Образы взяты официальные с хаба.
Причем в конкретном случае получается так, что для fpm соответствие 33:13330, а для nginx в этом же блоке сервисов 0:82, потому что без рута нгинкс не имеет возможности записывать в системную папку внутри контейнера (??????).
Сложный
Простой
