공유폴더에서 문서를 열 수는 있지만 수정한 내용을 저장하지 못하는 경우가 있습니다. 관리자가 폴더의 보안 설정에 ‘수정’을 허용했는데도 같은 문제가 계속되면, 권한을 추가하기 전에 공유 권한까지 함께 확인해야 합니다.
Windows의 NTFS 기반 공유폴더에는 네트워크 접근을 제어하는 공유 권한과 파일·폴더 자체의 접근을 제어하는 NTFS 권한이 적용됩니다. 두 설정을 서로 다른 수준으로 지정하면 관리자가 의도한 작업과 실제 가능한 작업이 달라질 수 있습니다.
공유 경로로 접근하면 두 권한을 모두 확인
공유 권한은 \\FS01\TeamDocs처럼 SMB 공유 경로로 접근할 때 적용됩니다. 일반적인 권한 수준은 읽기, 변경, 모든 권한입니다. NTFS 권한은 파일과 폴더에 설정하며, 로컬 접근과 공유 경로 접근 모두에 적용됩니다.
공유 경로에서는 수행하려는 작업이 두 권한에서 모두 허용되어야 합니다. 따라서 공유 권한이 읽기이고 NTFS 권한이 수정이면, 네트워크로 접속한 사용자는 수정할 수 없습니다. 반대로 공유 권한을 모든 권한으로 설정해도 NTFS 권한이 읽기라면 파일을 수정할 수 없습니다. Dell의 Windows 권한 설명에서도 이 결합 원칙을 설명합니다.
아래는 다른 그룹의 추가 허용이나 거부, 별도의 하위 파일 설정이 없다고 가정한 예시입니다.
| 공유 권한 | NTFS 권한 | 공유 경로에서 가능한 작업 |
|---|---|---|
| 읽기 | 수정 | 읽기 가능, 수정 불가 |
| 변경 | 읽기 및 실행 | 읽기 가능, 수정 불가 |
| 변경 | 수정 | 일반적인 읽기·쓰기·삭제 가능 |
사례 1 — 보안 탭에서는 수정인데 저장이 안 되는 경우
다음은 설명을 위한 가정 사례입니다. 영업팀 그룹에 D:\TeamDocs의 NTFS 수정 권한을 부여했지만, 해당 폴더를 공개한 TeamDocs 공유에는 읽기만 허용했다고 가정하겠습니다.
사용자는 공유 경로에서 문서를 열 수 있지만 변경 내용을 저장할 수 없습니다. 이때 NTFS 수정 권한을 다시 추가해도 공유 권한의 읽기 제한은 남습니다. 먼저 폴더 속성의 ‘공유 → 고급 공유 → 권한’에서 해당 사용자와 소속 그룹의 설정을 확인해야 합니다.
업무상 편집이 필요하다면 승인된 그룹의 공유 권한을 변경 수준으로 조정하고, NTFS에서도 수정이 허용되는지 확인합니다. 확인되지 않은 원인을 해결하려고 모든 사용자에게 모든 권한을 부여하는 방식은 접근 범위를 불필요하게 넓힙니다.
사례 2 — 개인 계정은 읽기인데 그룹을 통해 수정되는 경우
공유 권한에서 변경을 허용하고, NTFS에서는 사용자 개인에게 읽기를 허용했다고 가정하겠습니다. 그런데 같은 사용자가 속한 편집자 그룹에도 NTFS 수정이 허용되어 있다면, 개인 계정의 읽기 설정만으로 수정 작업을 제한할 수 없습니다.
같은 권한 체계 안에서 여러 허용 항목은 합산될 수 있습니다. 사용자 개인의 읽기 허용은 권한의 상한선이 아니므로, 읽기 전용 사용자를 만들려면 수정 권한을 제공하는 그룹 소속과 다른 허용 경로까지 점검해야 합니다.
반대로 같은 대상에 적용되는 명시적 쓰기 거부가 있다면, 명시적 수정 허용과 충돌해 쓰기가 차단될 수 있습니다. 다만 ‘거부는 무조건 모든 허용보다 우선한다’고 단순화하면 상속 권한을 잘못 판단할 수 있습니다. Microsoft의 접근 검사 설명은 사용자·그룹 정보와 접근 제어 항목의 평가 순서를 함께 설명합니다.
실제 점검은 계정·공유·파일 순서로 진행
먼저 문제가 발생한 공유 경로와 실패한 작업을 기록합니다. ‘접근 불가’로 묶기보다 폴더 열기, 파일 읽기, 새 파일 생성, 기존 파일 저장, 삭제 중 어디에서 실패하는지 구분해야 합니다. 이어 실제 SMB 연결에 사용된 계정이 의도한 계정인지 확인합니다.
파일서버에서는 다음 명령으로 공유 권한과 NTFS 권한을 각각 조회할 수 있습니다. 공유 이름과 로컬 경로는 예시이며, 해당 정보를 조회할 권한이 있는 관리자가 서버에서 실행하는 상황을 전제로 합니다.
Get-SmbShareAccess -Name "TeamDocs"
icacls "D:\TeamDocs"
icacls "D:\TeamDocs\견적서.xlsx"Get-SmbShareAccess는 공유의 접근 제어 목록을 보여줍니다. icacls는 대상 파일·폴더의 NTFS 접근 제어 목록을 표시하며, (I)는 상속된 항목을 의미합니다. 위 명령은 조회용이며 권한을 변경하지 않습니다.
최상위 폴더의 권한만으로 하위 파일까지 동일하다고 판단해서는 안 됩니다. 문제가 발생한 파일에 별도 권한이 있거나 상속이 중단되었을 수 있으므로 실제 대상도 확인합니다. 조정 후에는 영향을 받는 사용자 계정으로 필요한 작업과 제한해야 할 작업을 각각 시험합니다.
자주 묻는 질문
서버에서는 수정되는데 다른 PC에서는 안 되는 이유는 무엇인가요?
같은 계정이라도 서버의 로컬 경로로 접근하면 공유 권한 검사를 거치지 않습니다. 먼저 로컬 경로와 공유 경로의 차이인지 확인하고, 서로 다른 계정으로 시험한 것은 아닌지도 구분해야 합니다.
공유 권한을 읽기로 설정하면 서버 내부에서도 수정이 차단되나요?
공유 권한만으로는 로컬 경로의 수정을 제한하지 못합니다. 서버 내부 접근까지 통제하려면 NTFS 권한을 함께 설계해야 합니다.
두 권한이 충분하면 모든 저장 오류를 해결할 수 있나요?
파일 잠금이나 응용프로그램의 저장 방식 때문에 실패할 수도 있습니다. 두 권한에서 필요한 작업이 허용되는 것을 확인했다면 오류 메시지와 파일 사용 상태를 바탕으로 다른 원인을 점검해야 합니다.
결론
Windows 공유폴더의 권한 충돌은 한쪽 설정 화면만 보고 판단할 때 놓치기 쉽습니다. 공유 경로와 접속 계정을 확인하고, 공유 권한과 실제 파일의 NTFS 권한을 나누어 점검해야 합니다.
권한 조정은 승인된 사용자·그룹과 필요한 작업 범위에 맞춰 진행합니다. 변경 후 같은 사용자로 읽기·생성·저장·삭제를 구분해 확인하면 과도한 권한 부여와 미해결 상태를 함께 줄일 수 있습니다.
참고자료
확인일: 2026-10-27. Windows의 NTFS 기반 일반 SMB 공유를 대상으로 하며, Azure Files의 별도 역할 기반 권한은 다루지 않습니다.