Docker bind propagation: когда нужны rshared и rslave

Что именно распространяется между mount points

Bind mount связывает путь хоста с путём контейнера, но внутри этого дерева позже могут появляться другие mount points. Bind propagation определяет, увидит ли связанная сторона такие новые подмонтирования. Docker по умолчанию использует rprivate: новые mount points не распространяются ни от оригинала к replica, ни обратно. В режиме slave изменения подмонтирований идут от исходного mount к replica, но не в обратную сторону. Shared делает обмен двусторонним. Префикс r означает recursive: правило распространяется и на mount points, вложенные глубже. На практике чаще обсуждают rslave и rshared, потому что без рекурсивности вложенные деревья быстро дают неожиданные пробелы. Важно: это не настройка прав чтения/записи. readonly/ro контролирует запись, а propagation — видимость появляющихся mount points.

Совет: Если проблема решается обычным bind mount и файлы просто меняются, propagation вам, скорее всего, не нужен.

rprivate, rslave, rshared: практическая разница

• rprivate. нет распространения новых submounts. нет. режим по умолчанию, обычные приложения
• rslave. да, рекурсивно. нет. контейнер должен видеть mounts хоста, но не менять дерево хоста
• rshared. да, рекурсивно. да, рекурсивно. специализированные инструменты, которым нужна двусторонняя propagation

Как включить bind propagation и проверить результат

1. Убедитесь, что у вас Linux host и исходный mount point поддерживает нужную propagation. Docker документация отдельно отмечает, что bind propagation не работает на Docker Desktop так же, как на нативном Linux host.
2. Для --mount укажите bind-propagation=rslave или rshared; для -v добавьте режим в третий сегмент опций, например :ro,rshared.
3. Сначала создайте контейнер с минимально необходимым направлением. Если нужно только видеть submounts, появляющиеся на host, предпочитайте rslave двустороннему rshared.
4. Создайте тестовый submount внутри исходного дерева на host и проверьте, появляется ли он внутри контейнера. Для rshared отдельно проверяйте обратное направление только в изолированной тестовой среде.
5. Задокументируйте, зачем режим нужен. Без этого следующий инженер может удалить непонятную опцию или, наоборот, размножить rshared там, где достаточно rprivate.

Предупреждение: rshared расширяет связь контейнера с mount tree хоста. Не используйте его как случайную попытку починить permissions или file watching.

Почему Docker Desktop — отдельный случай

Docker прямо указывает, что bind propagation не работает на Docker Desktop как на обычном Linux host. Причина практическая: Desktop запускает Linux-контейнеры внутри своей VM, а пути рабочего компьютера проходят через слой файлового шаринга. Поэтому рецепт, который исправил mount propagation на Linux-сервере, не следует переносить на macOS или Windows Desktop один в один. Если инструмент требует rshared именно с host filesystem, сначала проверьте его официальную поддержку Docker Desktop. Для локальной разработки часто проще изменить архитектуру: передавать нужные данные обычным bind mount, named volume или сокетом/сервисом, вместо попытки распространять mount events через границу VM. Это особенно важно в CI: локальный тест на Desktop и production на Linux могут вести себя по-разному даже при одинаковой docker run команде.

Важно: Не делайте вывод о production Linux по одному тесту на Docker Desktop — у propagation разная среда исполнения.

Как отличить проблему propagation от обычной проблемы bind mount

Если контейнер вообще не видит исходный каталог, проверяйте path, существование source, права и синтаксис --mount/-v. Если видит файлы, но не видит новый filesystem, смонтированный позже внутрь этого каталога на host, тогда propagation становится реальным кандидатом. Если файлы меняются, но приложение не реагирует, причина может быть в inotify/file watching, кэшировании или особенностях Desktop, а не в mount propagation. Если запись запрещена, смотрите readonly, uid/gid, SELinux и user namespace. Такое разделение симптомов экономит время: propagation — специализированный механизм, и его включение не исправляет большинство проблем с volume permissions. В production полезно оставлять минимально необходимый режим и явно тестировать появление/удаление submounts при старте и перезапуске сервисов, которые их создают.

Безопасный выбор режима для storage- и system-level контейнеров

Если приложение требует propagation, формулируйте направление потока mount events до написания docker run команды. Сценарий «host создаёт новые mounts, контейнер должен их видеть» обычно указывает на slave/rslave, потому что обратная передача от контейнера к host не нужна. Двусторонний shared/rshared оправдан только когда контейнер сознательно создаёт submounts, которые должны появиться на исходной стороне. Чем шире propagation, тем сложнее объяснить, почему новый mount неожиданно оказался видим в соседнем дереве. Для системных агентов добавьте тест после рестарта daemon и host: некоторые проблемы проявляются не при первом запуске, а когда mount создаётся позже. Проверяйте также source mount на host через findmnt и его propagation flags, потому что настройка контейнера не может заставить исходный mount поддерживать поведение, которого нет на host. В документации сервиса зафиксируйте точный source path, выбранный режим и ожидаемое направление распространения. Это превращает редкий низкоуровневый флаг в контролируемое требование архитектуры.

Практический тест: появился submount — кто должен его увидеть

Самый понятный способ выбрать propagation — сформулировать направление появления новых mount points. Если новый submount создаётся на исходной стороне и контейнер должен его увидеть, нужен режим, допускающий распространение от source к replica; rslave подходит, когда обратное распространение не требуется. Если новые mount points должны проходить в обе стороны между связанными mount trees, рассматривают rshared. rprivate оставляет обе стороны изолированными относительно новых submounts и поэтому безопасен как дефолт. Проверять нужно именно новые mount events, а не обычное изменение файлов: файл, созданный внутри уже смонтированного каталога, виден через bind mount и без rshared. На Linux для диагностики удобно сравнить mountinfo внутри контейнера и на хосте до и после создания отдельного submount. На Docker Desktop семантика ограничена виртуализированной средой, поэтому production-поведение Linux-хоста следует проверять на Linux. Если задача сводится к доступу к файлам, permissions или inotify, смена propagation почти наверняка лечит не ту проблему.

Что учитывать

Docker прямо указывает, что bind propagation не работает на Docker Desktop как на обычном Linux host. Причина практическая: Desktop запускает Linux-контейнеры внутри своей VM, а пути рабочего компьютера проходят через слой файлового шаринга. Поэтому рецепт, который исправил mount propagation на Linux-сервере, не следует переносить на macOS или Windows Desktop один в один. Если инструмент требует rshared именно с host filesystem, сначала проверьте его официальную поддержку Docker Desktop. Для…

Источники и проверка

Фактическая часть сверена по первичным источникам (в т.ч. Bind mounts and bind propagation). Пример и формулировки — редакция N1RO на 2026-09-22.

• Bind mounts and bind propagation