기술자료

적용 환경

Ubuntu 22.04 LTS는 2026년 8월 기준 표준 보안 유지보수 기간에 포함됩니다.

작업 전 주의사항

먼저 현재 설정을 날짜가 포함된 파일명으로 백업합니다.

sudo cp -a /etc/fstab "/etc/fstab.backup-$(date +%Y%m%d-%H%M%S)"

백업 파일이 생성되었는지 확인합니다.

ls -l /etc/fstab*

디스크와 현재 마운트 상태 확인

1. 운영체제가 디스크를 인식하는지 확인

블록 장치, 파일시스템 형식, UUID와 현재 마운트 지점을 함께 확인합니다.

lsblk -f
sudo blkid

자동 마운트할 파티션이 목록에 없으면 fstab을 수정하기 전에 디스크 연결 상태부터 해결해야 합니다. 가상 서버나 클라우드 환경이라면 관리 패널에서 해당 볼륨이 현재 서버에 연결되어 있는지도 확인합니다.

2. 현재 마운트 여부 확인

현재 커널이 인식하고 있는 마운트 정보를 확인합니다.

findmnt
df -hT

예를 들어 디스크를 /data에 마운트하려는 경우 다음 명령으로 해당 경로만 조회할 수 있습니다.

findmnt --target /data

fstab 설정 오류 확인

1. 활성화된 fstab 항목 확인

주석과 빈 줄을 제외한 실제 설정을 확인합니다.

grep -Ev '^[[:space:]]*(#|$)' /etc/fstab

/etc/fstab의 각 행은 일반적으로 다음 여섯 필드로 구성됩니다.

2. UUID와 파일시스템 형식 비교

fstab에 적힌 UUID와 lsblk -f 또는 blkid가 출력한 실제 UUID가 정확히 일치해야 합니다. 디스크를 포맷하거나 복제본으로 교체하면 UUID가 바뀔 수 있습니다.

장치명인 /dev/sdb1도 사용할 수 있지만, 장치명은 하드웨어 구성이나 인식 순서에 따라 달라질 수 있으므로 자동 마운트에는 UUID 사용이 권장됩니다.

3. 설정 문법 검증

실제 마운트를 시도하기 전에 findmnt로 fstab 문법과 장치 참조를 검사합니다.

sudo findmnt --verify --verbose

오류가 표시되면 해당 행의 필드 수, UUID, 마운트 지점, 파일시스템 형식과 옵션을 먼저 수정합니다. 검증이 끝나기 전에는 재부팅하지 마십시오.

자동 마운트 설정 수정

1. 마운트 지점 생성

이 문서에서는 추가 디스크를 /data에 마운트하는 예시를 사용합니다. 실제 운영 환경에 맞는 경로로 변경하십시오.

sudo mkdir -p /data

2. fstab 수정

편집기로 설정 파일을 엽니다.

sudo nano /etc/fstab

ext4 파일시스템을 /data에 자동 마운트하는 기본 예시는 다음과 같습니다. YOUR_FILESYSTEM_UUID는 sudo blkid에서 확인한 실제 UUID로 교체합니다.

UUID=YOUR_FILESYSTEM_UUID /data ext4 defaults 0 2

서버 부팅에 반드시 필요하지 않은 보조 디스크라면 다음과 같이 nofail과 장치 대기 시간을 추가할 수 있습니다.

UUID=YOUR_FILESYSTEM_UUID /data ext4 defaults,nofail,x-systemd.device-timeout=10s 0 2

XFS, Btrfs, NTFS 등 다른 파일시스템이라면 세 번째 필드의 형식과 필요한 패키지 및 옵션이 달라집니다. lsblk -f에서 확인한 형식을 임의로 바꾸지 마십시오.

재부팅 전후 정상 작동 확인

1. 설정 다시 검증

sudo findmnt --verify --verbose

치명적인 오류가 표시되지 않는지 확인합니다.

2. systemd 설정 갱신 후 실제 마운트 시험

/etc/fstab 변경 내용을 systemd에 다시 읽히고, 아직 마운트되지 않은 항목을 실제로 마운트합니다.

sudo systemctl daemon-reload
sudo mount -a

mount -a가 아무 메시지 없이 종료되는 것이 일반적입니다. 오류가 출력되면 재부팅하지 말고 해당 메시지를 기준으로 설정을 수정합니다.

3. 마운트 결과 확인

findmnt --target /data
df -hT /data

출력의 소스 장치, 파일시스템 형식과 대상 경로가 의도한 값과 일치해야 합니다.

4. 재부팅 후 확인

sudo reboot

서버가 다시 시작된 뒤 다음 명령으로 자동 마운트 여부와 실패한 마운트 유닛을 확인합니다.

findmnt --target /data
systemctl --failed --type=mount --no-pager

오류별 추가 점검

부팅 및 마운트 로그 확인

현재 부팅에서 발생한 중요 오류와 실패한 유닛을 확인합니다.

sudo journalctl -b -p err..alert --no-pager
systemctl --failed --no-pager

마운트 지점이 /data라면 systemd 유닛 이름은 일반적으로 data.mount입니다. 다음 명령으로 상태와 로그를 확인합니다.

systemctl status data.mount --no-pager
sudo journalctl -b -u data.mount --no-pager

