Mount появился в другом окружении: проверяем propagation

Администратор подключил учебный том в отдельном окружении и обнаружил ту же точку в соседнем процессе. Mount namespace создаёт отдельный набор видимых mounts, но исходные точки могут сохранять связь распространения событий. Чтобы объяснить неожиданное появление, нужно исследовать propagation.

Посмотреть свойства точки

findmnt -o TARGET,SOURCE,FSTYPE,PROPAGATION
cat /proc/self/mountinfo
readlink /proc/1234/ns/mnt
readlink /proc/5678/ns/mnt

1234 и 5678 — PID сравниваемых процессов. Разные идентификаторы ns/mnt подтверждают разные namespaces, но ещё не исключают передачу mount-событий. В mountinfo ищите optional fields shared и master. Они описывают отношения групп распространения.

Shared допускает передачу событий между связанными peers; private не распространяет их через такую связь; slave получает события от master, но не отправляет их обратно по этому направлению. Эти свойства относятся к mount, поэтому одного факта создания namespace недостаточно для вывода об изоляции. Описание режимов есть в mount(8).

Сформулировать направление события

Запишите, кто создал вложенный mount, под какой родительской точкой и кто его увидел. Например, /srv/lab в двух окружениях связан shared:42. Если внутри него появился новый дочерний mount, его распространение к peer объяснимо. Совпадающий источник устройства сам по себе этого не доказывает: две независимые операции тоже могут подключить один том.

Для чтения другой иерархии у администратора может быть доступен findmnt -N PID. Проверьте поддержку параметра локальной версией util-linux. Альтернатива — изучить /proc/PID/mountinfo. Сохраняйте исходный файл целиком: номера mount и родителей помогают не потерять контекст.

Проверить в отдельной лаборатории

Изменение propagation корня работающей системы затрагивает больше сервисов, чем кажется. Не начинайте с mount --make-rprivate /. Сначала воспроизведите поведение на изолированном стенде, выясните, какие сервисы намеренно полагаются на распространение, и выберите границу конкретного поддерева.

Для нового окружения обычно задают подходящую политику до создания вложенных mounts. Рекурсивные варианты меняют существующее поддерево, нерекурсивные — выбранную точку. Разница существенна при нескольких уровнях. После изменения повторно снимите findmnt и mountinfo, затем создайте и удалите учебный дочерний mount, наблюдая обе стороны.

Не спутать namespace с копией файлов

Даже private propagation не делает отдельную копию содержимого общей файловой системы. Обычные записи в файл могут быть видны через другие mounts. Изоляция событий подключения и изоляция данных — разные механизмы. Если задача состоит в независимом состоянии файлов, потребуется другой инструмент, например согласованный snapshot или отдельная файловая система.

Критерий результата — предсказанное направление появления и удаления mounts при повторном тесте. Сохраните схему двух окружений, parent mount, shared/master IDs и выбранную политику. Это позволит объяснить поведение без догадок о «магии namespace».

В курсе Linux и Bash для DevOps-инженеров работа с файловой системой и процессами даёт основу для чтения таких системных состояний. Откройте программу, чтобы укрепить практику проверки окружения приложения до изменения настроек.

Ещё по теме

• Нужна копия каталога только для чтения: проверяем readonly bind
• После mount файлы исчезли: как найти скрытые данные каталога