리눅스 서버에서 파일을 열거나 저장하려고 했는데 갑자기 permission denied 오류가 뜨면, 대부분 명령어가 틀린 게 아니라 현재 사용자와 파일 권한이 맞지 않는 상황입니다. 특히 설정 파일 수정, 로그 저장, 배포 스크립트 실행처럼 평소엔 되던 작업이 막히면 먼저 파일 소유자와 디렉터리 권한부터 확인해야 합니다.
실무에서는 파일 하나의 권한만 보는 것보다, 경로 전체에 실행 권한이 있는지와 현재 어떤 사용자로 작업 중인지를 같이 봐야 원인을 빨리 찾을 수 있습니다. 아래 순서대로 확인하면 permission denied 오류 해결 순서를 크게 놓치지 않습니다.
실제로 막히는 상황
예를 들어 웹 서버 설정 파일을 수정하려고 했는데 저장이 안 되거나, 배포 스크립트를 실행했는데 접근 권한이 없다고 나올 수 있습니다. 또 로그 파일을 확인하려고 했는데 파일은 존재하는데도 읽히지 않는 경우가 있습니다. 이런 상황에서 파일 자체가 있는지보다 읽기(r), 쓰기(w), 실행(x) 중 무엇이 부족한지를 먼저 봐야 합니다.
특히 디렉터리에는 파일과 다른 기준이 적용됩니다. 파일은 읽기 권한이 중요하지만, 디렉터리는 그 안으로 들어가거나 파일 이름을 조회하려면 실행 권한이 필요합니다. 그래서 “파일은 644인데 왜 못 열지?” 같은 상황이 디렉터리 권한 문제인 경우가 많습니다.
먼저 의심하기 쉬운 부분
permission denied 오류가 나면 많은 경우 아래부터 확인합니다.
- 현재 로그인한 사용자가 맞는지
- 파일 소유자가 내 계정인지
- 파일 권한에 읽기/쓰기 권한이 있는지
- 상위 디렉터리에 실행 권한이 있는지
- root 권한이 필요한 작업을 일반 계정으로 하고 있지 않은지
이 순서가 중요한 이유는, 파일 권한만 바꿔도 해결되지 않는 경우가 꽤 많기 때문입니다. 예를 들어 파일은 755인데 상위 폴더가 700이면 접근이 막힙니다. 반대로 디렉터리는 열렸지만 파일 소유자가 다르고 쓰기 권한이 없어서 저장이 안 되는 경우도 있습니다.
실제 원인 후보
실무에서 자주 만나는 원인은 크게 네 가지입니다.
- 소유자 문제: 파일 주인이 다른 사용자라서 접근이 안 되는 경우
- 권한 문제: chmod 값이 부족해서 읽기/쓰기/실행이 막힌 경우
- 경로 문제: 현재 위치와 실제 파일 위치가 달라서 엉뚱한 파일을 건드리는 경우
- 서비스 실행 계정 문제: systemd 서비스가 내가 접속한 계정이 아닌 다른 계정으로 동작하는 경우
Node.js 서버 운영에서도 비슷합니다. 개발할 때는 내 계정으로 실행되다가, systemd로 올리면 다른 사용자로 떠서 로그 파일이나 업로드 디렉터리에 쓰지 못하는 일이 자주 생깁니다.
확인 명령어
가장 먼저 현재 위치와 파일 정보를 확인합니다.
pwd
ls -l /var/www/html/index.html
namei -l /var/www/html/index.html정상이라면 현재 위치가 예상한 디렉터리로 나오고, 파일 소유자와 권한도 함께 보입니다. namei -l은 경로 전체를 단계별로 보여줘서 상위 디렉터리 권한 문제를 찾는 데 유용합니다.
/var/www/project
-rw-r--r-- 1 deploy deploy 1240 May 12 10:20 /var/www/html/index.html
f: /var/www/html/index.html
drwxr-xr-x root root /
drwxr-xr-x root root var
drwxr-xr-x root root www
drwxr-xr-x root root html
-rw-r--r-- deploy deploy index.html반대로 문제가 있는 경우는 이런 식으로 보일 수 있습니다.
ls: cannot access '/var/www/html/index.html': Permission denied
namei: /var/www/html/index.html: Permission denied이 경우 파일 하나만 볼 게 아니라 /var, /var/www, /var/www/html 중 어느 구간에서 막히는지 봐야 합니다.
정상 출력 예시
읽기 가능한 파일이라면 보통 아래처럼 확인됩니다.
$ ls -l ./config.json
-rw-r--r-- 1 deploy deploy 532 May 12 09:00 ./config.json디렉터리 접근도 정상이라면 다음처럼 나옵니다.
$ ls -ld /opt/app/logs
drwxr-xr-x 2 deploy deploy 4096 May 12 09:10 /opt/app/logs여기서 중요한 점은 디렉터리에는 x 권한이 있어야 들어갈 수 있다는 것입니다. 파일 목록을 읽는 것과 디렉터리에 진입하는 것은 다른 기준으로 판단합니다.
잘못된 상태 예시
아래처럼 나오면 쓰기 또는 실행 권한이 부족한 상태입니다.
$ ls -ld /opt/app/logs
drwxr-x--- 2 root root 4096 May 12 09:10 /opt/app/logs이 상태에서 일반 사용자가 접근하면 permission denied가 날 수 있습니다. 또 파일은 읽기 가능해 보여도 상위 경로가 닫혀 있으면 열리지 않습니다.
$ namei -l /opt/app/logs/app.log
f: /opt/app/logs/app.log
drwxr-xr-x root root /
drwxr-xr-x root root opt
drwxr-xr-x root root app
drwxr-x--- root root logs
-rw-r--r-- root root app.log이 경우 문제는 app.log가 아니라 logs 디렉터리입니다. 디렉터리 권한이 막혀서 파일까지 못 들어가는 상황입니다.
해결 방법
원인에 따라 접근 방법이 다릅니다. 우선 파일 소유자와 권한을 맞추는 것이 기본입니다. 이전에 확인한 chown 명령어가 필요한 경우에 해당하면 소유자를 바꾸는 것이 먼저고, 권한 값이 부족하면 chmod를 검토합니다.
예를 들어 웹 서비스 계정이 파일을 써야 한다면 소유자를 서비스 계정으로 바꾸거나, 필요한 범위만 권한을 열어야 합니다.
sudo chown deploy:deploy /opt/app/logs/app.log
sudo chmod 664 /opt/app/logs/app.log반대로 운영 서버에서는 무작정 777로 바꾸면 안 됩니다. 동작은 할 수 있지만 보안상 위험하고, 나중에 다른 문제를 만들 가능성이 큽니다. 권한을 넓히기 전에 누가 이 파일을 읽고 써야 하는지를 먼저 정해야 합니다.
디렉터리 권한이 부족한 경우에는 해당 디렉터리에 진입할 수 있도록 x 권한이 필요합니다. 다만 공용 디렉터리라도 최소 권한으로 조정하는 편이 안전합니다.
CentOS와 Ubuntu에서 같이 확인할 점
권한 확인 명령어 자체는 CentOS와 Debian/Ubuntu에서 거의 같습니다. 다만 시스템 서비스나 로그 위치를 볼 때 차이가 생길 수 있습니다.
- systemd 서비스 상태는 둘 다
systemctl status 서비스명으로 확인 - 로그는 Ubuntu/Debian에서
/var/log기반으로 보는 일이 많고, CentOS도 대부분 비슷하지만 서비스별 위치를 따로 확인해야 함 - 보안 정책 때문에 CentOS 계열에서는 SELinux 영향도 함께 의심해야 하는 경우가 있음
즉, permission denied가 파일 권한처럼 보여도 실제로는 보안 정책이나 서비스 실행 계정 문제일 수 있습니다. 특히 systemd 서비스가 특정 사용자로 떠 있는지 확인해야 합니다.
systemctl status nginx
ps -ef | grep node정상 출력 예시는 이런 식입니다.
● nginx.service - The nginx HTTP and reverse proxy server
Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; vendor preset: disabled)
Active: active (running) since Mon 2026-05-12 10:00:00 KST; 10min ago여기서 서비스가 다른 계정으로 실행 중이면, 그 계정이 접근 가능한 파일 경로와 권한을 다시 맞춰야 합니다.
초보자가 자주 놓치는 부분
가장 흔한 실수는 파일 권한만 바꾸고 디렉터리를 확인하지 않는 것입니다. 두 번째는 root로는 되는데 일반 사용자로는 안 되는 상황을 “파일이 고장났다”고 오해하는 것입니다. 세 번째는 편하게 해결하려고 권한을 과하게 열어두는 것입니다.
또 하나 중요한 점은 SSH로 접속한 계정과 실제 서비스 실행 계정이 다를 수 있다는 것입니다. 내 SSH 계정에서는 파일이 보이는데 systemd 서비스에서는 permission denied가 나는 경우가 여기에 해당합니다.
운영 서버에서 chmod, chown, rm 같은 명령어를 바로 실행하기 전에 현재 소유자와 경로를 먼저 확인하세요. 특히 여러 서비스가 같은 디렉터리를 공유하는 경우, 권한을 잘못 바꾸면 다른 서비스까지 함께 영향을 받을 수 있습니다.
만약 Node.js 앱이 systemd로 올라가 있는데 로그 파일에 쓰지 못한다면, 앱 코드보다 먼저 로그 디렉터리 소유권과 권한을 확인하는 편이 빠릅니다. 반대로 SSH 자체가 거부된다면 파일 권한보다 계정 잠금, 키 권한, 방화벽, 포트 문제까지 함께 봐야 합니다.
마지막 체크리스트
- 현재 로그인한 사용자와 서비스 실행 사용자가 같은지 확인했는가
ls -l로 파일 소유자와 권한을 확인했는가namei -l로 경로 전체 권한을 확인했는가- 디렉터리에 실행 권한이 있는지 봤는가
- root로만 되는 작업인지 판단했는가
- CentOS의 SELinux나 서비스 정책까지 의심해야 하는지 확인했는가
- 권한을 넓히기 전에 백업이나 테스트를 먼저 했는가
permission denied 오류 해결 순서는 복잡해 보여도 결국 사용자, 소유자, 권한, 경로 네 가지를 차례대로 확인하는 일입니다. 이 순서만 잡아도 불필요한 chmod 반복을 줄이고, 실제 원인에 더 빨리 도달할 수 있습니다.
