mount --moveシステムで実行している場合systemdの使用を開始、が無効になり、上記のメッセージが表示されます。
これはmount --make-private、親マウントで実行してから移動を許可できることを意味します。
しかし、マウントを動かすことができることに気づきました。存在する共有サブツリーに。例えば
mount --make-private /boot/
mount --move /boot/efi /mnt
これらの区別は、取り消しの試みもmount --move /mnt /boot/efi失敗することを意味します。
モバイル共有マウントでマウントを無効にするのはなぜですか？移動マウントが許可される理由存在する共有インストールから？
$ mount --version
mount from util-linux 2.30.2 (libmount 2.30.2: selinux, btrfs, assert, debug)
$ rpm -q util-linux
util-linux-2.30.2-1.fc26.x86_64
ベストアンサー1
実際、共有の親トピックの下にあるインストールを移動できない理由はどこにも文書化されていません。私はカーネルでこのコードについて多くの研究をしてきました。
たとえば、次のコードを考えてみましょう。
mount --bind /opt /opt
mount --make-shared /opt
mkdir /opt/A
mount --bind /tmp /opt/A
mount --move /opt/A /mnt
の親は/opt/A共有マウントなので、/optそれに属するソースの伝播ツリー全体をからに移動する必要/optがあります/mnt。ただし、対応するマウントポイントがない可能性があるため、/opt元の伝播ツリーに属するすべてのマウントを移動できない状況を想像するのは簡単です。/mntこれは、マウントネームスペースを使用すると簡単に発生する可能性があります。したがって、この場合、ターゲット伝播ツリーにマウントポイントがないマウントは削除する必要があります。ただし、これは umount イベントをトリガーする必要があることを意味します。しかし、他の問題もあります。たとえば、umountイベントを伝播する必要があると主張することもできます。ただし、これは移動したいインストールツリー全体が削除されることを意味します。何らかの形で山の木が重なっていればさらにひどい。そこには隠された複雑さがたくさんあるので、単にブロックされました。