Linux drwxr-xr-x 권한 의미와 755 설정 완벽 정리

drwxr-xr-x의 의미

drwxr-xr-x은 소유자가 변경할 수 있고, 다른 모든 사용자는 읽기 및 접근만 가능하며 내용을 수정할 수는 없는 디렉터리를 의미합니다. 8진수 모드로는 755입니다. Linux는 ls -l 출력의 각 줄 시작 부분에 이 10개의 문자를 표시합니다. 이 문자열은 항상 동일한 순서로 같은 의미를 가지므로, 하나만 익히면 모든 경우에 적용할 수 있습니다.

테스트 결과의 신뢰성을 결정하는 가장 중요한 규칙이 하나 있습니다. root 사용자는 권한 비트를 무시합니다. 커널은 root에게 CAP_DAC_OVERRIDE 기능(임의 접근 제어 무시)을 부여하므로, root는 모드 설정상 금지된 파일도 열 수 있습니다. 이 페이지의 모든 예제는 비트 설정과 관계없이 root에게는 성공합니다. 규칙이 실제로 작동하는지 확인하려면 일반 사용자로 로그인하십시오.

10개의 문자, 하나씩 살펴보기

디렉터리와 파일을 하나씩 생성하여 확인합니다. 이 과정에서 새로운 디렉터리 외부의 파일은 전혀 건드리지 않습니다.

mkdir -p ~/permdemo/inner
printf 'hello\n' > ~/permdemo/inner/notes.txt
ls -ld ~/permdemo ~/permdemo/inner ~/permdemo/inner/notes.txt

일반적인 기본 umask 값인 022를 사용할 때, 디렉터리 두 줄은 drwxr-xr-x로 시작하고 파일 줄은 -rw-r--r--로 시작합니다.

첫 번째 문자는 권한이 아닌 파일 유형입니다. d은 디렉터리입니다. -는 일반 파일입니다. l는 심볼릭 링크입니다. c과 b은 각각 문자 및 블록 장치 노드입니다. s은 소켓이며, p는 네임드 파이프입니다. 이 문자는 8진수 값 외부에 위치하므로 drwxr-xr-x이 d로 시작하는 값이 아닌 755가 됩니다.

그 뒤에 오는 9개의 문자는 3개씩 세 그룹으로 나뉘며, 순서는 절대 바뀌지 않습니다.

• 2~4번째 문자는 소유자(owner) 그룹으로, 파일 소유자에게 적용되는 비트입니다.
• 5~7번째 문자는 그룹(group) 그룹으로, 파일의 그룹에 적용되는 비트입니다.
• 8~10번째 문자는 기타(other) 그룹으로, 그 외 모든 사용자에게 적용되는 비트입니다.

그룹 내의 슬롯은 항상 r, w, x 순서이며, 대시(-)는 해당 비트가 꺼져 있음을 의미합니다. 문자의 위치는 절대 변하지 않습니다. r-x는 쓰기 권한이 없는 읽기 권한입니다. -w-은 읽기 권한이 없는 쓰기 권한이며, 이는 허용되지만 드문 경우입니다.

따라서 drwxr-xr-x은 다음과 같이 나뉩니다. 디렉터리에 대해 d, 소유자에 대해 rwx, 그룹에 대해 r-x, 기타 사용자에 대해 r-x입니다.

일부 시스템은 11번째 문자를 출력하기도 합니다. 마지막에 붙는 점(.)인 drwxr-xr-x.는 해당 파일이 SELinux(Security Enhanced Linux) 컨텍스트를 포함하고 있음을 의미하며, Fedora나 Rocky와 같은 SELinux 배포판은 기본적으로 이를 출력합니다. 마지막에 붙는 더하기(+)인 drwxr-xr-x+은 해당 파일이 이 9개의 비트를 넘어선 추가 규칙 세트인 POSIX ACL(Access Control List)을 포함하고 있음을 의미합니다. 이러한 추가 규칙은 getfacl <path> 명령으로 읽을 수 있습니다.

