Mac의 VPN 경유 SMB 공유: 먼저 연결하고, 다음에 쓰기 테스트
Finder가 공유를 마운트하지만 저장을 거부합니까? 설정을 바꾸기 전에 VPN 경로, SMB 계정, 서버 권한을 분리하세요.
Finder가 VPN을 통해 공유를 마운트한 뒤 파일 저장을 거부한다면 터널은 이미 제 역할을 하고 있고, 불일치는 파일 서버의 신원과 권한에 관한 것입니다. 마운트 자체가 보이지 않는다면 그 지점 이후로는 아무것도 검증되지 않았습니다. 두 경우 모두 macOS에서 비슷한 대화상자로 끝나기에 사람들은 VPN이 만들 수 없는 장애 때문에 VPN 프로필을 다시 만듭니다. 저는 먼저 연결이 정확히 어디서 멈추는지 확정하고, 그다음에야 편집하러 온 문서 대신 일회용 파일로 쓰기를 시험합니다.
어디를 볼지 세 가지 조건이 결정한다
설정을 건드리기 전에 세 가지 답이 필요합니다. 이름이 터널이 라우팅하는 사설 주소로 해석되는지, SMB 서비스가 지정한 특정 계정을 받아들이는지, 그 계정이 바로 그 공유와 폴더와 작업에 쓰기 권한을 갖는지이며, 각각 다른 지점에서 실패하고 VPN 소유자의 몫은 첫 번째뿐입니다.
| What you see | What it establishes | Who fixes it |
|---|---|---|
| Name does not resolve, or resolves outside the tunnel | The path was never built | VPN or DNS administrator |
| Name resolves, port 445 times out | Route, firewall or overlapping address space | VPN and network owners |
| Server answers, the sign-in is rejected | The file-service account, not the VPN login | File-server owner |
| Share mounts, writing is refused | Share policy or directory rights | File-server owner |
이 표가 값을 하는 이유는 Mac 로그인, VPN 로그인, SMB 계정이 세 개의 별개 신원이기 때문입니다. VPN 암호를 바꿔도 등록 사용자를 거부하는 공유는 절대 열리지 않고, 연결되었다고 보고하는 클라이언트는 겨냥한 서버에 대해 아무것도 말해 주지 않습니다.
탐색이 아니라 주소로 연결한다
원격 공유는 완전히 접근 가능하면서도 Finder의 네트워크 목록에는 보이지 않을 수 있습니다. 사무실 LAN의 검색은 브로드캐스트와 멀티캐스트 이름에 기대고, 대부분의 VPN은 그 트래픽을 터널로 전달하지 않으므로 빈 네트워크 보기는 끊긴 링크의 증거가 아닙니다.
의도한 VPN을 평소 클라이언트로 시작하고 인증을 마칩니다.
Finder에서 이동을 고르고 서버에 연결을 선택하거나 Command-K를 누릅니다.
받은 주소를 입력합니다. 이 예에서는
smb://files.corp.example/team입니다. 공개 서비스가 아니라 설명용 이름이며, 서버 이름만 있다면 그것에 연결한 뒤 돌려주는 목록에서 허용된 공유를 고릅니다.등록 사용자를 고르고 파일 서비스 계정을 입력합니다. Mac 계정도 VPN 계정도 아니며, 손님은 소유자가 그렇다고 할 때만 맞습니다.
공유를 열고 온 목적의 작업 하나만 합니다. 폴더 목록은 마운트를 증명할 뿐 그 이상은 아닙니다.
Apple의 서버 연결 안내서 는 이 Finder 작업 흐름과 그 뒤의 서비스 로그인을 설명합니다. 주소를 즐겨찾기로 저장하면 다음 연결을 반복할 수 있고, 항목 이름을 바꾸면 바뀌는 것은 라벨이지 대상이 아니라는 점을 기억하세요.
멈추는 단계를 읽는다
무엇이든 바꾸기 전에 어느 단계가 실패하는지 Finder에 입력한 같은 이름으로 기록합니다. 이름 확인부터 시작합니다: dscacheutil -q host -a name files.corp.example 는 macOS가 사용할 주소를 출력하고, netstat -rn 는 그 주소가 터널 인터페이스로 가는 경로인지 집 게이트웨이로 가는 경로인지 보여 줍니다.
다음은 도달 가능성입니다. nc -vz files.corp.example 445 는 SMB 포트가 아예 응답하는지 알려 주고, 이름 확인이 되고 445가 시간 초과라면 라우팅, 방화벽, 주소 중복 영역이므로 공유 권한을 바꿔도 도움이 되지 않으며, 포트가 응답하면 그 계정에 무엇을 제공하는지 서버에 다음과 같이 묻습니다. smbutil view //[email protected] 는 공유를 나열하고, smbutil statshares -a 는 마운트된 세션의 협상된 방언과 서명 상태를 보고하여 시험 중인 마운트가 생각하는 그것인지 알려 줍니다.
신원은 사람들이 건너뛰는 단계이므로 따로 확인할 가치가 있습니다. 자신이 등록 사용자라고 여기는 동안 마운트가 손님이나 오래된 저장 계정으로 살아 있을 수 있고, 그러면 모든 쓰기 시험이 잘못된 계정을 재게 됩니다.
쓰기 접근에는 문이 하나가 아니다
서버 쪽에서 두 계층이 거부할 수 있고 둘 다 Mac에서는 똑같아 보입니다. 공유가 읽기 전용으로 내보내졌는데 그 아래 폴더는 쓰기 가능할 수 있고, 쓰기 가능한 공유라도 계정을 거부하는 파일 시스템 ACL을 넘을 수 없고, 하위 폴더가 자체 정책을 가질 수도 있습니다. Windows 서버에서는 공유 권한과 NTFS 권한이 별개이며 유효 권한은 둘 중 더 엄격한 쪽입니다.
그러므로 무엇이 실제로 거부되는지 정합니다. 파일 만들기, 기존 파일 편집, 폴더 만들기, 이름 바꾸기, 삭제입니다. 이것은 하나의 권한이 아니며 목록이 되는 폴더도 전부 거부할 수 있고, 마운트가 된다고 허가가 되는 것은 아닙니다.
신원이 잘못된 것 같으면 공유를 꺼내고 키체인 접근의 오래된 항목을 지운 뒤 등록 계정으로 다시 연결합니다. Finder는 저장된 세션을 기꺼이 재사용하며 서버가 당신으로 보지 않는 사용자의 권한을 재게 만듭니다.
실제 문서를 건드리지 않고 쓰기를 시험한다
소유자의 동의를 얻어 실패하는 폴더에 새 이름으로 작은 파일 하나를 만듭니다: touch /Volumes/team/qa-write-test.txt 공유가 그곳에 마운트되어 있을 때, 또는 그냥 응용 프로그램에서 새 이름으로 다른 이름으로 저장합니다. 접근을 시험하려고 문서를 덮어쓰지 말고, VPN이 복사하지 않는 오류의 정확한 문구를 그대로 두세요.
그다음 일반적인 불평 대신 시도한 작업을 소유자에게 전달합니다. 소유자는 공유 정책, 계정의 그룹 소속, 그 한 폴더의 권한을 확인하고 어느 계층이 거부했는지 알려 줄 수 있습니다. 메시지가 용량, 잠긴 파일, 이름 충돌을 언급한다면 다른 문제이며 자체 조사가 필요합니다.
수정을 확인하고 순서대로 꺼낸다
소유자가 무언가를 바꾼 뒤 같은 작은 쓰기를 반복하고 파일이 서버에 보이고 나중에 지울 수 있는지 확인합니다. 시작했다가 멈추는 복사는 처리량 문제이고 권한 문제가 아니며, 즉시 오는 거부는 권한 문제입니다.
VPN을 끊기 전에 공유를 마운트 해제하고 열린 문서를 닫습니다. 터널이 사라진 뒤 꺼내면 Finder와 응용 프로그램이 죽은 경로에서 기다립니다. SMB는 사설 네트워크 안에 두고, 이론을 시험하려고 방화벽을 끄지 말고, 우회책으로 폴더를 모두에게 열지 마세요. 티켓에는 주소, 계정 이름, 실패한 작업, 메시지의 정확한 문구, 시각을 넣고 암호와 프로필 파일은 빼세요.
- 주소는 터널을 통해 라우팅되는 사설 주소로 해석됩니다.
- 포트 445가 응답하고
smbutil view는 의도한 계정에 대해 의도한 공유를 나열합니다. - 필요했던 쓰기는 기존 문서가 아니라 새 파일로 증명됩니다.