이 글의 목적은 Windows에서 Take Ownership(소유권 가져오기) 실행 후에도 “액세스가 거부됨” 또는 권한이 즉시 반영되지 않는 문제를 원인별로 진단하고, 권한 캐시 재빌드와 ACL(접근 제어 목록) 재적용까지 포함해 현장에서 재현 가능하게 해결하는 방법을 정리하는 것이다.
1. Take Ownership를 했는데 왜 바로 접근이 안 되는가
1) 소유자 변경과 권한 부여는 별개 작업이다
Take Ownership는 말 그대로 “소유자(Owner)”를 바꾸는 동작에 가깝다. 소유자가 바뀌어도 DACL(권한 목록)에 사용자 또는 Administrators에 대한 허용(Allow) 항목이 없으면 접근이 계속 막히는 구조이다. 따라서 “소유권 가져오기” 다음 단계로 “권한 부여(Full Control 부여)”가 반드시 필요하다.
2) 이미 열려 있는 프로세스는 ‘예전 권한 상태’로 계속 동작할 수 있다
파일·폴더는 누군가가 핸들을 잡고 있는 동안, 변경된 권한이 즉시 체감되지 않는 경우가 흔하다. 특히 탐색기, 백업/동기화, 백신, 인덱서, IDE, 터미널이 대상 폴더를 이미 열어둔 상태이면 변경 후에도 같은 창에서 계속 접근 실패가 발생할 수 있다. 이때는 권한이 실제로 적용되지 않은 것이 아니라, 이미 열린 핸들/세션/토큰 관점에서 재평가가 지연되는 경우가 많다.
3) UAC와 토큰 분리로 “관리자처럼 보여도” 권한이 부족할 수 있다
관리자 그룹 소속 계정이라도 일반 실행(비승격) 상태에서는 표준 사용자 토큰으로 동작하다가 특정 작업에서만 승격 토큰이 쓰이는 구조이다. Take Ownership를 실행한 창과 접근을 시도하는 앱의 권한 수준이 다르면, 한쪽에서는 변경이 되었는데 다른 쪽에서는 계속 거부처럼 보이는 상황이 발생할 수 있다.
4) 상위 폴더의 상속·명시적 거부(Deny)·특수 SID가 우선순위를 뒤집을 수 있다
NTFS 권한은 “상속(Inherited)”과 “명시(Explicit)”가 섞여 평가된다. 또한 Deny는 Allow보다 우선적으로 적용되는 경우가 많다. 예를 들어 상위 폴더에 Everyone 거부, Users 거부가 걸려 있으면 소유권을 바꿔도 접근이 막히는 상황이 유지될 수 있다.
주의 : Deny 항목을 성급하게 삭제하면 보안 정책이 무너질 수 있다. 업무 환경에서는 원인 확인 후 최소 범위로만 수정해야 하다.
2. 가장 빠른 진단 체크리스트
아래 순서대로 확인하면 “권한이 실제로 안 바뀐 것”과 “바뀌었는데 체감이 안 되는 것”을 빠르게 구분할 수 있다.
| 체크 항목 | 확인 방법 | 의미 | 다음 조치 |
|---|---|---|---|
| 소유자(Owner)가 내 계정/Administrators로 바뀌었는가 | 속성 → 보안 → 고급 → 소유자 표시 확인 | 소유권 변경 성공 여부 판단 | 아니면 takeown 재실행 또는 상위에서 강제 적용 |
| DACL에 내 계정(또는 Administrators) Full Control이 있는가 | 고급 보안 설정에서 “사용 권한 항목” 확인 | 실제 접근 권한 존재 여부 판단 | icacls로 명시적 권한 추가 |
| Deny가 걸려 있는가 | 권한 항목에서 “거부” 확인 | 허용보다 우선될 수 있음 | Deny의 범위/상속을 원인 중심으로 조정 |
| 상속이 꺼져 있는가 | “상속 사용” 상태 확인 | 상위 정책이 내려오지 않음 | 상속 켜기 또는 명시 권한을 올바르게 구성 |
| 탐색기/앱이 이미 폴더를 열고 있는가 | 다른 PC/계정에서 접근 가능 여부 비교 | 캐시/핸들/세션 이슈 가능 | 탐색기 재시작, 핸들 해제, 재부팅 |
3. 표준 해결 절차(권한 재적용까지 한 번에)
1) 대상 폴더를 사용하는 프로세스를 먼저 정리하다
대상 폴더를 사용 중인 프로그램을 모두 닫고, 동기화 클라이언트(예: OneDrive), 백업 에이전트, IDE, 미디어 플레이어 등을 종료하다. 가능하면 작업 관리자에서 탐색기(explorer.exe) 재시작을 준비하다.
2) 관리자 권한 터미널을 열다
Windows Terminal 또는 명령 프롬프트를 “관리자 권한으로 실행”하다. 권한 변경은 반드시 승격 토큰에서 수행해야 일관되게 반영되다.
3) takeown으로 소유권을 강제 부여하다
아래 예시는 폴더 전체(/R) 재귀 적용이며, 질문 없이(/D Y) 진행되다.
takeown /F "D:\TargetFolder" /R /D Y4) icacls로 관리자 또는 내 계정에 Full Control을 명시적으로 부여하다
소유권만으로는 접근이 보장되지 않으므로 DACL에 권한을 추가하다. 아래는 Administrators에 (OI)(CI)로 파일/하위폴더 상속 포함 Full Control(F)을 부여하는 예시이다.
icacls "D:\TargetFolder" /grant Administrators:(OI)(CI)F /T /C내 계정에 직접 부여하려면 아래처럼 사용자명을 바꾸어 적용하다.
icacls "D:\TargetFolder" /grant "%USERNAME%":(OI)(CI)F /T /C주의 : 공유 폴더나 서버 운영 폴더에 무분별한 Full Control을 부여하면 감사/보안 사고로 이어지다. 업무 환경에서는 필요한 계정/그룹만 최소 권한 원칙으로 부여해야 하다.
5) 권한 상속과 하위 개체 적용 옵션을 정리하다
하위 폴더/파일만 계속 거부되는 경우, 상속 불일치 또는 기존 ACL이 하위에 고정되어 있을 가능성이 높다. 가장 안전한 방식은 “정책을 표준화”하는 방향으로 접근하다.
다음 명령은 상속을 활성화하고(기본 상속 구조를 유지하는 상황에서) 추가로 부여한 권한을 하위에 재귀 적용하다.
icacls "D:\TargetFolder" /inheritance:e icacls "D:\TargetFolder" /grant Administrators:(OI)(CI)F /T /C6) ACL이 꼬였을 때는 초기화(/reset)로 정리하다
권한 항목이 과도하게 누적되었거나, 원인 파악이 어려운 Deny/특수 SID가 얽혀 있으면 일괄 정리 후 재부여가 더 빠르다. 다만 /reset은 “기본 상속 기반”으로 돌아가므로, 상위 폴더의 권한 설계가 정상이라는 전제에서만 사용해야 하다.
icacls "D:\TargetFolder" /reset /T /C초기화 후 반드시 필요한 그룹에 다시 권한을 부여하다.
icacls "D:\TargetFolder" /grant Administrators:(OI)(CI)F /T /C4. “권한 적용 안됨”처럼 보일 때 하는 캐시 재빌드(체감 문제 해결)
1) 탐색기 권한 체감 문제는 탐색기 재시작으로 정리되는 경우가 많다
가장 먼저 탐색기 재시작을 수행하다. 작업 관리자에서 “Windows 탐색기”를 다시 시작하면, 열려 있던 폴더 핸들이 정리되며 새 권한으로 재평가되다.
taskkill /f /im explorer.exe start explorer.exe2) 재부팅이 필요한 케이스를 구분하다
다음 조건 중 하나라도 해당하면 재부팅이 더 빠르고 확실하다.
| 조건 | 설명 | 권장 조치 |
|---|---|---|
| 대상 폴더가 시스템 구성요소/서비스가 점유 중이다 | 서비스 계정이 파일 핸들을 유지할 수 있다 | 관련 서비스 중지 후 재시도 또는 재부팅하다 |
| 보안 제품이 실시간 감시 중이다 | 차단/격리로 인해 권한과 무관하게 실패할 수 있다 | 일시 예외 처리 후 재적용하다 |
| 권한 변경 직후에도 동일 창에서만 계속 실패하다 | 핸들/세션이 갱신되지 않은 상태일 수 있다 | 탐색기 재시작 후에도 안 되면 재부팅하다 |
3) 토큰/세션 관점의 ‘권한 캐시’ 문제를 정리하다
권한을 부여한 뒤에도 특정 앱에서만 계속 접근 거부가 나면, 해당 앱이 비승격으로 실행 중이거나(표준 토큰), 오래 열린 세션을 유지하는 상황일 수 있다. 이때는 앱을 완전히 종료하고 “관리자 권한으로 다시 실행”하거나, 로그아웃 후 재로그인으로 세션을 새로 만들면 해결되다.
4) 네트워크 공유 경로라면 로컬 NTFS가 아니라 공유 권한/세션이 원인일 수 있다
대상이 \\server\share 형태의 SMB 공유이면, 로컬에서 Take Ownership를 해도 클라이언트가 보는 권한은 공유 권한(Share Permission)과 NTFS 권한의 교집합으로 결정되다. 또한 기존 인증 세션이 남아 있으면 변경이 늦게 체감되다. 이 경우는 공유 권한과 NTFS 권한을 함께 점검하고, 필요하면 네트워크 세션을 끊고 다시 연결하다.
5. 자주 놓치는 원인별 심화 해결
1) TrustedInstaller 소유 폴더(Windows, Program Files 등)를 건드린 경우이다
시스템 폴더는 업데이트/보호 메커니즘과 얽혀 있다. 소유권을 바꾸면 당장은 수정이 가능해도, 이후 업데이트 실패나 무결성 문제를 유발할 수 있다. 가능한 한 시스템 폴더는 원복하는 방향이 안전하다.
2) EFS/BitLocker/권한과 무관한 암호화 이슈이다
폴더 접근 거부처럼 보여도 실제로는 파일이 사용자 인증서 기반으로 암호화(EFS)되어 있거나, 드라이브 잠금(BitLocker) 상태가 불완전하면 접근이 실패하다. 이 경우 Take Ownership로는 해결되지 않으며, 암호화 키/잠금 상태를 먼저 해결해야 하다.
3) Controlled Folder Access 같은 보안 기능이 차단하는 상황이다
Windows 보안의 랜섬웨어 방지(제어된 폴더 액세스)가 켜져 있으면 권한을 줘도 앱 쓰기가 막힐 수 있다. 이때는 차단 기록을 확인하고 앱 허용 목록을 조정해야 하다.
4) 상속이 꺼진 채 하위에 엉킨 ACL이 남아 있는 상황이다
가장 흔한 패턴은 “상속 사용 안 함” + “하위에 이전 권한이 고정” 조합이다. 이때는 상속을 켜고, 하위 개체에 다시 전파되도록 구조를 정리해야 하다. GUI에서 해결이 꼬이면 icacls로 표준화하는 것이 빠르다.
6. 현장용 원클릭 절차(안전형 템플릿)
아래 템플릿은 “소유권 가져오기 + 관리자 Full Control 부여 + 하위 적용 + 오류 무시(/C)”까지 포함한 기본형이다. 경로만 바꾸고 관리자 권한 터미널에서 실행하다.
set "T=D:\TargetFolder"
takeown /F "%T%" /R /D Y
icacls "%T%" /inheritance:e
icacls "%T%" /grant Administrators:(OI)(CI)F /T /C
taskkill /f /im explorer.exe
start explorer.exe주의 : 위 템플릿은 관리 편의성을 위해 Administrators에 Full Control을 부여하다. 운영 서버나 공용 파일서버에서는 조직 표준 그룹으로 치환하고, 필요한 최소 범위로만 적용해야 하다.
FAQ
소유권을 가져왔는데도 “액세스가 거부됨”이 계속 뜨는 이유는 무엇인가?
소유권 변경은 권한 부여와 별개이기 때문이다. DACL에 사용자 또는 Administrators에 대한 허용 권한이 없거나, Deny가 우선 적용되면 접근이 계속 거부되다. icacls로 명시 권한을 추가하고 Deny/상속 상태를 함께 점검해야 하다.
같은 폴더인데 어떤 파일만 접근이 안 되는 이유는 무엇인가?
하위 파일에 상속이 끊겨 있거나, 특정 파일에만 별도 Deny/특수 SID가 붙어 있을 가능성이 높다. 상속을 정리하고 /T 재귀 적용으로 권한을 표준화해야 하다.
탐색기에서만 계속 접근이 안 되고, 터미널에서는 되는 경우는 무엇을 의심해야 하는가?
탐색기가 오래 열린 핸들을 유지하는 체감 문제일 수 있다. explorer.exe를 재시작하거나 로그아웃/재로그인을 수행하면 새 권한으로 재평가되다.
네트워크 공유 폴더에서 Take Ownership를 했는데 클라이언트에서 여전히 접근이 안 된다
공유 권한과 NTFS 권한의 교집합이 최종 권한이기 때문이다. 공유 권한 설정과 기존 인증 세션까지 함께 점검하고 필요하면 세션을 끊고 다시 연결해야 하다.