디렉터리에서 r, w, x 권한은 서로 다른 역할을 합니다

초보자가 가장 흔히 오해하는 첫 번째 규칙입니다. 파일과 디렉터리에서 문자는 같지만, 부여하는 권한은 다릅니다.

• 파일의 r는 내용을 읽습니다. 디렉터리의 r은 내부 파일 목록을 확인하며, 이는 일반적인 ls 명령에 필요한 권한입니다.
• 파일의 w은 내용을 변경합니다. 디렉터리의 w는 내부 항목을 추가하거나 삭제합니다. 파일 삭제는 디렉터리에 대한 변경 작업이므로 디렉터리의 쓰기 권한이 결정하며, 파일 자체의 모드는 영향을 주지 않습니다.
• 파일의 x은 프로그램을 실행합니다. 디렉터리의 x은 디렉터리를 탐색(traverse)합니다. 즉, 커널이 경로를 조회할 때 해당 디렉터리 내부의 이름을 해석할 수 있게 합니다.

탐색 권한은 사람들이 가장 의외라고 생각하는 부분입니다. 디렉터리의 x는 아무것도 실행하지 않습니다. /srv/site/index.html 파일을 열려면 /에 대한 x, /srv에 대한 x, /srv/site에 대한 x, 그리고 마지막으로 파일에 대한 r이 필요합니다. 경로상의 디렉터리 중 하나라도 x 권한이 없으면 조회는 거기서 중단됩니다. 마지막 파일이 모든 사용자에게 읽기 권한이 열려 있더라도 호출자에게는 전체 경로에 대해 Permission denied 오류가 발생합니다. namei -l /srv/site/index.html 명령을 사용하면 경로의 각 단계별 모드와 소유자를 출력하므로, 어느 지점에서 접근이 차단되는지 확인할 수 있습니다.

r 권한은 있지만 x 권한이 없는 디렉터리는 특이한 중간 상태입니다. 일반 사용자는 r 권한 덕분에 파일 목록을 볼 수는 있지만, 각 항목의 상태(stat)를 확인할 수는 없습니다. 따라서 ls -l 명령을 실행하면 크기와 모드 열이 물음표로 표시되고 각 항목마다 ls: cannot access ...: Permission denied 오류가 출력됩니다.

권한을 755로 설정하기

각 세 자리는 3비트 숫자로 구성됩니다. r는 4, w은 2, x은 1을 나타냅니다. 활성화된 비트의 값을 모두 더합니다.

• rwx는 4 + 2 + 1 = 7입니다.
• rw-은 4 + 2 = 6입니다.
• r-x는 4 + 1 = 5입니다.
• r--는 4입니다.
• ---은 0입니다.

따라서 drwxr-xr-x은 소유자 7, 그룹 5, 기타 사용자 5를 의미하여 755가 됩니다. -rw-r--r--은 6, 4, 4를 의미하여 644가 됩니다. drwxrwxr-x는 7, 7, 5를 의미하여 775가 되며, 이는 755에 그룹 쓰기 권한이 추가된 형태입니다. stat 명령을 사용하면 두 가지 형식을 동시에 출력해주므로 직접 숫자를 계산할 필요가 없습니다.

stat -c '%A %a %U %G %n' ~/permdemo ~/permdemo/inner/notes.txt

%A은 문자 형식, %a는 8진수 형식이며, %U과 %G는 각각 소유 사용자와 소유 그룹을 나타냅니다.

자주 검색되는 권한 문자열

실제 서버에서 마주하게 되는 모드와 그 8진수 값, 그리고 각 모드가 사용되는 위치는 다음과 같습니다.

