常にそうではなかったが、今では一貫していない動作が発生します。バインドマウントは既存のマウントをコピーしませんが（使用しない限り--rbind）、新しいマウントは自動的にコピー（およびアンマウント）されます。これはバグのようです。原因は何ですか？
# mount --bind / /mnt/tmp
# mount | grep /mnt
/dev/mapper/fedora-root on /mnt/tmp type ext4 (rw,relatime,seclabel,data=ordered)
# mount /var/lib/docker
# mount | grep mnt
/dev/mapper/fedora-root on /mnt/tmp type ext4 (rw,relatime,seclabel,data=ordered)
/dev/mapper/fedora-docker on /mnt/tmp/var/lib/docker type ext4 (rw,relatime,seclabel,data=ordered)
これは Fedora Workstation 23 で発生します。私はDebian 8も影響を受けると信じています。
他のプロセスなしでbashを起動すると、これは発生しませんinit=/bin/bash。つまり、Linuxカーネルに固有のものではないようです。
これは、ルートファイルシステムから新しいマウントポイントにファイルを移動する最も簡単な方法だったので、迷惑です。 SELinuxを使用するのは、ファイルに自動的にタグ付けされ、そのような操作がcp必要ないために特に便利です（少なくとも？を使用している場合）。restorecon
答え1
mount --make-privateマウントポイントで実行している場合は、新しいマウント停止がコピーされていることがわかります。
bashをinitとして実行することの違いは次のとおりです。源泉ファイルシステムはプライベートでマウントされます。 [*]起動中にシステム全体が効果的に実行されます--make-shared。を見ると違いがわかりますfindmnt -o +PROPAGATION。
ルートファイルシステムが共有としてマウントされると、すぐ下にマウントされたすべてのファイルシステムは同じ伝播設定を継承します。
ルートファイルシステムが共有として再マウントされていますsystemd。この機能は2012年頃にsystemdに追加されました。これは素晴らしいArch Linux Wikiで議論されています。
https://github.com/systemd/systemd/commit/b3ac5f8cb98757416d8660023d6564a7c411f0a0
この記事を読んで、次の方法を学ぶことをお勧めします。安全な分解再帰バインドのインストール。共有マウントではマウントするので削除して電波は双方向に進みます:-).
[*] boot を使用すると、init=/bin/bashファイルシステムがプライベートでマウントされていることがわかります。それでもFedoraのdracutinitramfsを使用して起動しますが、内部的にはsystemdとして実行されます。ここで何が起こっているのか100％確信できません。
答え2
なぜこれが起こるのかわかりませんが、これを避ける方法を見つけました。少なくともほとんどのファイルシステムでは、バインドマウントを使用する代わりに再マウントできます。
編集：この機能を使用すると、固有の問題が発生します。 2番目にファイルシステムをマウントすると、渡したファイルシステムごとのマウントオプションは無視されます。
# mount /dev/mapper/fedora-root /mnt/tmp
# mount | grep /mnt/tmp
/dev/mapper/fedora-root on /mnt/tmp type ext4 (rw,relatime,seclabel,data=ordered)
# mount /var/lib/docker
# mount | grep /mnt/tmp
/dev/mapper/fedora-root on /mnt/tmp type ext4 (rw,relatime,seclabel,data=ordered)