Docker·CI Git dubious ownership 해결: UID·마운트·safe.directory 점검

Docker나 CI에서 detected dubious ownership in repository가 나오면 Git 실행 사용자와 저장소의 실제 소유자를 먼저 비교하세요. UID·GID와 마운트 설계를 맞추는 것이 우선이며, 의도적으로 공유하는 신뢰된 저장소만 정확한 경로의 safe.directory 예외로 검토합니다. 모든 저장소를 신뢰하는 와일드카드 설정은 사용하지 않습니다. 이 글은 Git 소유권 검사이며 Docker 소켓 권한이나 파일 쓰기 권한 오류와는 별도입니다.

원인: 쓰기 권한과 저장소 소유권 검사는 다르다

호스트의 저장소를 컨테이너에 bind mount하면 컨테이너가 보는 경로와 실행 사용자가 호스트 작업 환경과 다를 수 있습니다. 파일을 읽거나 쓸 수 있어도 Git이 다른 소유자의 저장소를 신뢰하는지는 별개입니다. Git은 안전하지 않은 저장소의 설정과 훅 실행을 경계하기 때문에 단순히 chmod로 쓰기 권한을 넓혀도 올바른 해결이 아닐 수 있습니다. Git safe.directory 문서를 기준으로 신뢰 판단과 접근 권한을 나눕니다.

확인 대상	무엇을 보는가	잘못 연결하기 쉬운 결론
Git 실행 사용자	실제 id·HOME·Git 버전	호스트 로그인 사용자와 같다고 가정
저장소 소유자	컨테이너에서 보이는 UID·GID	파일을 읽을 수 있으니 안전하다고 판단
마운트 경로	호스트 source와 컨테이너 destination	호스트 경로를 컨테이너 예외에 입력
safe.directory	현재 Git 프로세스가 읽는 보호된 설정	저장소 local 설정만 바꾸기
예외 범위	검증한 저장소의 정확한 경로	모든 저장소를 무조건 신뢰

1. 실패한 것과 같은 환경에서 읽기 진단을 한다

개발자 터미널 대신 실패한 컨테이너나 러너의 동일 사용자로 확인합니다. 다음 예시의 /workspace/app은 실제 마운트 목적지로 바꿔야 합니다. id, 경로, Git 버전과 설정 출처에는 운영 정보가 있을 수 있으므로 전체 로그를 공개하지 않습니다. 저장소가 아직 신뢰되지 않으면 Git의 일부 저장소 명령이 거절될 수 있으므로 먼저 운영체제에서 경로와 소유자를 읽습니다.

# Linux 컨테이너 내부에서 읽기만 하는 예시
id
git --version
pwd -P
ls -ldn /workspace/app /workspace/app/.git
git config --show-origin --show-scope --get-all safe.directory

safe.directory가 없으면 조회 명령이 값 없이 종료될 수 있으며 이를 파일 손상으로 단정하지 않습니다. .git이 디렉터리가 아니라 worktree를 가리키는 파일일 수도 있으므로 실제 구조를 확인하세요. macOS·Windows 호스트, user namespace 또는 rootless 환경에서는 UID 해석이 단순한 호스트 숫자 비교와 다를 수 있습니다. 이 글의 Linux 예시를 모든 환경의 정답으로 복사하지 않습니다.

2. 소유권 불일치가 불필요하다면 실행 사용자 설계를 맞춘다

이미지의 USER, 런타임의 user 설정, CI 체크아웃 사용자와 마운트 목적지를 대조합니다. 실행 사용자만 바꿔도 홈 디렉터리·캐시·출력 파일 권한이 달라질 수 있으므로 새 러너나 비운영 컨테이너에서 먼저 검증합니다. Dockerfile의 USER가 적용하는 실행 단위는 공식 USER 설명을 확인하세요. root로 계속 실행하는 것을 해결 기준으로 삼지 않습니다.

bind mount의 원본은 호스트 파일과 연결됩니다. 컨테이너 안에서 재귀 chown을 실행하면 호스트 작업 폴더에 영향을 줄 수 있으므로 소유자를 한꺼번에 바꾸지 마세요. Docker bind mount 문서로 source·destination과 읽기/쓰기 범위를 확인합니다. 원본 작업과 미커밋 내용을 보존하고, 영향 범위를 확인한 변경 계획으로 사용자·마운트 구성을 조정하는 편이 재발 원인을 줄입니다.