• -rw-r--r--는 644입니다. 설정 파일이나 HTML 페이지와 같이 서비스가 읽기만 하는 일반 파일입니다.
• -rw-------은 600입니다. SSH 개인 키나 애플리케이션의 .env 파일과 같은 보안 정보입니다.
• -rw-rw-r--은 664입니다. 팀원이 쓰기 권한이 필요한, 그룹이 공유하는 디렉터리 내의 파일입니다.
• -rwxr-xr-x는 755입니다. /usr/local/bin/backup.sh 및 대부분의 /usr/bin과 같은 스크립트와 바이너리입니다.
• -rwx------는 700입니다. 소유자만 실행할 수 있는 개인 스크립트입니다.
• drwxr-xr-x은 755입니다. 거의 모든 시스템 디렉터리와 웹사이트의 문서 루트 디렉터리입니다.
• drwx------는 700입니다. ~/.ssh 및 보안이 강화된 서버의 홈 디렉터리입니다.
• drwxrwxr-x은 775입니다. 소유자의 그룹이 쓰기 권한을 가질 수 있는 디렉터리입니다.
• drwxrwsr-x은 2775입니다. 위와 동일하며 setgid 비트가 설정되어, 내부의 새 파일이 디렉터리의 그룹을 상속받습니다.
• drwxrwxrwt은 1777입니다. /tmp입니다. 끝의 t은 스티키 비트(sticky bit)이며, 사용자가 자신의 파일만 삭제할 수 있도록 합니다.
• -rwsr-xr-x은 4755입니다. /usr/bin/passwd 및 /usr/bin/sudo과 같이 소유자 권한으로 실행되는 setuid 바이너리입니다.
• -rw-rw-rw-는 666이며, drwxrwxrwx는 777입니다. 모든 사용자에게 쓰기 권한이 부여된 상태로, 서버에서는 거의 항상 설정 오류입니다.
• lrwxrwxrwx은 모든 심볼릭 링크에 표시되는 값입니다. Linux는 링크의 모드 비트를 무시하고 대상 파일을 확인하므로, 이 문자열은 아무런 의미가 없습니다.

어떤 권한 세트가 적용되는가

초보자가 두 번째로 자주 범하는 실수는 다음과 같습니다. 커널은 정확히 하나의 권한 세트(triad)를 선택하고 거기서 멈춥니다.

사용자 ID가 파일 소유자와 일치하면 소유자 권한 세트가 적용되며, 그룹이나 기타(other) 비트는 확인하지 않습니다. 그렇지 않고 파일의 그룹이 사용자가 속한 그룹 중 하나라면 그룹 권한 세트가 적용됩니다. 그 외의 경우에는 기타(other) 권한 세트가 적용됩니다.

여기서 두 가지 사실을 알 수 있습니다. 소유자 권한 세트는 가장 제한적인 경우에도 우선 적용됩니다. 모드 0466인 파일은 -r--rw-rw-로 출력되는데, 이 경우 소유자는 읽기만 가능하지만 다른 모든 사용자는 쓰기가 가능합니다. 소유자 확인이 가장 먼저 이루어지고 그 이후의 설정은 읽히지 않기 때문입니다. 이는 정상적인 동작이지만, 처음 접하는 사람들에게는 혼란을 줍니다.

그룹 권한 세트는 사용자가 속한 그룹 목록이 아니라 파일에 설정된 그룹에 의해 결정됩니다. ls -l은 각 줄에 소유자와 그룹이라는 두 가지 이름을 출력합니다. 오직 그 두 번째 그룹만이 해당 파일에 대한 권한을 가집니다. 사용자가 20개의 그룹에 속해 있더라도 파일이 그중 하나를 그룹으로 지정하고 있어야만 의미가 있습니다.

id
stat -c '%U %G %A %n' ~/permdemo/inner/notes.txt

id는 사용자의 계정명과 속한 모든 그룹을 출력합니다. stat은 파일의 소유자와 그룹을 출력합니다. 이 둘을 비교하면 커널이 사용자에게 어떤 권한 세트를 적용할지 알 수 있습니다.

