Permission denied: /dev/null 포함 10가지 사례

Permission denied는 리눅스에서 지금 계정에 그 파일이나 폴더, 명령을 쓸 권한이 없을 때 나오는 오류입니다. 오류 줄 앞의 명령 이름과 경로로 어떤 경우인지 고른 뒤 ls -l로 권한과 소유자를 확인하고, 그 경우에 맞는 권한이나 계정으로 다시 실행하면 해결됩니다.

아래 출력은 AlmaLinux 9.8 서버의 root 계정과 Debian 12 서버의 일반 계정에서 실행한 결과이며, 계정과 호스트 이름, /dev/null 출력의 시각은 예시 값입니다.

1️⃣ Permission denied 원인 확인

오류 줄은 [명령: 대상: Permission denied] 꼴로 끝나며, 앞에 붙은 명령 이름과 경로로 어디에서 막혔는지 확인할 수 있습니다. 아래 그림에서 내 화면과 닮은 오류 문구를 고르면 먼저 볼 명령과 이 글에서 읽을 자리가 나옵니다.

2️⃣ 자주 나오는 Permission denied

🔲 파일 읽기와 쓰기 권한

파일을 읽으려면 그 계정에 읽기(r) 권한이, 고치거나 새로 만들려면 쓰기(w) 권한이 있어야 합니다. 권한을 600으로 둔 secret.txt는 소유자 root만 읽고 쓸 수 있습니다.

ls -l secret.txt

-rw------- 1 root root 16 Oct 29 00:29 secret.txt

runuser -u daemon -- cat secret.txt

cat: secret.txt: Permission denied

다른 계정 daemon으로 같은 파일을 읽자 바로 거절되었습니다. 쓰기 권한이 없는 폴더 안에 파일을 만들 때도 같은 오류가 나며, Debian 12 서버의 일반 계정에서 권한을 000으로 둔 lock 폴더에 touch가 막혔습니다.

touch ~/touchtest/lock/x.txt

touch: cannot touch '/home/user/touchtest/lock/x.txt': Permission denied

ls -l 첫 칸에서 소유자, 그룹, 그 밖의 계정 순으로 r과 w가 있는지 보고, 필요한 계정에만 chmod로 권한을 더하거나 chown으로 소유자를 바꿉니다.

🔲 폴더 통과 권한

파일 권한이 맞아도 경로 중간 폴더에 x 권한이 없으면 그 안의 파일에 닿지 못합니다. 폴더에서 x는 그 폴더를 지나 안으로 들어가는 권한이고, r은 안의 이름 목록을 읽는 권한입니다.

ls -ld web web/css

drw-r--r-- 3 root root 35 Oct 29 00:29 web
drw-r--r-- 2 root root 23 Oct 29 00:29 web/css

runuser -u daemon -- ls -l web

ls: cannot access 'web/css': Permission denied
ls: cannot access 'web/index.html': Permission denied
total 0
d????????? ? ? ? ?            ? css
-????????? ? ? ? ?            ? index.html

web 폴더에 r만 있어 daemon은 안의 이름 css와 index.html까지 읽었지만, x가 없어 권한과 크기는 물음표로 남았습니다. 반대로 x만 있고 r이 없는 site 폴더는 목록이 막혔고, 이름을 알고 있는 파일은 읽혔습니다.

ls -ld site

drwx--x--x 2 root root 24 Oct 29 00:29 site

runuser -u daemon -- ls site

ls: cannot open directory 'site': Permission denied

runuser -u daemon -- cat site/index.html

<h1>index</h1>

경로가 길면 ls -ld로 위 폴더부터 하나씩 x가 있는지 확인하고, 막힌 폴더에 그 계정이 지나갈 x만 더합니다.

🔲 실행 권한

스크립트를 ./파일 이름으로 실행하려면 그 파일에 x 권한이 있어야 합니다. 권한이 644인 deploy.sh는 실행이 거절되었습니다.

ls -l deploy.sh

-rw-r--r-- 1 root root 8 Oct 29 00:29 deploy.sh

./deploy.sh

