바인드 마운트 란 무엇입니까?


325

“바인드 마운트”란 무엇입니까? 어떻게 만드나요? 무엇이 좋은가요?

무언가에 바인드 마운트를 사용하라는 지시를 받았지만 그것이 무엇인지 또는 어떻게 사용하는지 이해하지 못합니다.


2
마운트 및 심볼릭 링크 사이의 유용한 대안 설명 : quora.com/...
찰리 파커 (Charlie Parker)

답변:


564

바인드 마운트 란 무엇입니까?

바인드 마운트 디렉토리 트리의 대체이다. 일반적으로 마운트하면 저장 장치가 디렉토리 트리로 표시됩니다. 바인드 마운트는 기존 디렉토리 트리를 대신 사용하여 다른 지점에서 복제합니다. 바인드 마운트의 디렉토리 및 파일은 원본과 동일합니다. 두보기가 동일한 데이터를 표시하므로 한쪽의 수정 사항은 다른쪽에 즉시 반영됩니다.

예를 들어, Linux 명령을 실행 한 후

mount --bind /some/where /else/where

디렉토리 /some/where/else/where내용이 동일합니다.

하드 링크 또는 기호 링크와 달리 바인드 마운트는 파일 시스템에 저장된 내용에 영향을 미치지 않습니다. 라이브 시스템의 속성입니다.

바인드 마운트를 작성하는 방법

bindfs

bindfs파일 시스템은 인 퓨즈 디렉토리 트리의 뷰를 작성 파일 시스템. 예를 들어

bindfs /some/where /else/where

/else/where내용 /some/where이 보이는 마운트 지점을 만듭니다 .

bindfs는 별도의 파일 시스템이므로 파일 /some/where/foo/else/where/foo응용 프로그램에 다른 파일로 나타납니다 (bindfs 파일 시스템은 고유 한 st_dev값을 가짐). 한 쪽의 모든 변경 사항은 다른쪽에 "마 법적으로"반영되지만 파일이 동일하다는 사실은 bindfs의 작동 방식을 알고있을 때만 나타납니다.

Bindfs는 마운트 지점을 알지 못하므로 아래에 마운트 지점이 있으면 아래의 /some/where다른 디렉토리로 나타납니다 /else/where. 아래의 파일 시스템 마운트 또는 마운트 해제 는 해당 디렉토리의 변경으로 /some/where나타납니다 /else/where.

Bindf는 일부 파일 메타 데이터를 변경할 수 있습니다. 파일에 대한 가짜 권한 및 소유권을 표시 할 수 있습니다. 자세한 내용은 설명서 를 참조하고 예는 아래를 참조하십시오.

bindfs 파일 시스템은 루트가 아닌 사용자로 마운트 될 수 있으며 FUSE 파일 시스템을 마운트하는 권한 만 필요합니다. 배포판에 따라 fuse그룹에 속하거나 모든 사용자에게 허용 될 수 있습니다. 퓨즈 파일 시스템을 마운트 해제하려면 사용하는 fusermount -u대신에 umount, 예를 들어,

fusermount -u /else/where

nullfs

FreeBSD는 nullfs파일 시스템의 다른보기를 생성하는 파일 시스템을 제공합니다 . 다음 두 명령은 동일합니다.

mount -t nullfs /some/where /else/where
mount_nullfs /some/where /else/where

두 명령을 실행 한 후 /else/where내용 /some/where이 보이는 마운트 지점이됩니다 .

nullfs는 별도의 파일 시스템이므로 파일 /some/where/foo/else/where/foo응용 프로그램에 다른 파일로 나타납니다 (nullfs 파일 시스템에는 고유 한 st_dev값이 있음). 한쪽의 모든 변경 사항은 다른쪽에 "마 법적으로"반영되지만 파일이 동일하다는 사실은 nullfs의 작동 방식을 알고있을 때만 나타납니다.

디렉토리 트리의 수준에서 역할을하는 퓨즈 bindfs 달리, FreeBSD의의 nullfs 아래에 너무 마운트 포인트를 커널에 깊은 역할 /else/where로 마운트 같은 지점의 일부에만 트리 : 보이지 않는 /some/where아래에 반영됩니다 /else/where.