공유 디렉터리에 보통 특정 그룹을 지정하고 setgid 비트를 설정하는 이유가 바로 이것입니다. sudo chmod 2775 /srv/shared은 drwxrwsr-x로 출력되며, 이렇게 하면 내부에 생성된 파일은 생성자의 개인 그룹이 아닌 디렉터리의 그룹을 상속받게 되어 다른 사용자가 파일을 수정할 수 있게 됩니다. 각 서비스에 별도의 계정을 부여하는 것은 이 이야기의 나머지 절반이며, 이는 VPS에서 서비스당 하나의 Linux 사용자 사용하기에서 다룹니다.

umask는 모든 새 파일의 모드를 결정합니다

새 파일의 모드는 사용자로부터 직접 결정되지 않습니다. 파일을 생성하는 프로그램이 요청한 모드에서 umask가 제거할 비트를 뺀 값이 최종 모드가 됩니다. umask는 비트를 제거하는 마스크이므로, umask 값이 클수록 더 제한적인 권한의 파일이 생성됩니다.

대부분의 배포판은 기본값으로 022를 사용합니다. 일반 파일을 생성하는 프로그램은 0666을 요청하고, 디렉터리를 생성하는 프로그램은 0777을 요청합니다. umask는 두 요청 모두에서 022를 제거하므로, 결과적으로 파일은 644, 디렉터리는 755 권한을 갖게 됩니다. 이것이 바로 새로 설치된 VPS에서 흔히 볼 수 있는 권한 설정입니다.

umask
umask -S
touch ~/permdemo/new.txt && mkdir -p ~/permdemo/newdir
ls -ld ~/permdemo/new.txt ~/permdemo/newdir

umask -S은 0022보다 읽기 쉬운 문자 형태로 값을 출력합니다. 더 엄격한 기본값을 설정하려면 ~/.profile에 umask 027를 설정하십시오. 이렇게 하면 파일은 640, 디렉터리는 750 권한이 되어, 그룹 사용자는 읽을 수 있지만 그 외의 사용자는 접근할 수 없게 됩니다.

두 가지 제한 사항을 유의해야 합니다. umask는 비트를 제거할 수만 있고 추가할 수는 없습니다. 이것이 umask를 어떻게 설정하든 새로 생성된 파일이 기본적으로 실행 권한을 갖지 않는 이유입니다. 또한 systemd 서비스는 사용자의 셸 프로파일을 읽지 않으므로, 해당 값은 unit 파일 내에 직접 설정해야 합니다.

[Service]
UMask=0027

웹 파일 권한이 644이고 웹 디렉터리 권한이 755인 이유

웹 서버는 전용 계정으로 실행됩니다. Debian과 Ubuntu에서는 www-data을 사용하고, Rocky와 Alma에서는 nginx을 사용합니다. 해당 프로세스는 서비스하는 파일을 읽을 수 있어야 하며, 파일이 위치한 상위 디렉터리를 탐색할 수 있어야 합니다. 파일을 수정할 이유는 없으며, 정적 사이트라면 이를 절대 허용해서는 안 됩니다.

파일에 644를 설정하면 소유자에게는 쓰기 권한을, 모든 사용자에게는 읽기 권한을 부여하므로 배포 사용자는 파일을 게시할 수 있고 웹 사용자는 파일을 서비스할 수 있습니다. 디렉터리에 755를 설정하면 소유자에게는 쓰기 권한을, 모든 사용자에게는 탐색 권한을 부여하므로 웹 사용자는 파일을 추가하거나 삭제할 수 없는 상태로 경로를 따라 이동할 수 있습니다. 따라서 애플리케이션에 버그가 있더라도 서비스 중인 페이지를 덮어쓸 수 없습니다.

탐색 규칙은 바로 이 지점에서 문제가 됩니다. 사이트가 /home/deploy/site에 위치하는데 /home/deploy의 권한이 750이라면, 웹 사용자는 홈 디렉터리에 전혀 진입할 수 없으며 요청은 HTTP 403 오류로 종료됩니다. 이때 /var/log/nginx/error.log에는 다음과 같은 줄이 기록됩니다.