bash: line 1: ./deploy.sh: Permission denied

chmod u+x로 소유자에게 x를 더하자 첫 칸이 [-rwxr--r--]로 바뀌었습니다.

chmod u+x deploy.sh

ls -l deploy.sh

-rwxr--r-- 1 root root 8 Oct 29 00:29 deploy.sh

x 권한이 있는데도 실행이 거절되면 그 파일이 있는 파일 시스템이 noexec로 마운트되어 있는지 확인합니다.

🔲 root 몫 읽기

일반 계정은 root가 띄운 프로세스나 다른 계정의 비밀번호 정보처럼 시스템이 root 몫으로 둔 정보를 읽지 못합니다. Debian 12 서버의 일반 계정에서 1번 프로세스의 fd 폴더를 열자 권한 오류가 났습니다.

ls /proc/1/fd

ls: cannot open directory '/proc/1/fd': Permission denied

chage -l daemon

chage: Permission denied.

다른 계정의 비밀번호 만료 정보도 같은 이유로 막혔으며, 이 정보가 든 /etc/shadow는 일반 사용자가 읽을 수 없게 두는 파일입니다. 이런 오류는 권한을 넓히지 않고 sudo나 root 계정으로 다시 실행합니다.

🔲 sudo를 붙여도 >가 막힐 때

sudo는 그 뒤에 적은 명령만 root로 실행하고, 리다이렉션(>)으로 파일을 여는 일은 명령이 실행되기 전에 지금 계정의 셸이 처리합니다. 그래서 root만 쓸 수 있는 파일로 sudo echo의 출력을 리다이렉션하면, 오류 줄이 셸 이름으로 시작하는 [bash: 파일 경로: Permission denied] 꼴로 나옵니다.

sudo echo x > /root/test.txt

리다이렉션까지 root로 하려면 sh -c로 줄 전체를 감싸 셸까지 sudo로 실행하며, sudo 공식 매뉴얼도 리다이렉션이 되도록 sh -c 안에서 실행하는 예를 들고 있습니다.

sudo sh -c 'echo x > /root/test.txt'

tee는 표준 입력을 받아 적어 준 파일에 직접 쓰므로, tee를 sudo로 실행하면 파일은 root 권한의 tee가 엽니다. tee는 받은 내용을 화면에도 한 번 더 출력합니다.

echo x | sudo tee /root/test.txt

🔲 SSH 접속 거절

Permission denied 앞에 [계정@서버 주소:]가 붙고 괄호 안에 publickey 같은 인증 방식이 있으면 접속 인증 단계에서 거절된 경우이며, 파일 권한과는 확인할 곳이 다릅니다. 서버의 sshd는 StrictModes 설정이 기본값 yes라, 로그인을 받기 전에 그 계정의 홈 폴더와 파일의 권한, 소유자를 검사합니다. 홈 폴더와 ~/.ssh 폴더, ~/.ssh/authorized_keys 가운데 하나라도 다른 계정이 쓸 수 있으면 sshd가 그 키 파일을 사용하지 않으므로, ls -ld로 세 곳에 다른 계정의 w 권한이 없는지 확인합니다.

⌨️ Permission denied 시뮬레이터

아래 시뮬레이터는 root 계정으로 시작하며, runuser로 다른 계정 daemon이 되어 파일 읽기와 폴더 통과, 실행 권한에서 막히는 출력을 직접 확인할 수 있습니다.

3️⃣ 드문 Permission denied

권한 칸이 맞는데도 거절되면 SELinux 정책이나 noexec 마운트처럼 권한 비트 밖에서 막은 경우입니다. root로 실행했는데도 실행이 거절되면 그 파일에 x 비트가 하나도 없는지 확인합니다.

getenforce

ausearch -m AVC,USER_AVC,SELINUX_ERR,USER_SELINUX_ERR -ts today

findmnt -T /tmp -o TARGET,OPTIONS

🔲 /dev/null이 일반 파일로 바뀐 경우

