[태그:] Mount Failed

리눅스 서버에 새로운 디스크를 연결하거나 /etc/fstab 설정을 변경한 뒤 Mount Failed 오류가 발생하면 저장소를 사용하는 서비스까지 중단될 수 있습니다. 특히 서버를 재부팅한 이후 기존 디스크가 연결되지 않거나 NFS 공유 디렉터리에 접근하지 못하는 경우에는 설정 오류와 실제 저장장치 문제를 구분해야 합니다.

마운트 실패는 하나의 고정된 오류 메시지가 아닙니다. 실제로는 wrong fs type, special device does not exist, mount point does not exist, access denied by server처럼 원인에 따라 서로 다른 메시지가 표시됩니다.

이때 무작정 마운트 명령어를 반복하거나 파일시스템 복구를 시도하기보다 장치 인식 상태, UUID, fstab 설정, 파일시스템 유형, 마운트 옵션 및 시스템 로그를 순서대로 확인하는 것이 중요합니다.

Mount Failed 핵심 명령어 한눈에 보기

주의: 마운트 오류가 발생했다고 해서 mkfs, fsck -y, xfs_repair -L 같은 명령어를 바로 실행해서는 안 됩니다. 저장된 데이터와 파일시스템 상태를 먼저 확인해야 합니다.

1. Mount Failed 오류가 발생하는 주요 원인

리눅스에서 마운트는 디스크 파티션이나 네트워크 파일시스템을 특정 디렉터리에 연결하는 작업입니다. 장치 정보나 마운트 설정이 실제 환경과 일치하지 않으면 마운트가 실패할 수 있습니다.

• UUID 불일치: fstab에 등록된 UUID와 실제 파일시스템 UUID가 다른 경우
• 장치 경로 변경: 디스크 연결 순서가 바뀌어 /dev/sdb1 등의 이름이 변경된 경우
• 파일시스템 유형 오류: ext4, XFS, Btrfs 등의 유형을 잘못 지정한 경우
• 마운트 지점 문제: 대상 디렉터리가 없거나 올바르지 않은 경우
• 마운트 옵션 충돌: 파일시스템에서 지원하지 않는 옵션을 지정한 경우
• 파일시스템 손상: 슈퍼블록 또는 메타데이터에 문제가 발생한 경우
• NFS 연결 문제: 네트워크, 공유 경로, Export 권한이 잘못된 경우
• 부팅 순서 문제: 장치나 네트워크가 준비되기 전에 마운트가 시작된 경우

특히 동일한 오류 메시지가 여러 원인에서 나타날 수 있으므로 마운트 명령어의 출력과 커널 로그를 함께 확인해야 합니다.

2. lsblk와 blkid로 실제 디스크 상태 확인하기

가장 먼저 운영체제가 저장장치를 정상적으로 인식하는지 확인합니다.

lsblk -f

출력 예시는 다음과 같습니다.

NAME   FSTYPE UUID                                  MOUNTPOINTS
sda
└─sda1 ext4   11111111-2222-3333-4444-555555555555 /
sdb
└─sdb1 ext4   aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee

여기서 FSTYPE은 파일시스템 유형, UUID는 파일시스템 식별자, MOUNTPOINTS는 현재 연결된 디렉터리입니다.

추가로 다음 명령어를 실행합니다.

sudo blkid /dev/sdb1

예시 결과:

/dev/sdb1: UUID="aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee" TYPE="ext4"

실제 UUID가 fstab에 기록된 값과 다르다면 해당 설정을 수정해야 합니다.

또한 장치 자체가 lsblk에 표시되지 않는다면 파일시스템 설정에 앞서 디스크 연결, 가상머신 볼륨 연결 상태 또는 스토리지 장치 인식 문제를 확인해야 합니다.

3. /etc/fstab 설정 확인하기

/etc/fstab은 서버에서 사용할 파일시스템의 자동 마운트 정보를 관리하는 설정 파일입니다.

cat /etc/fstab

다음은 일반적인 ext4 마운트 설정 예시입니다.

UUID=aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee /mnt/data ext4 defaults 0 2

fstab 설정을 검증하려면 다음 명령어를 사용합니다.

