파일은 분명히 있고 권한도 크게 막혀 보이지 않는데, 웹서버나 Node.js 애플리케이션이 업로드 파일을 저장하지 못하거나 로그 파일을 갱신하지 못하는 경우가 있습니다. 이 글은 그런 상황에서 chmod로 권한 숫자부터 바꾸기 전에, 파일 소유자와 실행 계정이 맞는지 확인하고 chown으로 수정해야 하는지 판단하는 순서를 정리한 문서입니다.
이 글에서 해결할 문제
리눅스 서버에서 파일 접근 오류는 크게 세 가지가 섞여 나타납니다. 파일 권한 문제, 파일 소유자 문제, 그리고 서비스를 실행하는 사용자 계정 문제입니다. 화면에는 모두 Permission denied처럼 보일 수 있지만, 실제 원인은 다를 수 있습니다.
서버를 운영하다 보면 처음에는 권한 숫자 문제처럼 보였지만 실제로는 파일이 root 소유로 생성되어 서비스 계정이 수정하지 못하는 경우가 많습니다. 이 오류를 몇 번 겪은 뒤에는 바로 chmod를 실행하기보다 먼저 whoami, id, ls -l, 서비스 실행 계정을 순서대로 확인하는 편이 훨씬 안전했습니다.
먼저 확인할 핵심 요약
| 확인 항목 | 명령어 예시 | 판단 기준 |
|---|---|---|
| 현재 접속 계정 | whoami, id |
내가 SSH로 접속한 계정과 서비스 계정은 다를 수 있음 |
| 파일 소유자 | ls -l 파일명 |
파일을 수정해야 하는 계정이 소유자인지 확인 |
| 디렉토리 소유자 | ls -ld 디렉토리 |
새 파일 생성이 안 되면 상위 디렉토리까지 확인 |
| 서비스 실행 사용자 | systemctl cat 서비스명 |
systemd의 User=, Group= 설정 확인 |
| 실제 오류 로그 | journalctl -u 서비스명 |
권한 오류가 어느 경로에서 발생하는지 확인 |
실제 서버 운영 중 헷갈리기 쉬운 지점
가장 헷갈리는 부분은 SSH로 접속한 사용자와 실제 서비스를 실행하는 사용자가 다르다는 점입니다. 예를 들어 운영자는 ubuntu 계정으로 접속하지만, Nginx는 Debian/Ubuntu 계열에서 보통 www-data로 실행됩니다. Node.js 앱은 PM2를 어떤 사용자로 실행했는지에 따라 파일 생성 주체가 달라질 수 있습니다.
또 하나는 파일 자체와 디렉토리의 차이입니다. 기존 파일을 수정하는 문제라면 파일 소유자와 쓰기 권한이 중요하고, 새 파일을 생성하는 문제라면 상위 디렉토리의 소유자와 쓰기 권한이 중요합니다. 업로드 폴더에서 자주 놓치는 부분이 바로 이 디렉토리 권한과 소유자입니다.
처음 의심하기 쉬운 원인과 실제 원인의 차이
Permission denied가 보이면 많은 경우 권한 숫자를 먼저 떠올립니다. 하지만 운영 서버에서는 권한을 넓히는 방식보다, 누가 파일을 관리해야 하는지부터 정리해야 합니다.
| 처음 의심하는 원인 | 실제로 자주 확인되는 원인 | 먼저 볼 것 |
|---|---|---|
| 파일 권한이 너무 낮다 | 파일이 root 소유라 서비스 계정이 수정하지 못함 | ls -l, id |
| 앱 코드가 파일을 못 쓴다 | 업로드 디렉토리 소유자가 서비스 계정과 다름 | ls -ld uploads |
| Nginx 또는 Node.js가 죽었다 | 서비스는 실행 중이지만 로그 경로에 쓰지 못함 | systemctl status, journalctl |
| 배포가 실패했다 | 배포 스크립트를 sudo로 실행해 결과물이 root 소유가 됨 | 배포 실행 계정과 생성 파일 소유자 |
실제로 자주 막히는 상황
- 웹 애플리케이션의 업로드 폴더에 이미지가 저장되지 않는다.
- Node.js 앱이 로그 파일을 만들지 못하고
EACCES: permission denied를 출력한다. - 배포 후 파일이 모두
root root소유로 바뀌어 앱에서 수정하지 못한다. - Nginx 403 오류가 발생했는데 root 경로의 파일 소유자와 권한이 맞지 않는다.
- PM2로 실행한 앱과 수동으로 실행한 앱의 파일 생성 소유자가 다르다.
- 백업이나 배치 작업이 웹서버가 만든 파일을 읽거나 갱신하지 못한다.
원인 분리: chown이 필요한지 확인하는 순서
운영 서버에서는 수정 명령어보다 확인 명령어를 먼저 실행하는 습관이 중요합니다. 아래 예시는 Debian/Ubuntu 계열 서버를 기준으로 설명합니다. CentOS 계열에서는 웹서버 계정이 apache인 경우가 많아 환경에 따라 계정명이 다를 수 있습니다.
1. 현재 내가 어떤 계정인지 확인
whoami
id예상 출력은 다음과 비슷합니다.
ubuntu
uid=1000(ubuntu) gid=1000(ubuntu) groups=1000(ubuntu),27(sudo)이 결과는 SSH 접속 계정을 보여줄 뿐입니다. 웹서버나 앱이 이 계정으로 실행된다는 뜻은 아닙니다.
2. 문제가 나는 파일과 디렉토리의 소유자 확인
ls -ld /var/www/example/uploads
ls -l /var/www/example/uploads예를 들어 다음처럼 나오면 업로드 디렉토리의 소유자가 root입니다.
drwxr-xr-x 2 root root 4096 May 11 10:20 /var/www/example/uploads
-rw-r--r-- 1 root root 1243 May 11 10:21 sample.png서비스가 www-data로 실행 중이라면 이 상태에서는 새 파일 생성이나 기존 파일 수정이 막힐 수 있습니다.
3. 서비스를 실행하는 사용자 확인
systemd로 실행되는 서비스라면 서비스 정의에서 실행 사용자를 확인합니다.
systemctl cat myapp.service | grep -E '^User=|^Group='
systemctl status myapp.service예상 출력은 환경마다 다르지만, 다음처럼 서비스 사용자가 지정되어 있을 수 있습니다.
User=www-data
Group=www-data만약 User=가 없으면 서비스가 어떤 방식으로 실행되는지 추가 확인이 필요합니다. PM2를 사용한다면 PM2를 실행한 사용자도 함께 봐야 합니다.
pm2 list
pm2 logs4. 로그에서 실제로 막힌 경로 확인
브라우저 화면이나 앱 응답만 보면 어느 파일에서 막혔는지 놓치기 쉽습니다. 화면에 보이는 오류보다 먼저 로그와 서비스 상태를 확인하는 편이 원인을 좁히기 쉽습니다.
journalctl -u myapp.service -n 50 --no-pagerNginx 관련 문제라면 다음 로그도 확인할 수 있습니다.
sudo tail -n 50 /var/log/nginx/error.log로그에 다음과 비슷한 내용이 보이면 파일 소유자와 디렉토리 권한을 같이 확인해야 합니다.
EACCES: permission denied, open '/var/www/example/uploads/a.png'
open() '/var/www/example/index.html' failed (13: Permission denied)chown 명령어가 필요한 경우
chown은 파일이나 디렉토리의 소유자, 그룹을 바꾸는 명령어입니다. 단순히 읽기 권한을 주는 명령이 아니라, 누가 그 파일을 관리할지 바꾸는 명령입니다. 따라서 아래처럼 소유자와 실제 실행 계정이 어긋난 경우에 사용을 검토합니다.
- 서비스 계정이 직접 생성하고 수정해야 하는 파일이 다른 계정 소유일 때
- 업로드, 캐시, 로그 디렉토리가 root 소유라 애플리케이션이 쓰지 못할 때
- 배포 과정에서 sudo를 사용해 결과물이 root 소유로 생성되었을 때
- 웹서버와 애플리케이션이 같은 경로를 사용하지만 파일 생성 주체가 꼬였을 때
- systemd의 실행 사용자와 파일 소유자가 다를 때
반대로 파일을 서비스가 직접 수정할 필요가 없는 정적 파일이라면, 무조건 웹서버 계정 소유로 바꾸는 것이 항상 정답은 아닙니다. 환경에 따라 배포 사용자 소유로 두고 읽기만 허용하는 구조가 더 적절할 수 있습니다.
잘못된 예시
다음은 운영 서버에서 자주 나오는 위험한 처리 방식입니다. 오류가 사라질 수도 있지만, 원인을 숨기거나 다른 서비스에 영향을 줄 수 있습니다.
# 문제가 나는 경로를 확인하지 않은 상태에서 전체 웹 루트 소유자를 변경
sudo chown -R www-data:www-data /var/www
# 현재 사용자가 누구인지, 서비스 계정이 무엇인지 확인하지 않고 실행
sudo chown -R www-data:www-data .-R 옵션은 하위 파일과 디렉토리 전체에 적용됩니다. 범위를 잘못 잡으면 배포 파일, 백업 파일, 다른 사이트 파일까지 한 번에 소유자가 바뀔 수 있습니다. 운영 서버에서는 먼저 단일 파일이나 문제 디렉토리만 확인하고, 필요한 경우에만 범위를 좁혀 적용하는 편이 안전합니다.
수정 예시: 업로드 디렉토리 소유자 맞추기
아래 예시는 Debian/Ubuntu에서 웹서버 또는 앱이 www-data 계정으로 실행되는 경우입니다. 실제 서버에서는 먼저 서비스 실행 계정이 정말 www-data인지 확인한 뒤 적용해야 합니다.
1. 적용 전 상태 확인
ls -ld /var/www/example/uploads
id www-data출력 예시는 다음과 같습니다.
drwxr-xr-x 2 root root 4096 May 11 10:20 /var/www/example/uploads
uid=33(www-data) gid=33(www-data) groups=33(www-data)2. 필요한 경로만 소유자 변경
sudo chown www-data:www-data /var/www/example/uploads이 명령은 해당 디렉토리 자체의 소유자만 바꿉니다. 이미 그 안에 생성된 파일까지 바꿔야 하는 상황이라면 먼저 목록을 확인한 뒤 범위를 정해야 합니다.
find /var/www/example/uploads -maxdepth 1 -ls하위 파일까지 같은 소유자로 맞춰야 하는 경우에는 경로를 매우 구체적으로 지정합니다.
sudo chown -R www-data:www-data /var/www/example/uploads위 명령은 하위 파일 전체에 영향을 줍니다. 실행 전 대상 경로가 맞는지 pwd, ls -ld, find로 확인하고, 다른 사이트나 다른 서비스의 파일이 섞여 있지 않은지 확인해야 합니다.
수정 예시: root 소유로 생성된 단일 파일만 변경
배포 후 특정 파일 하나만 root 소유가 된 경우에는 전체 디렉토리를 바꾸지 말고 해당 파일만 수정하는 편이 안전합니다.
ls -l /var/www/example/index.html-rw-r--r-- 1 root root 1243 May 11 10:20 /var/www/example/index.html서비스나 배포 구조상 해당 파일을 www-data가 관리해야 한다면 다음처럼 변경합니다.
sudo chown www-data:www-data /var/www/example/index.html다만 정적 파일을 배포 사용자가 관리하고 웹서버는 읽기만 하는 구조라면, 소유자를 꼭 www-data로 바꿀 필요가 없을 수 있습니다. chown은 운영 방식에 맞게 적용해야 합니다.
수정 후 확인 방법
chown을 실행한 뒤에는 명령이 성공했는지만 보지 말고, 실제 서비스 계정 기준으로 접근 가능한지 확인해야 합니다.
1. 소유자 변경 확인
ls -ld /var/www/example/uploads
ls -l /var/www/example/index.html예상 출력은 다음과 비슷합니다.
drwxr-xr-x 2 www-data www-data 4096 May 11 10:20 /var/www/example/uploads
-rw-r--r-- 1 www-data www-data 1243 May 11 10:20 /var/www/example/index.html2. 서비스 로그 재확인
journalctl -u myapp.service -n 50 --no-pagerPM2로 Node.js 앱을 운영한다면 다음도 확인합니다.
pm2 logs같은 Permission denied가 계속 나온다면 파일 하나가 아니라 상위 디렉토리, 앱 설정의 저장 경로, 또는 서비스 실행 사용자가 다를 수 있습니다.
3. 실제 쓰기 동작 확인
테스트 파일을 생성해야 한다면 서비스가 사용하는 경로가 맞는지 먼저 확인합니다. 운영 중인 업로드 디렉토리에 임의 파일을 만들 때는 파일명 충돌이 없는지 주의해야 합니다.
sudo -u www-data touch /var/www/example/uploads/permission-test.tmp
ls -l /var/www/example/uploads/permission-test.tmp
sudo -u www-data rm /var/www/example/uploads/permission-test.tmpsudo -u www-data는 해당 사용자 권한으로 명령을 실행해 보는 방법입니다. 이 명령도 실제 파일을 만들고 지우므로, 테스트 경로가 맞는지 확인한 뒤 사용해야 합니다.
CentOS 계열과 Debian/Ubuntu 계열의 차이
chown 명령어 사용법은 대부분의 리눅스 배포판에서 비슷하지만, 웹서버 계정명은 다를 수 있습니다. Debian/Ubuntu 계열에서는 www-data를 자주 사용하고, CentOS/RHEL 계열에서는 apache를 사용하는 경우가 많습니다.
# Debian/Ubuntu에서 자주 보는 예시
sudo chown www-data:www-data /var/www/example/uploads
# CentOS/RHEL 계열에서 자주 보는 예시
sudo chown apache:apache /var/www/example/uploads환경에 따라 Nginx를 별도 사용자로 실행하거나, Node.js 앱을 일반 배포 사용자로 실행할 수도 있습니다. 계정명은 추측하지 말고 서비스 설정과 프로세스 상태로 확인하는 것이 좋습니다.
ps -eo user,group,comm | grep -E 'nginx|node|apache'재발 방지 체크리스트
- 배포 스크립트를 어떤 사용자로 실행하는지 확인한다.
- sudo로 빌드하거나 파일을 생성한 뒤 결과물이 root 소유가 되지 않았는지 확인한다.
- 업로드, 캐시, 로그처럼 서비스가 쓰는 디렉토리는 소유자와 그룹 기준을 정해 둔다.
- 파일 오류가 나면 chmod보다 먼저
ls -l,ls -ld,id를 확인한다. - systemd 서비스의
User=,Group=설정과 실제 파일 소유자가 맞는지 확인한다. - PM2를 사용하는 경우 PM2를 실행한 사용자와 앱이 쓰는 경로의 소유자를 함께 확인한다.
chown -R은 대상 경로를 충분히 확인한 뒤 필요한 범위에만 적용한다.- 오류 화면만 보지 말고
journalctl, Nginx error log, PM2 logs를 함께 확인한다. - 정적 파일, 업로드 파일, 로그 파일처럼 성격이 다른 파일을 같은 기준으로 바꾸지 않는다.
정리
파일 접근 오류가 발생했을 때 chown이 필요한지는 “권한 숫자가 몇인가”보다 “누가 이 파일을 만들고 수정해야 하는가”로 판단하는 편이 정확합니다. 특히 웹서버, Node.js 앱, 배포 사용자, root 계정이 함께 등장하는 서버에서는 파일 소유자가 쉽게 섞입니다.
운영 중에는 먼저 현재 사용자, 파일 소유자, 디렉토리 소유자, 서비스 실행 사용자, 로그 경로를 확인한 뒤 필요한 범위에만 chown을 적용하는 것이 안전합니다. 이렇게 확인 순서를 고정해 두면 같은 Permission denied 오류를 만났을 때 원인을 훨씬 빠르게 좁힐 수 있습니다.
FAQ
Q1. Permission denied가 나오면 무조건 chown을 해야 하나요?
아닙니다. Permission denied는 파일 권한, 디렉토리 권한, 소유자, 실행 사용자, 경로 오류 등 여러 원인으로 발생할 수 있습니다. 먼저 ls -l, ls -ld, whoami, id, 서비스 로그를 확인한 뒤 소유자 불일치가 확인될 때 chown을 검토하는 것이 좋습니다.
Q2. www-data로 모두 바꾸면 안전한가요?
항상 그렇지는 않습니다. Debian/Ubuntu의 웹서버 계정으로 www-data를 많이 사용하지만, 모든 파일을 웹서버 계정 소유로 바꾸는 것이 좋은 구조는 아닐 수 있습니다. 업로드나 캐시처럼 서비스가 직접 써야 하는 경로와, 배포 사용자가 관리하고 웹서버가 읽기만 하는 정적 파일은 기준을 다르게 잡을 수 있습니다.
Q3. chown -R은 언제 사용해야 하나요?
하위 파일과 디렉토리까지 모두 같은 소유자로 맞춰야 한다는 근거가 있을 때만 사용합니다. 실행 전에는 ls -ld, find 경로 -maxdepth 1 -ls 등으로 대상 범위를 확인해야 합니다. 운영 서버에서 경로를 잘못 지정하면 다른 서비스 파일까지 영향을 받을 수 있으므로, 가능하면 단일 파일이나 좁은 디렉토리부터 확인하는 것이 안전합니다.