윈도우 폴더 속성의 Sharing 탭은 WSL2 Docker bind mount 권한과 거의 관련이 없습니다./mnt/c/docker_data/downloads:/downloads처럼 WSL에서 Windows C: 드라이브를 Docker에 마운트할 때는 주로 WSL의 /mnt/c 접근 권한, Windows ACL 권한, 컨테이너 내부 실행 UID/GID가 문제입니다.
가장 권장하는 방법은 Windows 경로 대신 WSL 리눅스 파일시스템을 쓰는 것입니다.
하지만, 다운받은 영상이나 pdf 등은 윈도우에서 자주 열어보기 때문에 윈도우 파일시스템을 활용하고자 합니다.
윈도우11 폴더에 접근권한 부여하기
윈도우11의 C:\docker_data\downloads에 저장할 것이라 이 폴더를 기준으로 설명합니다. 먼저 Windows 쪽 ACL을 열어주세요. PowerShell을 관리자 권한으로 열고:
New-Item -ItemType Directory -Force C:\docker_data\downloads
icacls C:\docker_data /grant "$env:USERNAME:(OI)(CI)F" /T그다음 WSL Ubuntu에서:
mkdir -p /mnt/c/docker_data/downloads
ls -ld /mnt/c/docker_data /mnt/c/docker_data/downloads
touch /mnt/c/docker_data/downloads/test.txttouch가 실패하면 Docker 문제가 아니라 WSL에서 Windows 폴더에 쓰기 권한이 없는 상태입니다.
wsl2에서 윈도우 폴더에 접근을 위한 설정
리눅스 파일 타입으로 접근가능하게 설정해줘야 파일 저장시 오류가 적습니다.
WSL에서 chmod/chown이 제대로 먹게 하려면 /etc/wsl.conf에 metadata 옵션을 켭니다.
sudo nano /etc/wsl.conf내용을 아래처럼 넣습니다.
[automount]
options = "metadata,umask=022,fmask=011"저장 후 Windows PowerShell에서:
wsl --shutdown다시 Ubuntu를 열고:
sudo chown -R $USER:$USER /mnt/c/docker_data
chmod -R 775 /mnt/c/docker_data그 후 Docker 재시작:
cd ~/docker_data/metube
docker compose down
docker compose up -d추가로 컨테이너가 /downloads에 어떤 사용자로 쓰는지 확인해보세요.
docker exec -it metube sh
id
ls -ld /downloads
touch /downloads/test.txt컨테이너 안에서 touch /downloads/test.txt가 실패하면 bind mount 권한 문제입니다.
현재 상황에서는 아래 순서로 처리하는 게 가장 빠릅니다.
mkdir -p /mnt/c/docker_data/downloads
touch /mnt/c/docker_data/downloads/test.txt
docker compose down
docker compose up -d
docker exec -it metube sh -c 'id && ls -ld /downloads && touch /downloads/test.txt'실패가 계속되면 compose를 아래처럼 WSL 내부 경로로 바꾸는 것이 가장 확실합니다.
무리한 시도를 중단하는 것도 현명한 방법입니다.
volumes:
- /home/ubuntu/docker_data/downloads:/downloads자투리 상식1)
위에서 사용했던 이 명령은 Windows에서 C:\docker_data 폴더에 현재 로그인한 사용자에게 전체 권한을 부여하는 PowerShell 명령입니다.
icacls C:\docker_data /grant "$env:USERNAME:(OI)(CI)F"나눠서 보면:
icaclsWindows의 파일/폴더 권한, 즉 ACL을 확인하거나 수정하는 명령입니다.
C:\docker_data권한을 바꿀 대상 폴더입니다.
/grant특정 사용자나 그룹에게 권한을 부여하겠다는 뜻입니다.
$env:USERNAME현재 Windows에 로그인한 사용자 이름입니다. 예를 들어 로그인 계정이 TaeG라면 PowerShell에서 자동으로 TaeG로 바뀝니다.
(OI)(CI)F권한 범위와 종류입니다.
| 표시 | 의미 |
|---|---|
OI |
Object Inherit: 폴더 안의 파일에도 권한 상속 |
CI |
Container Inherit: 폴더 안의 하위 폴더에도 권한 상속 |
F |
Full Control: 전체 권한 |
즉 전체 의미는:
C:\docker_data 폴더와 그 안의 모든 파일/하위 폴더에 대해
현재 Windows 사용자에게 전체 제어 권한을 부여한다실제로는 보통 이렇게 실행하는 편이 더 확실합니다.
icacls C:\docker_data /grant "$($env:USERNAME):(OI)(CI)F" /T여기서 /T는 하위 파일과 폴더까지 재귀적으로 적용한다는 뜻입니다.
확인용:
icacls C:\docker_data이 명령을 실행하면 현재 권한 목록을 볼 수 있습니다.
자투리 상식2)
/etc/wsl.conf의 아래 설정은 그 동작 방식을 바꾸는 설정입니다.
[automount]
options = "metadata,umask=022,fmask=011"WSL2에서 /mnt/c, /mnt/d 같은 Windows 드라이브는 리눅스 파일시스템이 아니라 Windows NTFS를 WSL이 DrvFs라는 방식으로 마운트한 것입니다. 그래서 기본 상태에서는 리눅스의 chmod, chown, 실행 권한, 소유자 개념이 일반 Ubuntu 파일시스템처럼 동작하지 않을 수 있습니다.
1. [automount]
이 섹션은 WSL이 Windows 드라이브를 자동으로 마운트할 때의 설정입니다.
예를 들어 Windows의 C:\는 WSL 안에서 보통 이렇게 보입니다.
/mnt/c[automount]는 /mnt/c, /mnt/d 같은 경로가 어떤 옵션으로 마운트될지 정합니다.
2. metadata
가장 중요한 옵션입니다.
metadata이 옵션을 켜면 WSL이 Windows 파일/폴더에 대해 리눅스식 메타데이터를 저장할 수 있습니다.
즉 이런 명령들이 더 리눅스답게 동작합니다.
chmod 775 /mnt/c/docker_data/downloads
chown ubuntu:ubuntu /mnt/c/docker_data/downloads
ls -l /mnt/c/docker_data/downloadsmetadata가 없으면 /mnt/c 아래 파일들은 Windows 권한을 기준으로 보이기 때문에, chmod를 해도 기대처럼 바뀌지 않거나 소유자가 이상하게 보일 수 있습니다.
metadata를 켜면 WSL이 NTFS 확장 속성에 리눅스 권한 정보를 저장합니다. 그래서 WSL 안에서는 해당 파일이 마치 리눅스 파일처럼 uid, gid, mode 정보를 가지는 것처럼 보입니다.
예를 들어:
chmod 775 /mnt/c/docker_data/downloads이 명령이 의미 있게 작동하려면 metadata가 필요합니다.
3. umask=022
umask는 새로 만드는 파일이나 폴더의 기본 권한에서 빼는 값입니다.
리눅스에서 기본 권한은 보통 다음 기준으로 계산됩니다.
파일 기본값:
666폴더 기본값:
777여기에 umask=022를 적용하면:
파일:
666 - 022 = 644즉:
rw-r--r--폴더:
777 - 022 = 755즉:
rwxr-xr-x정리하면 umask=022는 새 파일/폴더를 만들 때 기본적으로 이렇게 만들겠다는 뜻입니다.
| 종류 | 기본 권한 |
|---|---|
| 새 파일 | 644, 소유자는 읽기/쓰기, 나머지는 읽기 |
| 새 폴더 | 755, 소유자는 읽기/쓰기/실행, 나머지는 읽기/실행 |
이 설정은 보안상 무난한 기본값입니다. 다른 사용자에게 쓰기 권한은 주지 않고, 읽기/접근 정도만 허용합니다.
4. fmask=011
fmask는 파일에만 적용되는 마스크입니다.
여기서 f는 file입니다.
Windows 파일은 기본적으로 실행 가능 여부를 리눅스처럼 명확히 갖고 있지 않습니다. 그래서 WSL에서는 /mnt/c 아래 파일들이 전부 실행 가능처럼 보이는 경우가 있습니다.
예를 들어 기본 상태에서 파일이 이렇게 보일 수 있습니다.
-rwxrwxrwx file.txt하지만 txt, jpg, yml 같은 일반 파일이 전부 실행 가능으로 보이는 것은 리눅스 관점에서 부자연스럽습니다.
fmask=011은 파일 권한에서 실행 비트를 일부 제거합니다.
umask=022와 함께 쓰면 일반 파일은 보통 다음처럼 보이게 됩니다.
644즉:
-rw-r--r--실행 권한이 빠진 일반적인 파일 권한입니다.
왜 Docker bind mount에서 이게 중요할까?
현재 compose에는 이런 설정이 있습니다.
volumes:
- /mnt/c/docker_data/downloads:/downloads이 뜻은 Windows의:
C:\docker_data\downloads를 컨테이너 안의:
/downloads로 연결한다는 뜻입니다.
컨테이너 내부 앱은 /downloads에 파일을 저장하려고 합니다. 그런데 /mnt/c/docker_data/downloads의 리눅스식 권한이 이상하게 잡혀 있으면 컨테이너에서 쓰기 실패가 날 수 있습니다.
metadata를 켜면 WSL에서 다음 같은 조정이 가능해집니다.
sudo chown -R $USER:$USER /mnt/c/docker_data
chmod -R 775 /mnt/c/docker_data그러면 Docker 컨테이너가 bind mount된 폴더를 볼 때도 권한 처리가 더 예측 가능해집니다.
0 댓글