open() "/home/deploy/site/index.html" failed (13: Permission denied), client: 203.0.113.5

여기서 13은 EACCES로, 커널이 권한을 거부했음을 의미합니다. 네트워크에는 아무런 문제가 없습니다. 포트는 정상적으로 수신 대기 중이고 요청도 도달했기 때문에, Linux에서 수신 대기 포트가 작동하는 방식을 배우는 단계에서는 이 상황이 매우 혼란스러울 수 있습니다. namei -l /home/deploy/site/index.html을 실행하여 다른 사용자에 대한 x 권한이 없는 첫 번째 디렉터리를 찾을 때까지 경로를 따라 확인하십시오.

업로드 경로와 같이 애플리케이션이 직접 쓰기를 수행해야 하는 디렉터리는 예외입니다. 이때는 권한 모드를 넓히는 대신 소유권을 변경하십시오. sudo chown -R www-data:www-data /srv/site/uploads를 사용하여 소유권을 변경하고 모드는 755로 유지합니다. 쓰기 권한이 꼭 필요한 디렉터리에만 쓰기 권한을 부여하십시오.

chmod, 전체 트리를 망가뜨리지 않고 사용하기

chmod은 두 가지 형식을 모두 지원합니다. 8진수(octal) 방식은 9개의 비트를 한 번에 설정합니다: chmod 644 notes.txt. 심볼릭(symbolic) 방식은 지정한 부분만 변경하고 나머지는 그대로 둡니다: chmod u+x deploy.sh은 소유자에게 실행 권한을 추가하며, chmod go-w notes.txt는 그룹과 기타 사용자의 쓰기 권한을 제거합니다.

재귀적(recursive) 옵션은 디렉터리 트리를 손상시킬 위험이 있습니다. chmod -R 755 .은 모든 이미지와 설정 파일을 실행 가능하게 만듭니다. chmod은 스크립트와 JPEG 파일을 구분할 수 없기 때문입니다. 대신 대문자 X를 사용하십시오.

chmod -R u=rwX,go=rX ~/permdemo
stat -c '%a %n' ~/permdemo ~/permdemo/inner/notes.txt

대문자 X은 디렉터리와 이미 실행 권한이 하나라도 있는 파일에만 실행 권한을 적용합니다. 디렉터리는 755로, 일반 파일은 644로 설정되며, 이미 실행 가능했던 스크립트는 해당 상태를 유지합니다. 신뢰할 수 있는 파일의 모드를 그대로 적용하려면 chmod --reference=good.sh other.sh를 사용하여 권한을 복사하십시오.

비트 설정이 잘못되었을 때 나타나는 메시지

bash: ./deploy.sh: Permission denied는 스크립트에 사용자에게 적용되는 삼중 권한 중 x 비트가 없거나, 경로상의 디렉터리에 x 권한이 없을 때 발생합니다. chmod u+x deploy.sh 명령으로 첫 번째 문제를 해결할 수 있습니다.

bash: ./deploy.sh: cannot execute: required file not found는 이름 때문에 혼동하기 쉬운 다른 오류입니다. x 비트는 정상이나, 첫 번째 줄에 명시된 인터프리터를 찾을 수 없는 경우입니다. 보통 Windows 줄바꿈 문자가 원인이며, 이 경우 커널은 /bin/bash\r이라는 이름의 인터프리터를 찾게 됩니다. sed -i 's/\r$//' deploy.sh 명령으로 이를 수정하십시오.

Permissions 0644 for '/home/deploy/.ssh/id_ed25519' are too open.은 다른 계정이 읽을 수 있는 개인 키 사용을 거부하는 SSH 클라이언트에서 발생합니다. 키 파일은 600 권한이 필요하며, ~/.ssh 디렉터리는 700 권한이 필요합니다. 키 관리에 대한 전체 내용은 SSH 키 관리 및 파일 권한 설정에서 확인할 수 있습니다.