중첩된 경로처럼 유닛 이름을 직접 판단하기 어렵다면 다음 명령으로 변환합니다.

systemd-escape --path --suffix=mount /data

디스크 또는 파일시스템 오류 확인

커널이 기록한 장치 인식 오류와 I/O 오류를 확인합니다.

sudo journalctl -k -b --no-pager

ext4 파일시스템의 점검 예시는 다음과 같습니다. /dev/sdb1은 실제 장치명으로 변경하며, 운영 중인 데이터가 사용 중이지 않은지 먼저 확인합니다.

sudo umount /data
sudo fsck -f /dev/sdb1

XFS와 같은 다른 파일시스템은 점검 및 복구 도구가 다르므로 fsck 명령을 그대로 적용하지 마십시오.

비상 모드로 부팅된 경우 복구

잘못된 /etc/fstab 항목 때문에 비상 모드로 진입했다면 서버 콘솔에서 관리자 셸로 접속합니다. 루트 파일시스템이 읽기 전용이면 먼저 읽기·쓰기 모드로 다시 마운트합니다.

mount -o remount,rw /

현재 설정을 백업한 뒤 편집기로 열어 잘못된 행을 수정하거나 행 앞에 #을 추가해 임시로 비활성화합니다.

cp -a /etc/fstab /etc/fstab.emergency-backup
nano /etc/fstab

수정 후 설정을 검증하고 systemd 구성을 갱신합니다.

findmnt --verify --verbose
systemctl daemon-reload
mount -a

오류가 더 이상 발생하지 않으면 기본 부팅 대상으로 전환하거나 서버를 재부팅합니다.

systemctl default

이전 부팅의 오류를 확인하려면 정상 부팅 후 sudo journalctl -b -1 -p warning..alert --no-pager를 사용할 수 있습니다.

재발 방지 방법

• 장치명보다 UUID를 사용하고, 디스크를 포맷하거나 교체한 뒤에는 UUID를 다시 확인합니다.
• /etc/fstab 변경 전에는 항상 백업 파일을 만듭니다.
• 재부팅 전에 findmnt --verify --verbose와 mount -a를 모두 실행합니다.
• 보조 디스크에만 필요에 따라 nofail과 제한된 장치 대기 시간을 적용합니다.
• 마운트 지점에 애플리케이션 파일을 미리 저장하지 않고, 실제 마운트 여부를 서비스 시작 전에 확인합니다.
• 원격 서버에서는 네트워크와 무관한 콘솔 접속 수단을 유지합니다.

자주 묻는 질문

장치명 대신 UUID를 사용해야 하나요?

장치명은 디스크 추가, 제거 또는 인식 순서에 따라 달라질 수 있습니다. 자동 마운트 설정에는 더 안정적인 UUID 사용이 권장됩니다.

mount -a가 성공하면 재부팅 후에도 반드시 마운트되나요?

mount -a는 현재 시점의 장치와 설정으로 실제 마운트를 시험하는 중요한 절차지만, 부팅 당시 장치 준비 지연이나 볼륨 연결 문제까지 완전히 보장하지는 않습니다. 재부팅 후 findmnt와 systemd 로그를 다시 확인해야 합니다.

nofail을 추가하면 모든 문제가 해결되나요?

아닙니다. nofail은 마운트가 실패해도 부팅을 계속하게 할 뿐입니다. UUID 오류, 파일시스템 손상이나 디스크 미연결 원인은 별도로 해결해야 합니다.

fstab의 마지막 숫자는 무엇을 의미하나요?

여섯 번째 필드는 부팅 중 파일시스템 검사 순서입니다. 일반적으로 루트 파일시스템은 1, 다른 로컬 파일시스템은 2, 검사하지 않을 항목은 0을 사용하지만 파일시스템과 운영 정책에 맞게 결정해야 합니다.

LVM 볼륨도 UUID로 등록할 수 있나요?

가능합니다. LVM 논리 볼륨 안에 생성된 파일시스템의 UUID를 blkid로 확인해 사용할 수 있습니다. 다만 부팅 시 볼륨 그룹이 활성화되지 않는 문제라면 pvs, vgs, lvs와 LVM 관련 로그도 함께 점검해야 합니다.

관련 VISION IDC 기술자료

• VISION IDC 기술자료 전체 목록
• PuTTY를 이용한 리눅스 SSH 접속 방법

공식 참고자료

• Ubuntu release cycle — Ubuntu 22.04 LTS 지원 기간 확인
• Ubuntu 22.04 fstab(5) 매뉴얼 — /etc/fstab 필드와 장치 식별 방식 확인
• Ubuntu 22.04 mount(8) 매뉴얼 — UUID 사용, 마운트 처리와 mount -a 동작 확인
• Ubuntu 22.04 findmnt(8) 매뉴얼 — 마운트 조회와 fstab 검증 방법 확인
• Ubuntu 22.04 systemd.mount(5) 매뉴얼 — nofail, x-systemd.device-timeout 및 자동 의존 관계 확인
• Ubuntu 22.04 journalctl(1) 매뉴얼 — 현재 및 이전 부팅 로그 조회 방법 확인
• Ubuntu 22.04 fsck(8) 매뉴얼 — 파일시스템 점검 시 마운트 상태 관련 주의사항 확인

공식 자료 조회일: 2026년 8월 7일