일반 계정으로 SSH에 들어오자마자 셸 프롬프트보다 먼저 아래 줄이 연달아 찍히면, 모든 계정이 출력을 버리는 문자 장치 /dev/null이 root 소유의 일반 파일로 바뀌지 않았는지 먼저 확인합니다. 줄 수는 로그인할 때 읽는 profile 스크립트 수에 따라 서버마다 다르며, 같은 서버에서 root로 바꾼 뒤에는 이 오류가 나지 않았습니다.

-bash: /dev/null: Permission denied
-bash: /dev/null: Permission denied
-bash: /dev/null: Permission denied
...

ls -l /dev/null

-rw-r--r-- 1 root root 55 Jan 10 09:00 /dev/null

stat -c %F /dev/null

regular file

첫 칸이 [-rw-r--r--]이고 크기 자리에 55가 찍혀, 다른 명령이 버린 오류 글자가 파일로 쌓여 있었습니다. 정리 명령 줄에 아래 꼴이 섞여 root로 실행되면 rm이 장치 파일을 지우고, 그다음 명령의 2>/dev/null 리다이렉션이 같은 이름으로 root 소유 일반 파일을 새로 만듭니다.

rm -f /dev/null 2>/dev/null

아래 줄은 root로 실행합니다. 새 장치를 옆 이름으로 만든 뒤 mv로 덮어쓰면 이름이 비는 순간이 없어, 지운 다음 만드는 사이에 다른 리다이렉션이 일반 파일을 또 만들 틈을 남기지 않습니다.

mknod -m 666 /dev/null.new c 1 3 && mv -f /dev/null.new /dev/null && ls -l /dev/null

crw-rw-rw- 1 root root 1, 3 Jan 10 09:05 /dev/null

stat -c %F /dev/null

character special file

mknod의 [c 1 3]은 커널 장치 번호 목록에서 /dev/null의 번호입니다. 복구한 뒤 일반 계정의 echo x > /dev/null도 오류 없이 끝났습니다. 재부팅으로 돌아올 수도 있지만, 서버를 멈추지 않는 위 한 줄이 더 빠릅니다.

버릴 출력은 >/dev/null이나 2>/dev/null로 넘기기까지만 하고, 복구할 때가 아니면 /dev/null을 rm이나 mv 대상으로 적지 않습니다.

🔢 FAQ & 추천 콘텐츠

🔗 추천 콘텐츠

권한 · 소유권 리눅스 퍼미션(4,2,1)과 소유권 | chmod, chown, umask 명령어 Permission denied가 난 파일과 폴더의 권한 숫자를 읽고, chmod와 chown으로 필요한 계정에만 권한을 주는 방법을 다룬 글입니다. 글 보기 →

웹 서버 · 403 APM 설치 후 아파치 403 에러(403 Forbidden) 웹 서버가 웹 폴더를 읽지 못해 error_log에 Permission denied가 남고 403이 뜬 경우를 다룬 글입니다. 웹 서버 · 503 APM 설치 후 503 에러 Apache가 php-fpm 소켓에 붙지 못해 503이 난 경우를 error.log로 확인한 글입니다. 프로세스 · 우선순위 리눅스 nice 명령어: 우선순위 지정과 renice 변경, CPU를 다툴 때의 몫 실측 일반 계정이 nice 값을 낮춰 우선순위를 올리려 할 때 권한 오류가 나는 경우까지 시뮬레이터로 확인하는 글입니다.

ℹ️ 제휴 안내
본 사이트의 콘텐츠에는 제휴 링크가 포함되어 있습니다. 방문자가 이 링크를 통해 상품 또는 서비스를 구매하면 본 사이트는 판매처로부터 수수료를 지급받습니다. 이 과정에서 구매자가 지불하는 금액^{(이벤트 할인 시 금액이 내려갑니다↓)}은 오르지 않습니다. 게시된 가격·할인·재고 정보는 작성 시점 기준이며 실제와 다를 수 있으므로, 구매 전 판매처에서 최종 확인하시기 바랍니다. 상품 선정과 평가는 자체 기준에 따라 작성되며, 수수료 지급 여부가 소개 순서나 평가 내용에 영향을 주지 않습니다.