3. 의도된 공유 저장소만 정확한 경로로 예외를 둔다

다른 소유자가 맞고 저장소 내용·설정·훅을 신뢰할 근거가 있는 경우에만 예외를 검토합니다. 다음은 현재 Git 실행 사용자의 global 설정에 한 경로를 추가하는 예시입니다. 저장소 local 설정은 이 보호된 신뢰 예외를 스스로 승인하는 위치가 아닙니다. 실행 사용자의 HOME이 달라지면 읽는 global 파일도 달라질 수 있습니다.

# 저장소 소유자·내용을 검토해 의도된 공유가 확인된 뒤에만
git config --global --add safe.directory /workspace/app

# 같은 실행 사용자로 실제 반영과 저장소 접근 확인
git config --show-origin --show-scope --get-all safe.directory
git -C /workspace/app status --short

예외는 소유권·일반 파일 권한을 바꾸지 않습니다. 다른 사용자 저장소의 설정·훅을 신뢰하게 되는 의미가 있으므로 경고만 사라졌다고 승인 없이 공용 러너 전체에 적용하지 않습니다. 와일드카드나 상위 폴더 전체 예외 대신 정확한 저장소 하나로 좁히고 적용 이유와 담당자를 기록하세요. 알 수 없는 저장소는 Git의 신뢰 관련 안내처럼 별도 검토해야 합니다.

확인 방법과 되돌리기: 새 컨테이너에서도 같은 사용자로 확인한다

같은 사용자·HOME·마운트 경로로 Git 상태를 읽고, 새 컨테이너나 다음 CI 실행에서도 필요한 설정이 재현되는지 확인합니다. 지금 열린 셸에서만 예외를 넣고 이미지를 다시 만들면 사라지는 경우를 구분하세요. 오류가 권한 거절로 바뀌면 파일 접근 문제를 따로 진단하며 예외 범위를 더 넓히지 않습니다. 작업 결과물의 소유자와 캐시 쓰기도 함께 확인합니다.

되돌릴 때는 변경 전 global 설정을 보존한 기록과 비교해 이번에 추가한 해당 값만 제거합니다. 다른 경로의 예외나 공유 시스템 설정을 함께 지우지 마세요. Git 버전마다 명령 구문이 다를 수 있으므로 설치된 git help config의 값 일치·해제 옵션을 확인합니다. 소유권 설계를 바로잡았다고 기존 예외 목록 전체를 자동 삭제하는 방식도 피합니다.

FAQ

chmod 777이면 해결되나요? 소유권 신뢰 검사와 쓰기 권한은 다릅니다. 권한을 넓혀 오류를 숨기지 않습니다.

호스트 경로를 safe.directory에 넣으면 되나요? Git이 실행되는 컨테이너에서 인식하는 실제 저장소 경로와 설정 사용자를 확인해야 합니다.

CI마다 예외를 추가해도 괜찮나요? 의도된 공유와 신뢰 근거가 있는 정확한 경로에 한해 검토합니다. 사용자 설계나 체크아웃·마운트 원인을 먼저 바로잡는 것이 우선입니다.

공식 출처와 관련 글

공식 자료 확인일은 2026년 10월 15일입니다. 설정·명령 예시는 문서로 확인했으며 AWS 계정이나 운영 서버에서 직접 실행한 결과가 아닙니다. 실제 적용 전 설치 버전·권한·대상 환경을 확인하세요. 가격과 기능은 확인일 기준으로 설명합니다.

Git config: safe.directory·보호된 설정·조회와 해제

Docker: bind mount의 호스트 경로와 컨테이너 경로

Dockerfile: USER와 실제 UID·GID

Git: 신뢰할 수 없는 저장소의 설정과 실행 주의

관련 문제를 함께 확인하려면 GitHub Actions와 GitLab CI의 러너·권한 선택 글을 참고하세요.

직접 생성한 개념 이미지입니다. 실제 사용자나 저장소 화면이 아니며 파일 권한과 Git의 저장소 신뢰 검사를 구분합니다.