Комментарии 17
man cp
-a, --archive
По возможности сохраняет структуру и атрибуты исходных файлов при копировании. Эквивалентно заданию опций -dpPR.
И нет никаких проблем при переносе. Более того, можно для /var/lib/docker использовать симлинк или монтирование в папку. Это позволит не менять конфигурацию самого docker.
-a, --archive
По возможности сохраняет структуру и атрибуты исходных файлов при копировании. Эквивалентно заданию опций -dpPR.
И нет никаких проблем при переносе. Более того, можно для /var/lib/docker использовать симлинк или монтирование в папку. Это позволит не менять конфигурацию самого docker.
Да, изначально человек, выполняющий перенос, не добавил нужный ключ. Но в дальнейшем, даже rsync не спас ситуацию, я в статье об этом писал.
Из интересного — стоит сравнить файловые системы. И проверить, что acl действительно не используются. Кстати, какие из папок tmp у вас настоящие, а — какие симлинки/хардлинки?
Есть определенные проблемы с доступом к серверу, дело в том, что у меня рутового доступа нет. И я лишь осуществляю составление инструкций, по которым человек выполняет действия. Энтерпрайз, все дела..=(
Но я задумал поднять аналогичную лабораторную среду у себя дома и попробовать воссоздать проблему. По результатам, если их получу, обязательно отпишусь.
Но я задумал поднять аналогичную лабораторную среду у себя дома и попробовать воссоздать проблему. По результатам, если их получу, обязательно отпишусь.
Сообщаем докер демону, чтобы смотрел в новую директорию. Тут два пути: либо через флаг -g указать демону на новый путь, либо конфиги systemd
На самом деле, есть ещё как минимум два варианта:
1. Симлинк (мы его используем): ln -s /data/docker /var/lib/docker.
2. Монтировать большой раздел для докера сразу в /var/lib/docker.
rsync -av --numeric-ids
ну или просто mv.
> То есть, каким-то загадочным образом у нас побились права
Ничего загадочного тут нет, cp -r копирует, меняя все права на те, которые в umask указаны, делая при этом chown на текущего пользователя. А у вас там nginx от www-data куда-то писать хочет внутри контейнера.
> В одной из строк вывода мы должны увидеть:
Правильно смотреть в docker info | awk '/Root Dir/ {print $NF}'
> Докер образ же не менялся.
Менялся. Локально он хранится уже распакованным, так что права внутри него побились.
ну или просто mv.
> То есть, каким-то загадочным образом у нас побились права
Ничего загадочного тут нет, cp -r копирует, меняя все права на те, которые в umask указаны, делая при этом chown на текущего пользователя. А у вас там nginx от www-data куда-то писать хочет внутри контейнера.
> В одной из строк вывода мы должны увидеть:
Правильно смотреть в docker info | awk '/Root Dir/ {print $NF}'
> Докер образ же не менялся.
Менялся. Локально он хранится уже распакованным, так что права внутри него побились.
Спасибо за ваш комментарий, люблю, когда много и по делу! =)
Я тоже подумал про umask. Мы удалили новый каталог и сделали rsync -a со старого. И проблема сохранилась.
В целом, я думаю можно дополнить вашим подходом мой. То есть сначала проверяем отработал ли конфиг, и передались ли опции демону при старте. А потом уже смотрим инфо докер демона. Спасибо, я дополню статью!
К такому же выводу я и пришел, единственное, я не понял причины. Потому что каталог источник мы не трогали. И rsync с сохранением аттрибутов\прав с данного каталога не принес победы…
Ничего загадочного тут нет, cp -r копирует, меняя все права на те, которые в umask указаны, делая при этом chown на текущего пользователя. А у вас там nginx от www-data куда-то писать хочет внутри контейнера.
Я тоже подумал про umask. Мы удалили новый каталог и сделали rsync -a со старого. И проблема сохранилась.
Правильно смотреть в docker info | awk '/Root Dir/ {print $NF}'
В целом, я думаю можно дополнить вашим подходом мой. То есть сначала проверяем отработал ли конфиг, и передались ли опции демону при старте. А потом уже смотрим инфо докер демона. Спасибо, я дополню статью!
Менялся. Локально он хранится уже распакованным, так что права внутри него побились.
К такому же выводу я и пришел, единственное, я не понял причины. Потому что каталог источник мы не трогали. И rsync с сохранением аттрибутов\прав с данного каталога не принес победы…
tldr.
--numeric-ids rsync-у говорили? Если нет — сменился владелец, т.к. UID-ы внутри контейнера и в хост-системе разные. И в образах (распакованных), и в артефактах.
(как вариант, -HAX ещё пробовать, если там на хардлинки/acl/xattr что-то завязано, но здесь скорее всего не тот случай, т.к. три топора всё починили).
--numeric-ids rsync-у говорили? Если нет — сменился владелец, т.к. UID-ы внутри контейнера и в хост-системе разные. И в образах (распакованных), и в артефактах.
(как вариант, -HAX ещё пробовать, если там на хардлинки/acl/xattr что-то завязано, но здесь скорее всего не тот случай, т.к. три топора всё починили).
--numeric-ids rsync-у говорили? Если нет — сменился владелец, т.к. UID-ы внутри контейнера и в хост-системе разные. И в образах (распакованных), и в артефактах.
А вот это я не учел, ваша правда! Попробую воссоздать в лабораторных условиях. Спасибо!
Кстати, у меня то проблема не с тем что слетел владелец\группа. В моем случае проблема именно с правами.
масса деталей не расписана.
Не указана ФС корня и нового раздела, на который переносится сторадж.
Если использовался btrfs, то простой rsync уже не позволит повторить структуру сабволумов
Еще бывают чудесные вещи при storage driver aufs, когда все права позволяют, а писать в каталог невозможно. Похоже, это ваш случай.
Не указана ФС корня и нового раздела, на который переносится сторадж.
Если использовался btrfs, то простой rsync уже не позволит повторить структуру сабволумов
Еще бывают чудесные вещи при storage driver aufs, когда все права позволяют, а писать в каталог невозможно. Похоже, это ваш случай.
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
История проблемы переноса docker storage (docker root)