sudo findmnt --verify --verbose

이 명령어는 설정 형식과 장치 참조를 점검하는 데 도움이 되지만, 실제 마운트 성공을 보장하지는 않습니다.

설정을 변경하기 전에는 백업 파일을 만들어 두는 것이 좋습니다.

sudo cp -a /etc/fstab /etc/fstab.bak

특히 루트 파일시스템이나 중요한 데이터 디스크의 fstab 설정을 잘못 변경하면 재부팅 시 복구 모드로 진입하거나 서비스가 시작되지 않을 수 있습니다.

4. 마운트 지점과 파일시스템 유형 확인하기

마운트 대상 디렉터리가 존재하지 않으면 다음과 같은 오류가 발생할 수 있습니다.

mount: /mnt/data: mount point does not exist.

먼저 디렉터리를 확인합니다.

ls -ld /mnt/data

새로운 마운트 지점이 필요한 상황이라면 경로를 확인한 뒤 생성할 수 있습니다.

sudo mkdir -p /mnt/data

다만 기존 파일이 존재하는 디렉터리에 다른 파일시스템을 마운트하면 원래 디렉터리의 내용이 마운트된 동안 가려질 수 있습니다.

파일시스템 유형은 다음 명령어로 확인합니다.

lsblk -f /dev/sdb1
sudo file -s /dev/sdb1

실제 파일시스템이 XFS인데 fstab에 ext4로 지정했다면 유형 불일치로 마운트가 실패할 수 있습니다.

장치에 파일시스템이 없거나 암호화·LVM 계층이 존재하는 경우에는 올바른 논리 장치가 무엇인지 먼저 확인해야 합니다.

5. wrong fs type과 bad superblock 오류 확인하기

마운트 실패 시 다음과 같은 메시지가 나타날 수 있습니다.

mount: /mnt/data: wrong fs type, bad option,
bad superblock on /dev/sdb1,
missing codepage or helper program, or other error.

이 메시지는 파일시스템 유형 오류, 지원하지 않는 옵션, 필요한 도구 누락 또는 파일시스템 손상 등 여러 원인에서 발생할 수 있습니다.

먼저 커널 로그를 확인합니다.

sudo journalctl -k -b | grep -Ei 'ext4|xfs|btrfs|superblock|I/O error|mount'

예를 들어 다음과 같은 메시지가 나타날 수 있습니다.

EXT4-fs (sdb1): VFS: Can't find ext4 filesystem

이 경우 실제 파일시스템이 ext4인지, 올바른 장치를 선택했는지, 메타데이터에 문제가 있는지 확인해야 합니다.

반면 다음과 같은 오류가 나타난다면 스토리지 장치 자체의 문제를 의심할 수 있습니다.

I/O error, dev sdb, sector 2048

I/O 오류가 반복된다면 쓰기 작업을 최소화하고 저장장치 상태와 백업을 우선 확인해야 합니다.

6. NFS Mount Failed 오류 확인하기

NFS 공유 디렉터리에서 마운트 오류가 발생한다면 로컬 디스크와 다른 항목을 점검해야 합니다.

먼저 현재 NFS 마운트 상태를 확인합니다.

findmnt -t nfs,nfs4

NFS 서버 연결 상태도 확인합니다.

ping -c 4 192.0.2.10
nc -vz -w 3 192.0.2.10 2049

위 IP 주소는 예시입니다. 또한 ping이 실패했다고 해서 반드시 NFS 연결이 불가능한 것은 아닙니다. ICMP 차단 여부와 NFS 서비스 상태를 구분해야 합니다.

NFSv4 공유 경로를 연결하는 예시는 다음과 같습니다.

sudo mount -t nfs4 192.0.2.10:/exports/data /mnt/shared

NFS 서버에서 공유 설정을 확인할 수 있다면 다음 명령어를 사용합니다.

sudo exportfs -v

access denied by server while mounting 오류가 발생한다면 클라이언트 IP 주소가 허용되어 있는지, Export 경로와 NFS 버전이 맞는지 확인해야 합니다.

7. systemd 부팅 과정에서 Mount Failed가 발생하는 경우

