파일 시스템 테이블인 /etc/fstab은 시스템 도구가 마운트하거나 활성화할 수 있는 파일 시스템, 스왑 영역, 바인드 마운트, 네트워크 소스 및 기타 연결을 선언합니다. 항목은 부팅 과정에 참여할 수 있지만 noauto, 자동 마운트 통합 및 서비스 관리자 정책 같은 옵션에 따라 언제 또는 실제로 실행되는지가 달라집니다.
파일 시스템 · 레슨 7
/etc/fstab
`/etc/fstab`에 영구적인 파일 시스템 및 스왑 연결을 정의하고 안전하게 검증하는 방법을 알아봅니다.
여섯 필드
일반적인 항목에는 공백으로 구분된 여섯 필드가 있습니다.
UUID=130b882f-7d79-436d-a096-1e594c92bb76 /data ext4 defaults,nosuid,nodev 0 2
- 소스: 장치 경로,
UUID=,LABEL=, 네트워크 소스 또는 지원되는 다른 지정 방식입니다. - 대상: 마운트 지점이며, 스왑 같은 용도에서는 적절한 경우
none을 사용합니다. - 유형: 파일 시스템 유형,
swap,none또는 허용된 자동 유형입니다. - 옵션: 마운트 보조 도구와 통합 계층이 해석하는 쉼표 구분 목록입니다.
- dump 필드: 역사적으로
dump백업 유틸리티의 참여 여부를 제어하며, 일반적으로0은 참여하지 않음을 뜻합니다. - pass 필드: 적용 가능한 경우 부팅 시
fsck순서를 제어하며,0은 이 메커니즘을 통한 자동 검사를 비활성화합니다.
필드 안의 공백은 fstab 구문에 따라 공백의 경우 \040처럼 이스케이프해야 합니다. 필드 밖의 #은 주석을 시작합니다.
일반적인 /etc/fstab 항목에는 필드가 몇 개 있습니까?
안정적인 소스 식별자
로컬 파일 시스템에서는 파일 시스템 UUID가 /dev/sdX 열거 이름보다 안정적인 경우가 많습니다.
$ lsblk -f
$ sudo blkid
UUID=...는 해당 식별자가 의도한 파일 시스템에 속하는지 확인한 뒤에만 사용하십시오. 다시 포맷하면 새 UUID가 생성되고 블록 수준 복제는 같은 UUID를 복사할 수 있습니다. PARTUUID=는 파일 시스템이 아니라 파티션 테이블 항목을 식별하며 의미가 다릅니다.
소스 필드의 UUID=...는 일반적으로 무엇을 식별합니까?
마운트 옵션과 검사 필드
defaults는 구현에서 정의한 일반적인 옵션 집합으로 확장되며 모든 마운트에 가장 안전한 정책인 것은 아닙니다. 읽기 전용 접근이나 장치 노드 및 setuid 동작 제한처럼 신뢰 수준과 작업 부하에 맞는 옵션을 추가하십시오. 네트워크와 이동식 파일 시스템에는 부팅이 예상치 못하게 멈추지 않도록 시간 제한, 의존성 또는 장애 허용 정책이 필요할 수 있습니다.
fsck가 지원하는 파일 시스템에서 루트 파일 시스템은 일반적으로 pass 1을 사용하고 검사할 다른 로컬 파일 시스템은 pass 2를 사용합니다. 일부 유형은 일반 부팅 시 fsck를 사용하지 않는 등 파일 시스템별 관행이 다를 수 있으므로 2를 기계적으로 지정하지 말고 설치된 파일 시스템과 배포판 문서를 따르십시오.
여섯 번째 필드의 값 0은 무엇을 요청합니까?
복구 경로를 마련하고 편집하기
잘못된 루트, 부팅 또는 필수 네트워크 항목은 시작 과정을 중단시킬 수 있습니다. 편집하기 전에 다음을 수행하십시오.
- 최신 백업과 콘솔 또는 복구 접근을 확인합니다.
- 권한을 유지하면서 기존 파일을 복사합니다.
- 소스 식별 정보를 검증하고 의도한 마운트 지점을 만듭니다.
- 범위가 좁은 변경 하나만 수행합니다.
- 재부팅 전에 검증하고 테스트합니다.
누구나 읽을 수 있는 fstab 항목에 자격 증명을 직접 넣지 마십시오. 해당 마운트 보조 도구가 제공하는 보호된 자격 증명 메커니즘을 사용합니다.
중요한 fstab 항목을 변경하기 전에 복구 접근을 확인해야 하는 이유는 무엇입니까?
성공을 가정하지 않고 검증하기
지원되는 경우 정적 검사부터 시작합니다.
$ sudo findmnt --verify --verbose
그런 다음 통제된 조건에서 특정 새 항목을 테스트하고 findmnt로 확인하며, 테스트가 임시였다면 마운트 해제합니다. mount -a는 여러 대상 항목을 실제로 시도하여 네트워크에 연결하거나 의도하지 않은 소스를 연결할 수 있습니다. 이미 마운트된 항목과 noauto 항목도 건너뛰므로 무해한 구문 검사기도 아니고 완전한 증명도 아닙니다.
systemd 기반 시스템에서는 fstab을 편집한 뒤 관리자 설정을 다시 불러와 생성된 마운트 단위를 갱신하고, 로컬 문서에 따라 의존성과 부팅 동작을 검증하십시오.
mount -a만으로 fstab을 완전히 검증할 수 없는 이유는 무엇입니까?
리눅스 파티션과 파일 시스템 관리하기에서 복구에 안전한 실습용 보조 저장 장치를 사용해 연습하십시오.
레슨 완료
/etc/fstab 완료
이제 영구 파일 시스템 테이블 항목을 읽고 검증할 수 있습니다.
소스, 대상, 유형, 옵션, dump 및 pass 필드를 해석합니다.
의도한 식별 의미에 맞는 검증된 식별자를 선택합니다.
실제 파일 시스템에 맞는 마운트 및 검사 정책을 선택합니다.
복구 접근을 유지하고 범위가 좁은 변경 하나를 수행합니다.
정적 검증, 대상별 마운트 및 부팅 정책 확인을 함께 사용합니다.