여기서는 멈추세요
- root·boot·swap 항목 또는 알 수 없는 UUID가 포함되면 실제 mount와 재부팅을 중단합니다.
- 원격 서버에서 콘솔 접근과 /etc/fstab 복원 경로가 없으면 변경하지 않습니다.
MOUNT RECOVERY
/etc/fstab 오류로 마운트가 실패할 때
재부팅으로 시험하지 않고 UUID, fstab 문법과 systemd mount unit을 검증한 뒤 승인된 마운트만 적용합니다.fstab errormount failedDependency failed for Local File Systemswrong fs typeUUID does not exist
환경Ubuntu 22.04·24.04 LTS · util-linux · systemd mount unit
분류디스크·파일
검토일2026-08-27
진행5단계 · 조회 우선
SAFE OPERATING BOUNDARY
중단·복구 기준부터 확인하세요
복구 기준
문제가 생기면 /etc/fstab.before-haru-change를 복원하고 daemon-reload를 수행합니다. 새로 마운트된 경로의 사용 프로세스를 확인하지 않고 강제 unmount하지 않습니다.
담당자에게 전달할 자료
- lsblk -f와 findmnt --verify --verbose 출력
- 문제 mount unit의 status·journal과 해당 fstab 한 줄
- 장치 연결 이력과 수정 전후 /etc/fstab 차이
BEFORE YOU START
이런 증상에서 시작합니다
- 부팅 중 mount job timeout
- Dependency failed for Local File Systems
- mount -a 오류
- UUID 장치를 찾지 못함
CHECK THE BRANCH
놓치기 쉬운 원인 분기
UUID가 존재하지 않음
장치 이름을 임의로 바꾸지 말고 lsblk의 실제 UUID와 클라우드 볼륨 연결 상태를 먼저 확인합니다.
네트워크 파일시스템
NFS·CIFS는 로컬 디스크와 시작 조건이 다르므로 _netdev, network-online과 자격증명 파일 권한을 별도로 검토합니다.
emergency mode 원인
필수 마운트 실패가 부팅을 막을 수 있습니다. nofail을 무조건 추가하기보다 해당 마운트가 서비스에 필수인지 먼저 확인합니다.
FOLLOW THE FLOW
순서대로 확인하기
조회시스템을 변경하지 않는 확인 단계
실제 장치·UUID·파일시스템 확인
fstab의 장치 식별자와 현재 연결된 블록 장치를 비교합니다.
블록 장치와 UUID
lsblk -f현재 마운트 트리
findmnt --real --output TARGET,SOURCE,FSTYPE,OPTIONS결과 읽기
fstab의 UUID가 lsblk에 없으면 문법보다 장치 연결·교체·스냅샷 복원 상태를 먼저 확인합니다.
다음 판단
문제 장치와 예상 마운트 지점을 기록합니다.
조회시스템을 변경하지 않는 확인 단계
fstab을 변경 없이 검증
findmnt가 fstab의 장치, 마운트 지점, 옵션과 파일시스템 형식을 검사하도록 합니다.
fstab 상세 검증
findmnt --verify --verbosefstab 해석 결과
findmnt --fstab --evaluate결과 읽기
parse error, unreachable source, 잘못된 mountpoint를 실제 줄과 연결합니다.
다음 판단
오류가 없다면 systemd가 생성한 mount unit 상태를 확인합니다.
조회시스템을 변경하지 않는 확인 단계
systemd mount unit과 로그 확인
MOUNTPOINT_ESCAPED를 systemd-escape 결과로 바꾸고 실패 시각의 로그를 봅니다.
mount unit 이름 생성
systemd-escape -p --suffix=mount /mnt/datamount unit 상태
systemctl status MOUNTPOINT_ESCAPED.mount --no-pager -lmount unit 로그
journalctl -u MOUNTPOINT_ESCAPED.mount -b --no-pager결과 읽기
device timeout, 잘못된 파일시스템 형식, 권한·네트워크 실패를 구분합니다.
다음 판단
원인이 되는 fstab 한 줄과 의존 서비스를 식별합니다.
주의서버 부하나 권한을 고려할 단계
변경 전 백업과 fake 실행
실제 마운트를 수행하지 않는 fake 모드로 전체 fstab이 어떤 작업을 시도할지 확인합니다.
fstab 백업
sudo cp -a /etc/fstab /etc/fstab.before-haru-change마운트 fake 실행
sudo mount --fake --all --verbose결과 읽기
예상하지 못한 장치·경로나 root·boot 관련 변경이 보이면 실제 mount -a를 실행하지 않습니다.
다음 판단
수정 내용과 복원할 백업 경로를 운영 기록에 남깁니다.
변경데이터·서비스 상태가 달라질 수 있는 단계
승인된 fstab을 다시 읽고 마운트 검증
fstab 수정 자체는 자동화하지 않습니다. 검토된 한 줄을 반영한 뒤 아래 순서로 검증합니다.
변경 단계입니다. 실행 전 대상 이름과 경로, 서비스 중단 영향, 복구 방법을 다시 확인하세요.
systemd 설정 다시 읽기
sudo systemctl daemon-reloadfstab 최종 검증
findmnt --verify --verbose승인된 항목만 마운트
sudo mount --verbose /mnt/data대상 확인
findmnt /mnt/data결과 읽기
오류 없이 예상 SOURCE가 예상 TARGET에 올바른 옵션으로 마운트되어야 합니다.
다음 판단
재부팅은 콘솔 접근과 복원 절차를 확보한 뒤 별도 검증합니다.
PRIMARY REFERENCES
공식 문서
배포판과 버전에 따라 옵션·로그 위치가 다를 수 있습니다. 실행 전 서버의 --help와 로컬 매뉴얼을 함께 확인하세요.