이 글의 목적은 Windows에서 Take Ownership(소유권 가져오기) 또는 takeown/icacls로 소유자와 권한을 바꿨는데도 “접근이 거부되었습니다”가 계속 발생하는 상황을 원인별로 분해하고, 현장에서 바로 따라 할 수 있는 “권한 재적용 + 토큰/세션 재빌드” 절차를 제공하는 것이다.
1. “소유권 변경”과 “권한 부여”는 서로 다른 작업이다
가장 흔한 오해는 “내가 소유자가 되었으니 이제 접근이 된다”라는 생각이다. NTFS에서 소유권(Owner)은 DACL(권한 목록)을 바꾸는 권한(WRITE_DAC)을 갖게 해주는 성격이 강하며, 자동으로 파일 읽기/쓰기 권한이 생기는 구조가 아니다. 즉, 소유권을 가져온 다음에 명시적으로 Administrators 또는 본인 계정에 권한(예: Full Control)을 부여해야 정상 접근이 되는 경우가 많다.
주의 : Windows 시스템 폴더(예: C:\Windows, C:\Program Files, C:\Program Files\WindowsApps 등)에 무분별하게 takeown/icacls를 적용하면 업데이트, 스토어 앱, 시스템 복구가 망가질 수 있다. 반드시 “문제가 되는 특정 폴더/파일” 범위로 제한하고, 변경 전 ACL 백업을 남기는 것이 안전하다.
2. 권한이 “적용 안 된 것처럼 보이는” 대표 원인 10가지
2-1. 이미 열린 핸들(Explorer/프로세스)이 오래된 권한 상태로 접근을 지속하는 경우
권한을 바꿔도, 해당 경로를 이미 열어둔 프로세스가 계속 접근을 시도하면 체감상 “안 바뀐 것처럼” 보일 수 있다. 특히 탐색기, 백업/동기화 클라이언트, 보안 소프트웨어가 파일을 붙잡는 경우가 잦다.
2-2. UAC 분리 토큰(표준 토큰)으로 접근 중인 경우
관리자 계정이라도 기본 탐색기/프로세스는 표준 토큰으로 동작하는 경우가 있다. “관리자 권한 CMD/PowerShell”에서 권한을 바꿨는데, 일반 탐색기에서 여전히 접근이 막히면 토큰 이슈를 의심해야 한다.
2-3. DACL에 “거부(Deny)” ACE가 존재하는 경우
NTFS 권한은 거부 항목이 허용보다 우선하는 규칙이 있다. Administrators에 Full Control을 줘도, Users 또는 특정 SID에 Deny가 걸려 있으면 접근이 계속 실패할 수 있다.
2-4. 상속이 끊겨 있거나(보호됨) 부모 상속이 의도대로 내려오지 않는 경우
폴더가 “상속 사용 안 함” 상태이면 부모에서 준 권한이 내려오지 않는다. 또는 파일/하위폴더마다 상속 상태가 제각각이라면 일부만 바뀐 것처럼 보인다.
2-5. 소유권만 바뀌고, 실제 권한(READ/WRITE/EXECUTE)이 부여되지 않은 경우
소유권 변경 직후 icacls로 권한을 주지 않으면, 여전히 목록/읽기조차 안 되는 케이스가 발생한다.
2-6. 네트워크 공유(UNC)라서 “공유 권한 + NTFS 권한”이 함께 작동하는 경우
공유 폴더는 공유 권한과 NTFS 권한이 모두 영향을 준다. 로컬에서 권한을 바꿔도 접속 경로가 네트워크라면 공유 권한이 막는 상황이 생긴다.
2-7. EFS(파일 암호화) 또는 다른 암호화/보호 기술이 적용된 경우
권한을 갖더라도 암호화 키가 없으면 열지 못한다. “권한 문제로 보이지만 실은 암호화 문제”인 경우가 있어 구분이 필요하다.
2-8. 대상이 Reparse Point(심볼릭 링크/정션)라서 다른 위치의 ACL을 보고 있는 경우
겉으로는 A 폴더를 바꾸는 것처럼 보이지만 실제 파일은 B 위치라 ACL 변경이 엉뚱한 곳에 적용될 수 있다.
2-9. WindowsApps/TrustedInstaller 보호 영역이라 추가 보호가 있는 경우
스토어 앱 경로는 일반적인 방식으로 소유권/권한을 바꾸면 운영 체제가 깨지는 경우가 많고, 일부 파일은 보안 정책과 결합되어 접근이 계속 제한될 수 있다.
2-10. 권한 변경은 됐는데, 내 로그인 세션의 그룹/권한 정보가 갱신되지 않은 경우
특히 AD 그룹 변경, 로컬 그룹 변경, 권한 정책 변경 이후에는 로그오프/로그온 또는 재부팅이 필요할 수 있다.
3. 진단 체크리스트: “무엇이 막는지” 먼저 확인한다
| 체크 항목 | 확인 방법 | 의미 | 다음 조치 |
|---|---|---|---|
| 소유자(Owner) 확인 | 파일/폴더 속성 → 보안 → 고급 | Owner가 바뀌었는지 확인 | Owner가 그대로면 takeown 재시도 |
| 명시적 Deny 존재 | 고급 보안 설정에서 권한 항목 확인 | Deny가 있으면 Full Control도 무력화될 수 있음 | Deny 제거 또는 정확한 대상 SID 정리 |
| 상속(Inheritance) 상태 | 고급 보안 설정 → 상속 사용 여부 | 부모 권한이 내려오는지 판단 | 상속 켜기 또는 재정렬/재부여 |
| 내 토큰에 관리자 그룹 포함 여부 | 관리자 CMD: whoami /groups | Administrators가 “Enabled”인지 확인 | 관리자 콘솔 사용 또는 로그오프/로그온 |
| 핸들 잠금(열려 있는 프로세스) | 탐색기 종료/재시작, 잠금 유틸 또는 Sysinternals로 확인 | 권한 변경 후에도 프로세스가 파일을 붙잡을 수 있음 | 해당 프로세스 종료 후 재시도 |
| 공유 경로 여부 | 경로가 \\서버\공유 형태인지 확인 | 공유 권한이 별도로 작동 | 공유 권한도 함께 점검 |
| EFS/암호화 여부 | 속성 → 고급 → 암호화 표시 확인 | 키 없으면 권한으로 해결 불가 | 복호화/키 복구 절차 필요 |
4. 실전 해결 절차: “권한 재적용 + 캐시·토큰 재빌드” 순서대로 진행한다
4-1. 0단계: 변경 전 ACL 백업을 남긴다
권한을 건드리면 되돌리기 어렵다. 대상 폴더에 대해 ACL을 파일로 백업해두면 최소한 원복 시도가 가능하다.
icacls "D:\대상폴더" /save "D:\acl_backup.txt" /t /c4-2. 1단계: 관리자 권한 콘솔을 확실히 연다
시작 메뉴에서 Windows Terminal(관리자) 또는 CMD(관리자)로 실행해야 한다. 일반 콘솔에서 실행하면 소유권/권한 변경이 중간에 실패하는 경우가 많다.
4-3. 2단계: 소유권을 가져온다(폴더+하위 전체)
takeown /f "D:\대상폴더" /r /d y이 단계는 “변경 권한을 만들기 위한 준비”에 가깝다. 이 단계만으로 접근이 풀리지 않아도 정상이다.
4-4. 3단계: Administrators에 Full Control을 명시적으로 부여한다
소유권을 가져온 뒤, 권한을 실제로 부여해야 한다.
icacls "D:\대상폴더" /grant Administrators:(OI)(CI)F /t /c(OI)(CI)는 하위 파일/폴더로 상속을 의미한다. 특정 사용자 계정에 직접 주고 싶으면 Administrators 대신 계정명을 넣으면 된다.
4-5. 4단계: “망가진 상속/혼합 권한”을 정리한다(상황별 선택)
4-5-1. 상속을 정상화하고 싶을 때
하위 객체까지 상속을 켜고 부모 기준으로 정리하는 방향이다. 이미 복잡하게 꼬였을 때 효과가 크다.
icacls "D:\대상폴더" /inheritance:e /t /c4-5-2. 권한이 뒤죽박죽이라 “기본값으로 재설정”하고 싶을 때
이 옵션은 해당 폴더 이하 권한을 재설정한다. 업무 데이터 폴더에서 “부모 상속 기반으로 재구성”하려는 목적에 적합하다. 시스템 폴더에는 적용하지 않는 것이 안전하다.
icacls "D:\대상폴더" /reset /t /c /l/l은 링크 자체에 적용한다. 링크를 따라가며 실제 대상까지 바꾸는 것을 피하고 싶을 때 사용한다.
주의 : /reset은 “현재 폴더의 상속 상태”와 “부모 ACL”에 크게 의존한다. 부모가 이미 이상하면 /reset으로 더 악화될 수 있다. 적용 전 icacls /save 백업이 필수이다.
5. 권한이 적용됐는데도 계속 접근 거부일 때: 캐시·토큰 재빌드(핵심)
실제 ACL이 정상인데도 “내 세션”이 이전 상태를 들고 있어 접근이 막히는 체감이 생길 수 있다. 이때는 아래 순서로 “세션/토큰/프로세스”를 재시작하는 것이 확실하다.
5-1. 탐색기(Explorer) 재시작으로 UI/핸들 캐시를 끊는다
taskkill /f /im explorer.exe start explorer.exe탐색기가 해당 폴더를 열어두고 있거나, 보안 탭 정보가 갱신되지 않는 것처럼 보일 때 1차로 효과가 있다.
5-2. 관리자 권한 토큰으로 다시 접근 테스트한다
일반 탐색기에서 실패하면, 관리자 PowerShell에서 디렉터리 조회를 먼저 시도한다.
powershell -NoProfile -Command "Get-ChildItem -LiteralPath 'D:\대상폴더' -Force | Select-Object -First 5"관리자 콘솔에서는 되는데 탐색기에서는 안 되면 UAC/토큰/프로세스 문제 가능성이 높다.
5-3. 로그오프/로그온으로 토큰을 완전히 재발급한다
권한 관련 체감 문제를 가장 확실히 정리하는 방법은 로그오프/로그온이다. 특히 그룹 변경, 권한 정책 변경, 소유권/ACL 대량 변경 이후에는 이 단계가 유효하다.
5-4. (네트워크 공유일 때) 세션을 끊고 재연결한다
공유 폴더에서 권한이 바뀐 직후 접근 문제가 지속되면 기존 SMB 세션이 남아 있을 수 있다.
net use net use \\서버\공유 /delete필요 시 자격 증명도 다시 입력하여 재연결한다.
5-5. (도메인 환경) 정책/그룹 변경 반영을 강제한다
gpupdate /force단, 그룹 멤버십 자체의 반영은 보통 로그오프/로그온이 필요하다.
6. “그래도 안 된다”일 때의 고급 원인별 처방
6-1. Deny가 원인일 때
고급 보안 설정에서 Deny 항목을 찾아 제거하거나, 최소한 문제 계정/그룹에 걸린 Deny를 정리해야 한다. Deny를 섣불리 전체 제거하면 보안이 약화될 수 있으니 “문제를 일으키는 대상에 한정”하는 것이 안전하다.
6-2. 파일이 잠겨 있을 때
백업/동기화/안티바이러스/인덱싱 서비스 등이 파일을 붙잡으면, 권한이 있어도 삭제/변경이 실패하는 경우가 있다. 이때는 해당 프로세스를 종료하거나 안전 모드에서 작업하는 방식이 현실적이다.
6-3. WindowsApps/TrustedInstaller 영역일 때
스토어 앱 경로는 시스템 무결성과 연결되어 있어 권한을 임의로 바꾸면 앱 실행/업데이트가 깨질 수 있다. 꼭 필요한 경우가 아니라면 권한 변경이 아닌 “앱 재설치/복구” 또는 “정식 경로(설정 앱)에서 제거”로 해결하는 것이 안정적이다.
6-4. 권한 자체가 전반적으로 망가진 상태일 때(최후 수단)
특정 폴더가 아니라 시스템 전반의 보안 설정이 꼬인 경우에는 보안 템플릿 기반으로 기본 보안 설정을 재적용하는 방법이 거론된다. 이 방식은 시스템에 광범위하게 영향을 줄 수 있으므로, 서버/업무 PC에서는 변경관리와 백업(또는 스냅샷) 이후 진행하는 것이 안전하다.
secedit /configure /cfg %windir%\inf\defltbase.inf /db defltbase.sdb /verbose주의 : 위 명령은 시스템 보안 설정을 폭넓게 재구성할 수 있다. 특정 폴더 문제 해결 목적이라면 먼저 takeown/icacls 범위 조정, 탐색기 재시작, 로그오프/로그온, 공유 세션 재연결 등 “국소 처방”을 모두 수행한 뒤에만 고려하는 것이 안전하다.
7. 권장 “원클릭에 가까운” 작업 시나리오(현장용)
7-1. 로컬 데이터 폴더(업무 폴더)에서 Take Ownership 후 접근 불가
icacls "D:\대상폴더" /save "D:\acl_backup.txt" /t /c takeown /f "D:\대상폴더" /r /d y icacls "D:\대상폴더" /grant Administrators:(OI)(CI)F /t /c taskkill /f /im explorer.exe start explorer.exe7-2. 상속이 꼬여서 하위 일부만 계속 접근 불가
icacls "D:\대상폴더" /save "D:\acl_backup.txt" /t /c takeown /f "D:\대상폴더" /r /d y icacls "D:\대상폴더" /grant Administrators:(OI)(CI)F /t /c icacls "D:\대상폴더" /inheritance:e /t /c taskkill /f /im explorer.exe start explorer.exe7-3. 네트워크 공유에서 권한 변경 후에도 계속 거부
net use net use \\서버\공유 /delete gpupdate /force그 후 로그오프/로그온을 수행하고 다시 접속하면, 세션/토큰이 새로 잡히며 개선되는 경우가 많다.
8. 재발 방지 체크리스트
| 재발 원인 | 예방 방법 | 비고 |
|---|---|---|
| 무분별한 권한 일괄 변경 | 대상 범위를 최소화하고 변경 전 icacls /save를 수행한다 | 원복 가능성 확보가 핵심이다 |
| 상속 구조 미정리 | 부모-자식 권한 설계를 먼저 확정한 뒤 적용한다 | 상속 끊김은 장기적으로 장애를 만든다 |
| Deny 남용 | Deny는 최소화하고 필요 시 정확한 SID/그룹에만 제한한다 | 문제 추적이 매우 어려워진다 |
| 권한 변경 후 세션 유지 | 대량 변경 후에는 탐색기 재시작 또는 로그오프/로그온을 표준 절차로 둔다 | 체감 문제를 줄이는 운영 팁이다 |
FAQ
Take Ownership를 했는데 왜 바로 접근이 안 되는가?
소유권은 권한 부여 자체가 아니라 권한을 바꿀 수 있는 지위를 제공하는 성격이 강하다. 따라서 takeown으로 소유자를 바꾼 뒤 icacls /grant로 읽기/쓰기/전체 제어 권한을 명시적으로 부여해야 정상 접근이 되는 경우가 많다.
탐색기에서만 접근이 안 되고 관리자 CMD에서는 되는 이유가 무엇인가?
탐색기는 표준 토큰으로 동작하거나, 기존에 열어 둔 핸들/캐시 영향으로 체감상 권한이 갱신되지 않은 것처럼 보일 수 있다. 이때 탐색기 재시작 또는 로그오프/로그온으로 토큰을 재발급하면 해결되는 경우가 많다.
icacls /reset을 쓰면 모든 게 해결되는가?
반드시 그렇지 않다. /reset은 상속 구조와 부모 ACL 상태에 의존하며, 부모가 이미 비정상이라면 더 악화될 수 있다. 업무 폴더에서 적용 전 ACL 백업을 남기고, 범위를 최소화하여 적용하는 것이 안전하다.
WindowsApps 폴더 권한을 바꿔도 계속 접근 거부가 나는 이유는 무엇인가?
해당 영역은 운영 체제 무결성과 앱 배포 구조와 결합된 보호 영역이라, 일반 데이터 폴더처럼 권한만 바꿔서 해결되지 않거나 부작용이 발생할 수 있다. 가능하면 앱 복구/재설치 또는 정상 제거 절차를 우선하는 것이 안정적이다.
권한 변경 후 가장 확실한 “캐시 재빌드” 방법은 무엇인가?
1) 탐색기 재시작으로 UI/프로세스 캐시를 끊고, 2) 그래도 문제가 있으면 로그오프/로그온으로 토큰을 재발급하는 것이 가장 확실하다. 네트워크 공유라면 SMB 세션을 삭제 후 재연결하는 절차를 추가하는 것이 유효하다.