nullfs 파일 시스템은 다른 BSD 변형 (OS X, OpenBSD, NetBSD)에서 사용할 수 있지만 기본 시스템의 일부로 컴파일되지는 않습니다.

리눅스 바인드 마운트

Linux에서는 바인드 마운트를 커널 기능으로 사용할 수 있습니다. 명령 행 옵션 또는 마운트 옵션 mount을 전달 하여 명령을 사용하여 작성할 수 있습니다 . 다음 두 명령은 동일합니다.--bindbind

mount --bind /some/where /else/where
mount -o bind /some/where /else/where

여기서“장치” /some/where는 온 디스크 파일 시스템의 경우와 같은 디스크 파티션이 아니라 기존 디렉토리입니다. 마운트 지점 /else/where은 평소와 같이 기존 디렉토리 여야합니다. 바인드 마운트를 만드는 것은 파일 시스템 드라이버를 포함하지 않으며 원래 마운트에서 커널 데이터 구조를 복사합니다.

mount --bind또한 비 디렉토리 상에 비 디렉토리를 장착 지원 : /some/where수있는 일반 파일을 수 (있는 경우 /else/where도 일반 파일을 할 필요가있다).

Linux 바인드 마운트는 대부분 원래와 구별 할 수 없습니다. 이 명령 df -T /else/where은와 동일한 장치 및 파일 시스템 유형을 표시 df -T /some/where합니다. 파일은 /some/where/foo/else/where/foo그들이 하드 링크 것처럼 구별 할 수 있습니다. 마운트 해제 할 수 있으며이 /some/where경우 /else/where마운트 된 상태로 유지됩니다.

구형 커널 (정확하게 언제, 나는 3.x까지 생각합니다)으로 바인드 마운트는 원래와 구별 할 수 없었습니다. 최근 커널은 바인드 마운트를 추적하고 PID / mountinfo를 통해 정보를 노출하므로 findmnt바인드 마운트를 표시 할 수 있습니다 .

바인드 마운트 항목을에 넣을 수 있습니다 /etc/fstab. 옵션에 원하는 다른 옵션을 포함 bind시키십시오 rbind. “장치”는 기존 트리입니다. 파일 시스템 열에는 none또는 이 포함될 수 있습니다 bind(무시되지만 파일 시스템 이름을 사용하면 혼동 될 수 있습니다). 예를 들면 다음과 같습니다.

/some/where /readonly/view none bind,ro

아래에 마운트 지점이 있으면 /some/where해당 내용이 아래에 표시되지 않습니다 /else/where. 대신 bind, rbind아래의 마운트 지점을 복제 할 수도 있습니다 /some/where. 예를 들어 /some/where/mnt마운트 포인트 인 경우

mount --rbind /some/where /else/where

에 해당

mount --bind /some/where /else/where
mount --bind /some/where/mnt /else/where/mnt

또한 Linux에서는 마운트를 shared , slave , private 또는 unbindable 로 선언 할 수 있습니다 . 이는 마운트 조작을 마운트 포인트를 복제하는 바인드 마운트에 반영하는지 여부에 영향을줍니다. 자세한 내용 은 커널 설명서를 참조하십시오 .

리눅스는 또한 마운트를 옮기는 방법을 제공합니다 : --bind사본 --move이 마운트 포인트를 움직이는 곳.

두 개의 바인드 마운트 디렉토리에서 다른 마운트 옵션을 사용할 수 있습니다. 그러나 바인드 마운트를 만들고 마운트 옵션을 설정하는 것은 원자 적으로 수행 할 수 없으며 두 가지 연속적인 작업이어야합니다. 예를 들어, 다음 명령은 읽기 전용보기를 작성하지만 /else/where읽기 / 쓰기가 수행되는 작은 시간 창이 있습니다 .

mount --bind /some/where /else/where
mount -o remount,ro,bind /else/where

바인드 마운트를 작동시킬 수 없습니다!