Authentication refused: bad ownership or modes for directory /home/deploy/.ssh는 홈 디렉터리나 해당 .ssh 디렉터리가 그룹 쓰기 권한을 가질 때 서버 저널에 나타납니다. sshd의 StrictModes 설정이 키를 거부하며, 클라이언트 측에서는 설명 없이 갑자기 비밀번호를 묻는 것처럼 보입니다.

sudo: /etc/sudoers is world writable 뒤에 sudo: no valid sudoers sources found, quitting가 이어지는 것은 sudo가 자신의 설정 파일 모드를 확인한 후 실행을 거부했음을 의미합니다. 해당 파일은 반드시 0440 권한이어야 합니다. 이는 광범위한 재귀적 chmod 명령을 실행한 뒤 흔히 발생하는 결과이며, 위에서 언급한 sshd 메시지와 함께 나타날 수 있습니다. 이 경우 제공자의 콘솔을 통해서만 서버에 다시 접근할 수 있습니다.

777이 해결책이 아닌 이유

777 권한은 시스템의 모든 계정과 해당 계정으로 실행되는 모든 프로세스에 쓰기 권한을 부여합니다. 서버는 각 서비스마다 고유한 사용자로 실행되므로, VPS 환경에서 "모든 사용자"라는 의미는 개인용 노트북보다 훨씬 넓은 범위를 포함합니다. 서비스가 침해당하면 777로 설정된 모든 경로에 쓰기 작업이 가능해집니다.

웹 루트 디렉터리에서 이러한 설정은 직접적인 피해로 이어집니다. 서버가 서비스 중인 디렉터리에 누구나 쓰기가 가능하다면, 파일 업로드 취약점이 스크립트를 심고 이를 다시 요청하여 실행하는 경로가 될 수 있습니다.

777은 소유권 문제에 대한 해결책으로 거의 항상 잘못된 선택입니다. "애플리케이션이 이 디렉터리에 쓸 수 없습니다"라는 증상이 나타날 때, 근본 원인은 디렉터리의 소유자가 잘못 지정된 것입니다. sudo chown -R appuser:appuser /srv/app/storage 명령과 755 모드를 사용하면 다른 계정의 접근을 차단하면서 문제를 해결할 수 있습니다. 배포 전에 필요한 계정을 생성하는 작업은 새 VPS 설정의 첫 10분 과정에 포함되어야 합니다.

누구나 쓰기가 가능한 설정이 정당한 유일한 예외는 /tmp 디렉터리이며, 이때는 drwxrwxrwt 권한을 사용합니다. 끝에 붙은 t는 스티키 비트(sticky bit)를 의미합니다. 이 설정은 디렉터리에 누구나 쓸 수 있게 하되, 사용자가 자신이 소유한 파일만 삭제할 수 있도록 제한합니다. 이 비트가 없다면 어떤 계정이든 다른 계정의 임시 파일을 삭제할 수 있게 됩니다.

모드를 변경하기 전에 읽기

이 명령어들은 상태를 읽기만 하므로 어디서든 안전하게 실행할 수 있습니다.

id
umask
stat -c '%A %a %U %G %n' ~/permdemo ~/permdemo/inner/notes.txt
namei -l ~/permdemo/inner/notes.txt
find ~/permdemo -perm -0002

find <path> -perm -0002는 world write 비트가 설정된 경로 아래의 모든 항목을 나열합니다. 이는 누군가 chmod 777을 사용하여 시스템을 수리한 후 서버를 감사하는 가장 빠른 방법입니다.

특정 서비스 계정이 디렉터리에 진입할 수 있는지 확인하려면 해당 계정으로 직접 조회해야 합니다. sudo -u www-data test -x /srv/site && echo yes || echo no은 해당 사용자가 디렉터리에 대한 탐색(traverse) 권한이 있을 때 yes을 출력하고, 권한이 없을 때 no를 출력합니다. root 계정으로 조회하는 것은 아무런 의미가 없습니다. root는 권한 검사를 건너뛰기 때문에 항상 yes이라는 결과가 나오기 때문입니다.

