이 글의 목적은 Windows 서버 환경에서 발생하는 DFS 네임스페이스 접근 거부 오류를 체계적으로 진단하고 근본 원인을 제거하는 실무 중심 해결 방법을 정리하여, 도메인 파일 서버를 안정적으로 운영할 수 있도록 돕는 것이다.
1. DFS 네임스페이스 접근 거부 오류 증상 정리
DFS 네임스페이스 접근 거부 문제는 단순 공유 폴더 권한 문제처럼 보이지만, 실제로는 도메인 컨트롤러, DFS 네임스페이스 서비스, Active Directory 메타데이터, 오프라인 파일 캐시, 인증 정책 등 여러 계층이 얽혀 있는 경우가 많다.
현장에서 주로 보고되는 대표적인 메시지는 다음과 같다.
| 오류 유형 | 대표 메시지 | 발생 위치 |
|---|---|---|
| DFS 네임스페이스 자체 접근 불가 | Windows에서 \\domain.local\DFSRoot 에 액세스할 수 없다. 구성 정보를 도메인 컨트롤러에서 읽을 수 없거나 액세스가 거부되었다. | 클라이언트 탐색기 또는 드라이브 매핑 |
| DFS 관리 콘솔에서 오류 | 네임스페이스를 쿼리할 수 없다. 액세스가 거부되었다. Properties cannot be set on the namespace server. Access is denied. | DFS 관리 콘솔(DFS Management) |
| 폴더 대상 접근 거부 | 이 네트워크 리소스를 사용할 권한이 없을 수 있다. 액세스가 거부되었다. | 특정 DFS 폴더 또는 하위 경로 |
| 간헐적 접근 불가 | 간헐적으로 “Windows에서 \\domain.local\DFSRoot 에 액세스할 수 없다” 메시지 발생 | 일부 클라이언트 또는 특정 지점 |
이러한 증상은 크게 다음 네 가지 범주로 나누어 분석하는 것이 실무에서 효율적이다.
- 클라이언트 측 네트워크·캐시·오프라인 파일 문제
- DFS 네임스페이스 서버 및 서비스 상태 문제
- Active Directory DFS-Configuration 권한 및 메타데이터 손상 문제
- 인증 정책(Protected Users, NTLM 제한 등) 및 보안 설정 문제
2. DFS 네임스페이스 구조와 권한 개요
정확한 진단을 위해서는 DFS 네임스페이스가 어떤 구성 요소로 동작하는지 이해해야 한다.
2.1 DFS 네임스페이스 종류
- 도메인 기반 DFS 네임스페이스이다.
- 경로 형태:
\\domain.local\DFSRoot형태이다. - 네임스페이스 구성 정보는 Active Directory 의
CN=Dfs-Configuration컨테이너에 저장된다. - 여러 네임스페이스 서버에 분산 구성하여 고가용성을 확보한다.
- 경로 형태:
- 독립형(standalone) DFS 네임스페이스이다.
- 경로 형태:
\\FileServer\DFSRoot형태이다. - 구성은 서버 로컬 레지스트리에 저장되며 AD 의존성이 없다.
- 경로 형태:
대부분 기업 환경에서는 도메인 기반 DFS 네임스페이스를 사용하기 때문에, 접근 거부 문제도 AD·도메인 컨트롤러·DFS-Configuration 권한과 연계되는 경우가 많다.
2.2 DFS 접근 흐름 요약
클라이언트가 \\domain.local\DFSRoot\Share 로 접근할 때 일반적인 흐름은 다음과 같다.
- DNS로 도메인 이름을 조회하여 도메인 컨트롤러 목록을 확인한다.
- DFS 네임스페이스에 대한 참조(referral)를 받기 위해 도메인 컨트롤러 또는 네임스페이스 서버와 통신한다.
- DFS 네임스페이스 서버에서 적절한 파일 서버(폴더 대상)에 대한 목록을 반환한다.
- 클라이언트는 반환된 대상 서버에 SMB(포트 445)로 실제 파일 공유를 연결한다.
따라서 어느 한 단계라도 실패하면 “접근 거부”, “구성 정보를 읽을 수 없다”, “네트워크 경로를 찾을 수 없다” 같은 오류가 발생할 수 있다.
3. 1단계: 클라이언트 측 기본 점검
DFS 네임스페이스 접근 거부가 있을 때, 먼저 클라이언트의 네트워크 및 DFS 캐시 상태를 확인하는 것이 좋다.
3.1 네트워크 및 DNS 점검
- 도메인 컨트롤러에 ping 이 정상적으로 가는지 확인한다.
- DFS 네임스페이스 서버(예:
DFS-SRV01)에 대해 다음 명령으로 SMB 연결 가능 여부를 확인한다.ping DFS-SRV01 test-netconnection DFS-SRV01 -Port 445 - 클라이언트 DNS 설정이 도메인 DNS 서버를 가리키는지 확인한다.
주의 : 포트 445가 차단되어 있으면 DFS 네임스페이스 참조를 정상적으로 받아도 실제 파일 서버 연결 단계에서 실패하여 접근 거부나 네트워크 경로 없음 오류가 발생한다.
3.2 DFS 클라이언트 캐시 상태 확인
DFS는 클라이언트에 도메인 및 서버 정보를 캐시한다. 캐시가 손상되거나 오래된 정보를 가지고 있으면 정상적인 서버가 있음에도 접근 거부가 발생할 수 있다.
다음 명령을 관리자 권한 명령 프롬프트 또는 PowerShell에서 실행하여 DFS 캐시 정보를 확인한다.
dfsutil /pktinfo dfsutil /spcinfo/pktinfo는 DFS 대상 경로에 대한 캐시 정보를 보여준다./spcinfo는 도메인 컨트롤러 및 신뢰된 도메인 정보 캐시를 보여준다.
이후 다음 명령으로 DFS 캐시를 초기화한다.
dfsutil /pktflush dfsutil /spcflush주의 : 캐시 플러시는 네임스페이스를 사용하는 다른 프로세스에 일시적인 지연을 줄 수 있으므로, 대규모 환경에서는 업무 비피크 시간에 수행하는 것이 안전하다.
4. 2단계: DFS 네임스페이스 서버 및 서비스 점검
DFS 네임스페이스 서버의 서비스 상태와 SMB 통신이 정상인지 먼저 확인해야 한다.
4.1 DFS Namespace 서비스 상태 확인
네임스페이스 서버에서 다음 PowerShell 명령으로 DFS 서비스 상태를 확인한다.
Get-Service -Name Dfs- 상태가
Running이 아니면 다음 명령으로 시작한다.Start-Service -Name Dfs - 시작이 실패하면 관련 종속 서비스(LanmanServer, Netlogon 등) 및 레지스트리 손상 여부를 추가로 점검해야 한다.
4.2 SMB 포트 및 서버 서비스 확인
- 네임스페이스 서버에서 서버 서비스(LanmanServer)가 실행 중인지 확인한다.
Get-Service -Name LanmanServer - 클라이언트에서 DFS 네임스페이스 서버의 445 포트 연결을 테스트한다.
Test-NetConnection DFS-SRV01 -Port 445 - 서버 또는 중간 방화벽에서 포트 445가 차단되어 있지 않은지 확인한다.
4.3 DFS 관리 콘솔에서 네임스페이스 상태 확인
- DFS Management 콘솔을 열고 네임스페이스를 선택한다.
- Namespace Servers 탭에서 모든 네임스페이스 서버가 “Online” 상태인지 확인한다.
- 문제가 있는 서버에는 X 표시 또는 경고 아이콘이 표시되는 경우가 많다.
- 오프라인이거나 더 이상 존재하지 않는 서버가 포함되어 있다면, 해당 서버를 제거하고 현재 실제로 사용하는 서버만 남겨야 한다.
5. 3단계: Active Directory DFS-Configuration 권한 및 메타데이터 점검
DFS 네임스페이스 구성은 Active Directory 의 CN=System, CN=Dfs-Configuration 컨테이너에 저장된다. 이 컨테이너의 ACL이 깨지거나, 네임스페이스 서버 컴퓨터 계정이 누락되면 DFS 네임스페이스 관리 또는 접근 시 “Access is denied”가 발생할 수 있다.
5.1 DFS 관리 권한 설계 원칙
- 도메인 기반 DFS 네임스페이스를 사용하는 경우, 네임스페이스 관리자는 일반적으로 다음 권한을 가진다.
- 도메인 컨트롤러에 대한 적절한 관리 권한
- DFS 네임스페이스 서버의 로컬 Administrators 그룹 또는 해당에 준하는 권한
CN=Dfs-Configuration컨테이너에 대한 Full Control 또는 최소한 Read/Write 권한
- DFS 루트가 도메인 컨트롤러에 있는 경우, Domain Admins 그룹 권한이 요구되는 경우가 많다.
5.2 ADSI Edit로 네임스페이스 개체 ACL 확인 절차
주의 : ADSI Edit는 Active Directory를 직접 수정하는 고급 도구이다. 잘못된 수정은 도메인 전체에 영향을 줄 수 있으므로, 변경 전 시스템 상태 백업 또는 스냅샷을 확보하는 것이 좋다.
- 도메인 컨트롤러 또는 RSAT가 설치된 관리용 서버에서 ADSI Edit를 실행한다.
- Connect to에서 Default naming context에 연결한다.
- 트리에서 다음 경로로 이동한다.
DC=yourdomain,DC=local └─ CN=System └─ CN=Dfs-Configuration - 문제가 되는 DFS 네임스페이스(예:
CN=DFSRootName)를 찾는다. - 해당 개체를 우클릭하여 속성(Properties)을 열고 보안(Security) 탭을 확인한다.
- 다음 항목을 확인한다.
- 현재 사용 중인 모든 네임스페이스 서버의 컴퓨터 계정이 목록에 포함되는지 확인한다.
- 각 서버 계정에 “Read all properties”, “Write all properties”가 허용되어 있는지 확인한다.
- “Account Unknown(S-1-5-…)” 같이 이미 제거된 서버의 SID가 남아 있다면 삭제하는 것이 좋다.
- 누락된 네임스페이스 서버 컴퓨터 계정을 추가하고 적절한 권한을 부여한다.
이 권한이 올바르게 설정되면, DFS 관리 콘솔에서 네임스페이스 속성 변경 시 발생하던 “Access is denied” 오류가 해소되는 경우가 많다.
5.3 DFS-Configuration 컨테이너 전체에 대한 관리 권한 부여
여러 DFS 네임스페이스를 운영하는 환경에서는 특정 관리 계정 또는 관리용 그룹(예: DFS-Admins)을 생성하여 CN=Dfs-Configuration 컨테이너에 Full Control을 부여하면, 향후 네임스페이스 추가·변경 시 권한 문제를 줄일 수 있다.
6. 4단계: 클라이언트 오프라인 파일 및 캐시 손상 문제 해결
특정 클라이언트에서만 DFS 네임스페이스 접근 거부가 발생하고, 서버 측 권한과 서비스에는 문제가 없을 때는 오프라인 파일 캐시 손상이 원인인 경우가 많다. 이 경우 DFS 네임스페이스를 FQDN 경로로 접근할 때만 “Access is denied”가 발생하고, 개별 서버 UNC 경로로 직접 접근하면 정상 동작하는 특징이 있다.
6.1 오프라인 파일 비활성화 및 캐시 초기화
- 해당 클라이언트에서 제어판 → 동기화 센터 → 오프라인 파일 관리를 연다.
- 오프라인 파일 사용 안 함(Disable Offline Files)을 선택한다.
- 관리자 권한 명령 프롬프트를 열고 다음 명령을 실행한다.
reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Csc\Parameters ^ /v FormatDatabase /t REG_DWORD /d 1 /f - 클라이언트를 재부팅한다. 재부팅 시 오프라인 파일 캐시가 초기화된다.
- 재부팅 후 DFS 네임스페이스에 다시 접근하여 문제가 해소되었는지 확인한다.
주의 : FormatDatabase 플래그를 사용하면 기존 오프라인 파일 캐시가 모두 삭제된다. 사용자가 오프라인으로만 보유하던 변경 내용이 있다면 손실될 수 있으므로, 사전 안내 후 진행해야 한다.
7. 5단계: 인증 정책(Protected Users, NTLM 제한 등) 점검
도메인 기반 DFS 네임스페이스를 새로 만들거나 관리할 때, 계정이 Domain Admins 그룹에 포함되어 있어도 Protected Users 그룹 또는 강한 NTLM 제한 정책 때문에 “The namespace cannot be queried. Access is denied.” 오류가 발생하는 경우가 있다.
7.1 Protected Users 그룹 및 NTLM 인증 제한
- Protected Users 그룹에 속한 계정은 NTLM 인증이 차단되는 등 추가적인 보안 제한을 받는다.
- DFS 네임스페이스 생성이나 변경 시 도메인 컨트롤러와의 통신에 NTLM이 사용되는 경로가 남아 있으면 인증 실패로 접근 거부가 발생할 수 있다.
7.2 점검 및 대응 절차
- DFS 네임스페이스를 생성·관리하는 계정이 Protected Users 그룹에 포함되어 있는지 확인한다.
- 해당 계정을 임시로 Protected Users에서 제외하고, 문제가 해결되는지 확인한다.
- 그룹 정책에서 “Network security: Restrict NTLM” 계열 정책이 과도하게 제한되어 있지 않은지 확인한다.
- 가능하면 Kerberos 기반 접근이 항상 정상적으로 동작하도록 SPN 설정과 시간 동기화를 유지한다.
주의 : 보안 정책을 완화할 때는 전체 도메인 보안 수준에 미치는 영향을 반드시 검토해야 한다. DFS 네임스페이스 관리 계정 전용으로 예외를 두는 방식이 상대적으로 안전하다.
8. 운영 환경에서의 DFS 네임스페이스 접근 거부 예방 체크리스트
문제가 한 번 해결되었다고 해서 끝난 것이 아니다. DFS 네임스페이스는 AD, 파일 서버, 네트워크, 클라이언트 설정이 모두 맞물리는 인프라 구성 요소이므로 정기적인 점검이 필요하다.
| 점검 항목 | 체크 방법 | 권장 주기 |
|---|---|---|
| DFS Namespace 서비스 상태 | Get-Service Dfs로 각 네임스페이스 서버 상태 확인 | 월 1회 및 장애 발생 시 |
| 네임스페이스 서버 목록 정합성 | DFS Management의 Namespace Servers 탭에서 실제 운영 서버만 포함되는지 확인 | 분기 1회 |
| DFS-Configuration ACL 건강도 | ADSI Edit로 CN=Dfs-Configuration 아래 각 네임스페이스 개체의 보안 탭 확인 | 구성 변경 후마다 |
| 오프라인 파일 정책 | 그룹 정책으로 DFS 경로에 대해 불필요한 오프라인 파일 사용이 강제되지 않는지 검토 | 정책 변경 시 |
| 인증·보안 정책 | Protected Users, NTLM 제한 정책 변경 시 DFS 접근 영향 테스트 | 보안 정책 변경 시 |
| 클라이언트 DNS 및 네트워크 | 무선망·지점 간 VPN 환경에서 DNS·포트 445 통신이 안정적인지 샘플 점검 | 반기 1회 |
FAQ
특정 몇 대 PC에서만 DFS 네임스페이스 접근 거부가 발생한다. 서버 문제인가?
일부 클라이언트에서만 문제가 발생하고 다른 다수의 PC에서는 정상이라면, 서버보다는 클라이언트 캐시·오프라인 파일·보안 소프트웨어 영향일 가능성이 크다. 이 경우 먼저 DFS 캐시 플러시(dfsutil /pktflush, /spcflush)를 수행하고, 오프라인 파일을 사용하는 환경이라면 오프라인 파일 비활성화 및 캐시 초기화를 검토하는 것이 좋다.
DFS 네임스페이스는 보이지만 폴더 대상에 접근할 때만 액세스가 거부된다.
이 경우 DFS 자체 문제라기보다는 실제 파일 서버의 공유 권한 또는 NTFS 권한 문제일 가능성이 높다. DFS 네임스페이스가 반환한 대상 서버 경로(예: \\FILE01\Share$)에 직접 UNC로 접속해 보고, 동일 계정으로 공유 권한과 NTFS 권한이 모두 적절한지 확인해야 한다. 또한 특정 사이트의 파일 서버만 실패한다면 사이트 간 네트워크 또는 방화벽 설정도 함께 확인해야 한다.
DFS Management에서 네임스페이스 속성 저장 시 “Access is denied”가 뜨지만, 사용자는 파일을 잘 쓴다.
사용자는 정상적으로 파일에 접근하지만 관리 콘솔에서만 액세스 거부가 발생한다면, Active Directory 메타데이터(DFS-Configuration) 권한 문제가 의심된다. ADSI Edit로 네임스페이스 개체의 보안 탭을 확인하여 네임스페이스 서버 컴퓨터 계정 및 관리자 계정에 적절한 Read/Write 권한이 있는지 확인해야 한다.
DFS 네임스페이스를 새로 만들 때만 “네임스페이스를 쿼리할 수 없다. 액세스가 거부되었다.”가 나온다.
이 증상은 네임스페이스 생성에 사용하는 계정의 인증 방식 제한과 관련 있는 경우가 있다. 특히 해당 계정이 Protected Users 그룹에 속해 있고, 환경에서 NTLM 인증이 금지되어 있으면 도메인 컨트롤러에 대한 인증이 실패해 네임스페이스 생성이 진행되지 않을 수 있다. 이때는 별도의 관리 계정으로 작업하거나, 임시로 Protected Users 그룹에서 제외한 뒤 생성 작업을 수행하는 방안을 검토한다.
DFS 네임스페이스를 통째로 삭제하고 새로 만드는 것이 가장 쉬운 해결책인가?
네임스페이스 구성이 단순하고 다운타임을 허용할 수 있다면 재생성이 빠를 수도 있다. 그러나 많은 사용자·애플리케이션이 해당 경로를 사용한다면 갑작스러운 경로 변경은 더 큰 장애를 일으킬 수 있다. 가능한 경우 Active Directory 메타데이터와 권한, 네임스페이스 서버 목록을 정리하여 기존 네임스페이스를 복구하는 것이 더 안전한 접근 방식이다.