시스템이 FUSE를 지원하지 않는 경우 동일한 효과를 얻는 전형적인 방법은 NFS 서버를 실행하고 노출하려는 파일을 내보내고 (액세스 권한을 localhost부여한 후) 동일한 시스템에 마운트하는 것입니다. 이는 메모리와 성능면에서 상당한 오버 헤드를 가지므로 바인드 마운트는 사용 가능한 경우 확실한 이점이 있습니다 (FUSE 덕분에 대부분의 Unix 변형에 해당).

사용 사례

읽기 전용보기

보안상의 이유로 또는 실수로 파일을 수정하지 않도록 안전 계층으로 파일 시스템의 읽기 전용보기를 작성하는 것이 유용 할 수 있습니다.

bindfs로 :

bindfs -r /some/where /mnt/readonly

리눅스를 사용하는 간단한 방법 :

mount --bind /some/where /mnt/readonly
mount -o remount,ro,bind /mnt/readonly

이렇게하면 /mnt/readonly읽기 / 쓰기 시간이 짧아 집니다. 이것이 보안상의 문제인 경우, 먼저 루트 만 액세스 할 수있는 디렉토리에 바인드 마운트를 작성하고 읽기 전용으로 만든 다음 공용 마운트 포인트로 이동하십시오. 아래 스 니펫 /root/private에서 (마운트 포인트 위의 디렉토리)는 개인용이어야합니다. 원래 사용 권한 /root/private/mnt은 마운트 지점 뒤에 숨겨져 있기 때문에 관련이 없습니다.

mkdir -p /root/private/mnt
chmod 700 /root/private
mount --bind /some/where /root/private/mnt
mount -o remount,ro,bind /root/private/mnt
mount --move /root/private/mnt /mnt/readonly

사용자 및 그룹 다시 매핑