FAQ

Linux에서 drwxr-xr-x는 무엇을 의미합니까?

맨 앞의 d로 표시된 디렉터리이며, 모드는 755입니다. 소유자 권한은 rwx이므로 소유자는 모든 권한을 가집니다. 그룹 권한은 r-x이고 기타 사용자 권한은 r-x이므로, 소유자를 제외한 다른 사용자는 디렉터리 내부 목록을 확인하고 통과할 수 있지만 내용을 추가하거나 삭제할 수는 없습니다. stat -c '%A %a %U %G %n' <path>를 사용하면 문자 형태와 8진수 형태를 나란히 출력하여 경로의 권한을 확인할 수 있습니다.

왜 웹 파일은 644이고 웹 디렉터리는 755입니까?

웹 서버는 Ubuntu에서 www-data이라는 별도의 계정으로 실행됩니다. 서버는 서비스할 파일을 읽고 상위 디렉터리를 통과할 권한이 필요하지만, 파일을 수정할 이유는 없습니다. 644는 소유자에게 쓰기 권한을 주고 다른 사용자에게는 읽기 권한을 줍니다. 755는 소유자에게 쓰기 권한을 주고 다른 사용자에게는 통과 권한을 줍니다. 애플리케이션이 반드시 써야 하는 디렉터리는 모든 사용자에게 권한을 넓히는 대신 chown을 사용하여 해당 애플리케이션 사용자로 소유권을 변경해야 합니다.

x 비트가 있으면 디렉터리를 실행할 수 있다는 뜻입니까?

아닙니다. 디렉터리에서 x은 통과(traverse)를 의미하며, 이는 커널이 경로를 따라갈 때 내부의 이름을 해석할 권한을 뜻합니다. cd를 실행하거나 하위 파일을 열 때 이 권한이 필요합니다. 경로상의 모든 디렉터리에 x이 있어야 하므로, 상위 디렉터리에 x 권한이 없으면 644 모드 파일이라도 접근할 수 없습니다. namei -l /path/to/file를 사용하면 경로상의 모든 디렉터리 모드를 출력하여 어디에서 접근이 차단되는지 확인할 수 있습니다.

chmod 777이 올바른 해결책인 경우가 있습니까?

서버에서는 거의 없습니다. 이 설정은 서비스 계정을 포함하여 시스템의 모든 계정에 쓰기 권한을 부여하므로, 서비스 하나만 침해당해도 파일을 덮어쓸 수 있습니다. 애플리케이션이 디렉터리에 쓸 수 없는 경우, 실제 문제는 소유권인 경우가 많습니다. sudo chown -R appuser:appuser /srv/app/storage을 755 모드로 설정하면 다른 사용자를 배제하면서 애플리케이션에 필요한 권한만 줄 수 있습니다. 잘 알려진 예외는 1777 모드의 /tmp인데, 이는 스티키 비트(sticky bit)가 사용자가 서로의 파일을 삭제하지 못하게 막기 때문에 가능한 것입니다.

왜 ls는 권한 뒤에 점이나 더하기 기호를 출력합니까?

열한 번째 문자는 9개의 권한 비트를 넘어서는 규칙을 설명합니다. drwxr-xr-x.와 같이 점(.)이 있으면 SELinux 보안 컨텍스트가 적용된 상태이며, 이는 Fedora나 Rocky에서 일반적입니다. drwxr-xr-x+과 같이 더하기(+)가 있으면 POSIX ACL(접근 제어 목록)이 설정된 상태이며, 세 가지 권한 그룹으로 표시되지 않는 특정 사용자나 그룹의 권한이 존재함을 의미합니다. getfacl <path>을 실행하면 이러한 추가 항목을 확인할 수 있습니다.