서버에서 데이터베이스 파일을 열지 못할 때

로컬에서는 문제없이 동작하는데, 운영 서버에만 가면 데이터베이스 파일을 열 수 없다는 에러가 난다. 대개 권한, 경로, 또는 프로세스 문제다.

실제 에러 메시지를 정확히 읽는다

먼저 에러 메시지를 전체적으로 본다:

Error: EACCES: permission denied, open '/data/app.db'

또는

Error: ENOENT: no such file or directory, open '/var/lib/app/data.sqlite'

EACCES는 권한 문제, ENOENT는 파일을 찾을 수 없다는 뜻이다.

파일이 실제로 존재하는지 확인한다

ls -la /data/app.db

파일이 없다면 어디에 있는지 찾는다.

find /home /opt /var -name 'app.db' -type f 2>/dev/null

또는 application이 생성한다면, 직접 생성해본다:

touch /data/app.db

권한을 확인한다

ls -la /data/app.db

결과가:

-rw-r--r-- 1 root root 4096 Jun 30 10:00 /data/app.db

이라면, 파일 소유자가 root인데 애플리케이션이 다른 사용자(예: app, node)로 실행될 수 있다. 이 경우 소유권을 변경해야 한다.

sudo chown app:app /data/app.db
sudo chmod 644 /data/app.db

디렉토리 권한도 확인한다

파일 자체뿐 아니라 디렉토리 권한도 중요하다.

ls -ld /data/

결과가:

drwxr-xr-x 2 root root 4096 Jun 30 10:00 /data/

라면, 소유자를 변경해야 할 수 있다:

sudo chown app:app /data/

애플리케이션이 어떤 사용자로 실행되는지 확인한다

ps aux | grep app

USER 컬럼을 보면 어떤 사용자로 실행 중인지 알 수 있다.

만약 root로 실행되고 있다면 피해야 한다. 전용 사용자로 변경하는 게 낫다.

경로를 확인한다

혹시 경로가 상대 경로라서 잘못 인식됐나?

cd /app && ls -la database.db  # 상대 경로
ls -la /data/database.db      # 절대 경로

Application 시작 위치에 따라 상대 경로의 의미가 달라진다. 절대 경로를 사용하는 게 낫다.

마운트 포인트를 확인한다

만약 Docker를 쓴다면, 볼륨 마운트가 제대로 됐나?

docker inspect <container-id> | grep -A 10 Mounts

볼륨이 제대로 마운트되지 않으면, 컨테이너 내부의 경로가 호스트의 실제 경로와 다를 수 있다.

SELinux가 차단하고 있지는 않나

CentOS나 Red Hat 기반 시스템이라면 SELinux 때문일 수 있다.

getenforce

Enforcing이면 SELinux가 활성화된 상태다. 로그를 확인한다:

sudo tail -f /var/log/audit/audit.log | grep denied

필요하면 정책을 변경한다:

sudo semanage fcontext -a -t admin_home_t '/data(/.*)?'
sudo restorecon -Rv /data

파일 시스템이 읽기 전용이지는 않나

mount | grep '/data'

RO(read-only)라고 표시되면 쓰기가 불가능하다. 마운트를 다시 해야 한다:

sudo mount -o remount,rw /data

디스크 용량을 확인한다

df -h /data

100% 찬 경우 새 파일을 쓸 수 없다. 불필요한 파일을 정리해야 한다.

애플리케이션 설정을 다시 본다

혹시 실수로 DB 경로를 잘못 설정했나?

grep -r "database\|db\|sql" /etc/app/config.json

설정 파일에서 데이터베이스 경로를 확인한다.

결론

DB 파일 접근 에러는 보통 권한, 경로, 혹은 파일 존재 문제다. 에러 메시지를 읽고, 파일 존재 여부와 권한을 확인하고, 애플리케이션 설정을 검토하면 대부분 해결된다.