파일 시스템은 숫자 ID로 사용자 및 그룹을 기록합니다. 때로는 같은 사람에게 다른 사용자 ID를 할당하는 여러 시스템이 생길 수 있습니다. 이것은 네트워크 액세스의 문제는 아니지만 디스크의 한 시스템에서 다른 시스템으로 데이터를 전송할 때 사용자 ID를 의미가 없게 만듭니다. Alice가 사용자 ID 1000을 갖고 Bob이 사용자 ID 1001을 갖는 시스템에 다중 사용자 파일 시스템 (예 : ext4, btrfs, zfs, UFS 등)으로 작성된 디스크가 있고 해당 디스크에 액세스 할 수 있도록한다고 가정하십시오. 디스크를 직접 마운트하면 Alice의 파일은 Bob이 소유 한 것으로 표시되고 (사용자 ID는 1001이므로) Bob의 파일은 Alice가 소유 한 것으로 표시됩니다 ( 사용자 ID는 1000입니다.

bindfs를 사용하여 사용자 ID를 다시 맵핑 할 수 있습니다. 먼저 루트 만 액세스 할 수있는 개인 디렉토리에 디스크 파티션을 마운트하십시오. 그런 다음 Alice와 Bob의 사용자 ID와 그룹 ID를 교환하는 사용자 ID와 그룹 ID를 다시 매핑하여 공용 영역에 bindfs보기를 작성하십시오.

mkdir -p /root/private/alice_disk /media/alice_disk
chmod 700 /root/private
mount /dev/sdb1 /root/private/alice_disk
bindfs --map=1000/1001:1001/1000:@1000/1001:@1001/1000 /root/private/alice_disk /media/alice_disk

참조 하나가 허용 가능 비 부팅 된 시스템의 사용자의 홈 폴더에있는 파일에 액세스 않습니다 어떻게? 그리고 나 자신으로 --bind 다른 사용자 마운트 또 다른 예.

감옥이나 컨테이너에 설치

chroot로 또는 컨테이너 시스템의 디렉토리 트리의 서브 트리에서 프로세스를 실행합니다. 이것은 액세스가 제한된 프로그램을 실행하는 데 유용 할 수 있습니다. 예를 들어, 자신의 파일과 파일에 액세스 할 수 있지만 동일한 컴퓨터에 저장된 다른 데이터에는 액세스 할 수없는 네트워크 서버를 실행하십시오. chroot의 한계는 프로그램이 하나의 하위 트리로 제한되어 있다는 것입니다. 독립 하위 트리에 액세스 할 수 없습니다. 바인드 마운트를 사용하면 다른 하위 트리를 해당 기본 트리에 이식 할 수 있습니다. 이것은 리눅스에서 가장 실제적인 컨테이너 사용의 기본이됩니다.

예를 들어, 머신이의 /usr/sbin/somethingd데이터에만 액세스 할 수 있는 서비스 를 실행한다고 가정하십시오 /var/lib/something. 이 두 파일을 모두 포함하는 가장 작은 디렉토리 트리가 루트입니다. 서비스를 어떻게 제한 할 수 있습니까? 한 가지 가능성은 서비스에서 필요한 모든 파일 (적어도 /usr/sbin/somethingd몇 개의 공유 라이브러리)에 하드 링크를 만드는 것 /var/lib/something입니다. 그러나 이것은 (하드 링크 파일이 업그레이드 될 때마다 업데이트 할 필요가) 복잡하고, 경우에 작동하지 않습니다 /var/lib/something/usr다른 파일 시스템에 있습니다. 더 나은 해결책은 임시 루트를 작성하고 마운트를 사용하여 채우는 것입니다.

mkdir /run/something
cd /run/something
mkdir -p etc/something lib usr/lib usr/sbin var/lib/something
mount --bind /etc/something etc/something
mount --bind /lib lib
mount --bind /usr/lib usr/lib
mount --bind /usr/sbin usr/sbin
mount --bind /var/lib/something var/lib/something
mount -o remount,ro,bind etc/something
mount -o remount,ro,bind lib
mount -o remount,ro,bind usr/lib
mount -o remount,ro,bind usr/sbin
chroot . /usr/sbin/somethingd &

리눅스의 마운트 네임 스페이스 는 chroot를 일반화합니다. 바인드 마운트는 네임 스페이스를 유연한 방식으로 채울 수있는 방법입니다. 예를 들어 프로세스가 동일한 파일 이름으로 다른 파일을 읽도록 설정을 참조하십시오 .

다른 배포판 실행

chroot를 사용하는 또 다른 용도는 디렉토리에 다른 배포본을 설치하고 기본 시스템에 존재하지 않거나 내용이 다른 하드 코딩 된 경로에 파일이 필요한 경우에도 프로그램을 실행하는 것입니다. 예를 들어 혼합 패키지를 지원하지 않는 64 비트 시스템에 32 비트 배포판을 설치하거나 호환성을 테스트하기 위해 이전 배포판 또는 기타 배포판을 설치하고 테스트 할 새 릴리스를 설치하는 데 유용합니다. 안정적인 기본 시스템 등을 유지하면서 최신 기능을 사용할 수 있습니다. 64 비트 데비안 / 우분투에서 32 비트 프로그램을 실행하려면 어떻게합니까?를 참조하십시오 . 데비안 / 우분투에 대한 예제입니다.

디렉토리 아래에 배포판의 최신 패키지를 설치했다고 가정합니다 /f/unstable. 여기서 디렉토리를 사용하여 해당 디렉토리로 전환하여 프로그램을 실행합니다 chroot /f/unstable. 이 설치에서 홈 디렉토리를 사용 가능하게하려면이를 chroot에 바인드 마운트하십시오.

mount --bind /home /f/unstable/home

프로그램 schroot 가이를 자동으로 수행합니다.

마운트 지점 뒤에 숨겨진 파일에 액세스

디렉토리에 파일 시스템을 마운트하면 디렉토리 뒤의 내용이 숨겨집니다. 디렉토리를 마운트 해제 할 때까지 해당 디렉토리의 파일에 액세스 할 수 없습니다. BSD nullfs 및 Linux 바인드 마운트는 마운트 인프라보다 낮은 수준에서 작동하기 때문에 파일 시스템의 nullfs 마운트 또는 바인드 마운트는 원본에서 서브 마운트 뒤에 숨겨진 디렉토리를 노출합니다.

예를 들어,에 tmpfs 파일 시스템이 마운트되어 있다고 가정하십시오 /tmp. /tmptmpfs 파일 시스템이 작성 될 때 파일이 있었다면 ,이 파일들은 여전히 ​​유효하게 액세스 할 수 없지만 디스크 공간을 차지합니다. 운영

mount --bind / /mnt

(Linux) 또는

mount -t nullfs / /mnt

(FreeBSD)에서 루트 파일 시스템의 뷰를 생성합니다 /mnt. 디렉토리 /mnt/tmp는 루트 파일 시스템 의 디렉토리 입니다.

다른 경로에서 NFS 내보내기

NFSv4 이전의 Linux 커널 NFS 서버와 같은 일부 NFS 서버는 디렉토리를 내보낼 때 항상 실제 디렉토리 위치를 알립니다. 즉, 클라이언트가 요청 server:/requested/location하면 서버는 위치에서 트리를 제공합니다 /requested/location. 때때로 클라이언트가 요청 /request/location하지만 실제로 파일을 제공 하는 것이 바람직합니다 /actual/location. NFS 서버가 대체 위치 제공을 지원하지 않는 경우 예상되는 요청에 대한 바인드 마운트를 작성할 수 있습니다 (예 :

/requested/location *.localdomain(rw,async)

/etc/exports와에 다음과 같은 /etc/fstab:

/actual/location /requested/location bind bind

심볼릭 링크를 대체

때로는 파일을 /some/where/is/my/file아래 /else/where에 표시 하기 위해 심볼릭 링크를 만들려고 하지만 사용하는 응용 프로그램은 file심볼릭 링크를 확장하고 거부합니다 /some/where/is/my/file. 바인드 마운트는이 문제를 해결할 수 있습니다. bind-mount /some/where/is/myto /else/where/is/my다음에 아래 가 아닌 아래 에있는 것으로 realpath보고 /else/where/is/my/file합니다 ./else/where/some/where

바인드 마운트의 부작용

재귀 디렉토리 탐색

바인드 마운트를 사용하는 경우 백업 및 인덱싱 (예 :로 케이트 데이터베이스 구축)과 같이 파일 시스템 트리를 재귀 적으로 순회하는 애플리케이션을 관리해야합니다 .

일반적으로 바인드 마운트는 재귀 디렉토리 탐색에서 제외되므로 각 디렉토리 트리는 원래 위치에서 한 번만 탐색됩니다. bindfs 및 nullfs를 사용하면 가능한 경우 이러한 파일 시스템 유형을 무시하도록 순회 도구를 구성하십시오. Linux 바인드 마운트는 그대로 인식 할 수 없습니다. 새 위치는 원래 위치와 동일합니다. Linux 바인드 마운트 또는 파일 시스템 유형이 아닌 경로 만 제외 할 수있는 도구를 사용하는 경우 바인드 마운트의 마운트 포인트를 제외해야합니다.

파일 시스템의 경계에서 중지 순회 (예를 들면 find -xdev, rsync -x, du -x그들이 bindfs가 발생하거나 nullfs 지점을 마운트 할 때 그 점은 다른 파일 시스템을 마운트하기 때문에 ...) 자동으로 중지됩니다. Linux 바인드 마운트를 사용하면 상황이 좀 더 복잡해집니다. 바인드 마운트가 동일한 파일 시스템의 다른 부분을 이식하는 경우가 아니라 바인드 마운트가 다른 파일 시스템을 이식하는 경우에만 파일 시스템 경계가 있습니다.

바인드 마운트를 넘어서

바인드 마운트는 다른 위치에있는 디렉토리 트리의보기를 제공합니다. 다른 마운트 옵션과 (binfs와 함께) 다른 소유권과 권한으로 동일한 파일을 노출합니다. 디렉토리 트리의 변경된보기를 제공하는 파일 시스템을 오버레이 파일 시스템 또는 스택 가능 파일 시스템이라고 합니다. 보다 고급 변환을 수행하는 다른 많은 오버레이 파일 시스템이 있습니다. 몇 가지 일반적인 것들이 있습니다. 원하는 사용 사례가 여기에 포함되지 않은 경우 FUSE 파일 시스템저장소를 확인하십시오 .

보이는 파일 필터링

  • clamfs — 파일을 읽을 때 바이러스 스캐너를 통해 파일을 실행합니다
  • filterfs — 파일 시스템의 일부를 숨 깁니다
  • rofs — 읽기 전용보기입니다. 와 비슷 bindfs -r하지만 조금 더 가볍습니다.
  • 연합 마운트 - 현재 다수의 파일 시스템 (라는 나뭇 가지 하나의 디렉토리 아래) : 경우에 tree1포함 foo하고 tree2포함 bar그들의 조합보기를 모두 포함 foo하고 bar. 새 파일은 특정 분기 또는보다 복잡한 규칙에 따라 선택한 분기에 작성됩니다. 이 개념의 구현은 다음과 같습니다.

파일 이름 및 메타 데이터 수정

  • ciopfs — 대소 문자를 구분하지 않는 파일 이름 (Windows 파일 시스템을 마운트하는 데 유용 할 수 있음)
  • convmvfs — 문자 세트간에 파일 이름을 변환합니다 ( )
  • posixovl — VFAT ( :) 와 같은보다 제한된 파일 시스템에 Unix 파일 이름 및 기타 메타 데이터 (권한, 소유권 등 )를 저장합니다

변경된 파일 내용보기

컨텐츠 저장 방식 수정

  • chironfs — 파일을 여러 기본 저장소에 복제합니다 ( 디렉토리 트리 수준의 RAID-1 )
  • copyfs — 모든 버전의 파일 사본을 보관합니다
  • encfs — 파일 암호화
  • pcachefs — 느린 원격 파일 시스템을위한 온 디스크 캐시 계층
  • simplecowfs — 제공된 파일을 통해 변경 사항을 메모리에 저장하고 원본 파일은 그대로 유지
  • 웨이 백 -모든 버전의 파일 사본 유지

1
하나는 systemd와 함께 작업을 수행하는 방법의 예를 추가 할 수 있습니다 utcc.utoronto.ca/~cks/space/blog/linux/SystemdBindMountUnits
dothebart

1
무엇을 mount --bind /dir1 /dir1합니까? 실장 소스와 대상이 다른 경우와 어떻게 다릅니 까?
Mark

Linux 5.0을 사용하는 / proc / self / mountinfo에 레코드가 없습니다. 커널은 그것이 바인드 마운트인지 말하지 않습니다. 프로세스는 chroot를 쉽게 중단 할 수 있으며 마운트 네임 스페이스로 격리를 수행해야합니다.
炸鱼 薯条 德里克

@ 炸鱼 薯条 德里克 링크 된 질문 unix.stackexchange.com/questions/295525/… 는 생각 합니다 /proc/self/mountinfo. chroot는 단독으로 사용할 수 없지만 격리에 사용할 수 있습니다. 마운트 네임 스페이스는 필요 하지 않습니다 . chroot는 파일 시스템 네임 스페이스 부분에 충분합니다. chroot의 프로세스가 chroot 외부의 프로세스와 동일한 사용자로 실행되지 않도록해야합니다.
Gilles

@Mark 디렉토리를 자신에 바인드 마운트하는 것은 그리 유용하지 않습니다. 특정 디렉토리에 마운트 된 파일 시스템을 숨기기 위해 사용할 수 있다고 생각하지만, 구체적으로하고 싶었던 시간은 생각할 수 없습니다.
Gilles

-1

바인드 마운트를 사용하면 호스트 시스템의 파일 또는 디렉토리가 컨테이너에 마운트되므로 호스트 시스템의 파일 디렉토리에서 변경 한 내용은 디렉토리의 컨테이너 내부에서 자동으로 사용할 수 있습니다.


이것이 바인드 마운트를 사용하는 방법 중 하나이지만 바인드 마운트 자체는 컨테이너와 관련이 없습니다. 나는 대답으로 언급하지만“컨테이너”가 아닌“감옥”이라는 이름으로 언급합니다. “컨테이너”를 추가하는 것은 귀중한 편집이 될 것입니다. 이것은 또한 나쁜 설명입니다. 왜 외부에서 변경 한 내용이 다른 방식으로 언급되지 않고 내부에서도 가능하다는 언급이 있습니까?
Gilles
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.