수동 마운트는 성공하지만 서버 재부팅 후에만 실패한다면 systemd 마운트 유닛과 장치 준비 순서를 확인해야 합니다.

systemctl --failed

마운트 경로에 대응하는 systemd 유닛 이름을 확인합니다.

systemd-escape -p --suffix=mount /mnt/data

출력 예시:

mnt-data.mount

유닛 상태와 부팅 로그를 확인합니다.

systemctl status mnt-data.mount
journalctl -b -u mnt-data.mount

네트워크 파일시스템에서는 _netdev 옵션을 검토할 수 있습니다.

192.0.2.10:/exports/data /mnt/shared nfs4 defaults,_netdev 0 0

또한 x-systemd.automount를 사용하면 접근 시점에 마운트를 시도하도록 구성할 수 있습니다.

다만 nofail 옵션은 마운트 실패가 부팅에 미치는 영향을 줄일 수 있을 뿐, 저장소 연결 문제를 해결하지는 않습니다.

데이터베이스나 중요한 애플리케이션이 해당 저장소에 의존한다면 마운트가 완료되기 전에 서비스가 실행되지 않도록 서비스 의존성도 함께 검토해야 합니다.

8. 파일시스템 복구 전 확인해야 할 사항

Mount Failed 오류가 발생했다고 해서 파일시스템이 반드시 손상된 것은 아닙니다.

파일시스템 복구 도구는 종류에 따라 다르며, 마운트된 상태에서 잘못 실행하면 데이터 손상을 일으킬 수 있습니다.

먼저 파일시스템 유형을 확인합니다.

lsblk -f

ext4는 일반적으로 e2fsck, XFS는 xfs_repair 같은 전용 도구를 사용합니다.

그러나 복구 명령어를 실행하기 전에는 대상 장치가 정확한지, 마운트가 해제되어 있는지, 백업이나 스냅샷을 확보할 수 있는지 확인해야 합니다.

특히 mkfs는 기존 파일시스템을 복구하는 명령어가 아니라 새로운 파일시스템을 생성하는 명령어이므로 기존 데이터가 있는 장치에 실행해서는 안 됩니다.

실전 점검 순서

리눅스 서버에서 Mount Failed 오류가 발생하면 다음 순서로 확인하는 것이 좋습니다.

# 1. 디스크 및 파일시스템 확인
lsblk -f

# 2. UUID 확인
sudo blkid

# 3. 현재 마운트 상태 확인
findmnt

# 4. fstab 설정 확인
cat /etc/fstab

# 5. fstab 검증
sudo findmnt --verify --verbose

# 6. 마운트 대상 디렉터리 확인
ls -ld /mnt/data

# 7. 실제 파일시스템 서명 확인
sudo file -s /dev/sdb1

# 8. 커널 오류 확인
sudo journalctl -k -b | grep -Ei 'mount|ext4|xfs|superblock|I/O error'

# 9. 실패한 systemd 유닛 확인
systemctl --failed

# 10. NFS 마운트 확인
findmnt -t nfs,nfs4

/dev/sdb1과 /mnt/data는 실제 서버의 장치와 마운트 경로로 변경해야 합니다.

원인을 확인하기 전에는 디스크를 포맷하거나 파일시스템 복구 명령어를 무작정 실행하지 않아야 합니다.

정리

리눅스 서버에서 Mount Failed 오류가 발생하면 먼저 디스크가 정상적으로 인식되는지 확인하고, 실제 UUID와 /etc/fstab 설정이 일치하는지 점검해야 합니다.

장치와 UUID가 정상이라면 파일시스템 유형, 마운트 옵션, 대상 디렉터리 및 커널 로그를 확인해야 합니다.

NFS 환경에서는 서버 연결과 Export 설정을, 부팅 시에만 실패하는 환경에서는 systemd 유닛과 장치·네트워크 준비 순서를 추가로 살펴봐야 합니다.

핵심 점검 순서는 장치 인식 확인 → UUID 및 fstab 검증 → 파일시스템·마운트 옵션 점검 → 커널 로그 분석 → NFS 또는 systemd 확인 → 안전한 복구입니다.