SMB-deling på Mac over VPN: koble til først, test skriving etterpå
Finder monterer delingen, men nekter å lagre? Skille VPN-veien, SMB-kontoen og servertillatelsen før du endrer noen innstilling.
Hvis Finder monterer delingen over VPN og deretter nekter å lagre en fil, gjør tunnelen allerede jobben sin, og uenigheten handler om identitet og rettigheter på filserveren. Hvis monteringen aldri dukker opp, er ingenting ut over det punktet testet. Begge tilfellene ender i en lignende dialog på macOS, og derfor bygger folk VPN-profiler på nytt for en feil VPN ikke kan produsere. Jeg begynner med å fastslå nøyaktig hvor forbindelsen stopper, og tester først etterpå skriving med en engangsfil i stedet for dokumentet jeg kom for å redigere.
Tre vilkår avgjør hvor du skal se
Du trenger tre svar før du rører en innstilling: løses navnet til en privat adresse som tunnelen ruter, godtar SMB-tjenesten den konkrete kontoen du oppga, og har den kontoen skriverettigheter på akkurat den delingen, mappen og handlingen. Hver av dem feiler på ulikt sted, og bare den første tilhører VPN-eieren.
| 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 |
Tabellen fortjener plassen fordi Mac-pålogging, VPN-pålogging og SMB-konto er tre atskilte identiteter. Å endre VPN-passordet åpner aldri en deling som avviser den registrerte brukeren, og en klient som melder forbindelse sier ingenting om serveren du sikter mot.
Koble til via adresse, ikke ved å bla
En ekstern deling kan være fullt tilgjengelig og likevel usynlig i Finders Nettverk-liste. Oppdagelse på et kontor-LAN hviler på broadcast- og multicast-navn, og de fleste VPN-er fører ikke den trafikken gjennom tunnelen, så en tom Nettverk-visning er ikke bevis på en brutt lenke.
Start den tiltenkte VPN-en med dens vanlige klient og fullfør autentiseringen.
I Finder velger du Gå, deretter Koble til server, eller trykker Command-K.
Skriv inn adressen du fikk. I dette eksempelet er det
smb://files.corp.example/team, et illustrerende navn og ikke en offentlig tjeneste. Hvis du bare har servernavnet, kobler du til det og velger den autoriserte delingen fra listen det returnerer.Velg Registrert bruker og skriv inn filservicekontoen, ikke Mac-kontoen din og ikke VPN-kontoen. Gjest er bare riktig når eieren sier det.
Åpne delingen og gjør den ene oppgaven du kom for. En mappeliste beviser monteringen og ikke noe mer.
Apples veiledning for serverforbindelse dokumenterer denne Finder-flyten og tjenestepåloggingen bak. Lagre adressen som favoritt slik at neste forbindelse kan gjentas, og husk at å gi oppføringen nytt navn endrer etiketten, ikke målet.
Les trinnet der det stopper
Før du endrer noe, noter hvilket trinn som feiler, med de samme navnene du skrev i Finder. Begynn med navneoppslag: dscacheutil -q host -a name files.corp.example skriver ut adressen macOS vil bruke, og netstat -rn viser om den adressen har en rute gjennom tunellgrensesnittet eller gjennom hjemmegatewayen din.
Så tilgjengelighet. nc -vz files.corp.example 445 sier om SMB-porten i det hele tatt svarer; hvis oppslaget virker og 445 går i timeout, er du i området ruting, brannmur eller overlappende adresser, og ingen endring av delingstillatelser hjelper. Hvis porten svarer, spør serveren hva den tilbyr den kontoen: smbutil view //[email protected] lister delinger, og smbutil statshares -a rapporterer den monterte sesjonens forhandlede dialekt og signeringstilstand, noe som forteller deg om monteringen du tester er den du tror.
Identitet fortjener sin egen sjekk, fordi det er trinnet folk hopper over. En montering kan leve som gjest eller som en eldre lagret konto mens du antar at du er den registrerte brukeren, og da måler hver skrivetest feil konto.
Skrivetilgang har mer enn én port
To lag kan si nei på serversiden, og begge ser like ut fra Macen. En deling kan være eksportert skrivebeskyttet mens mappen under er skrivbar, og en skrivbar deling kan ikke overstyre en filsystem-ACL som avviser kontoen din; en undermappe kan også ha sin egen policy. På Windows-servere er delingstillatelsen og NTFS-tillatelsene atskilt, og den effektive retten er den strengeste av de to.
Så avgjør hva som faktisk avvises: å opprette en fil, redigere en eksisterende, lage en mappe, gi nytt navn eller slette. Det er ikke én tillatelse, og en mappe der listing virker kan avvise dem alle. En fungerende montering er ikke en innvilgelse.
Hvis du mistenker feil identitet, løser du ut delingen, sletter den foreldede oppføringen i Nøkkelringtilgang og kobler til igjen med den registrerte kontoen. Finder gjenbruker gjerne en lagret sesjon og lar deg måle tillatelser for en bruker serveren ikke anser som deg.
Test skriving uten å røre ekte dokumenter
Med eierens samtykke oppretter du én liten fil under et nytt navn i mappen som feiler: touch /Volumes/team/qa-write-test.txt når delingen er montert der, eller bare Lagre som med et nytt navn fra programmet. Overskriv aldri et dokument for å teste tilgang, og ta vare på den nøyaktige feilmeldingen i stedet for å omformulere den, fordi VPN-en ikke kopierer den.
Deretter gir du eieren operasjonen du forsøkte i stedet for en generell klage. De kan sjekke delingens policy, kontoens gruppemedlemskap og rettighetene på akkurat den mappen, og si hvilket lag som avviste deg. Hvis meldingen nevner kapasitet, en låst fil eller en navnekonflikt, er det et annet problem som fortjener sin egen undersøkelse.
Bekreft rettelsen, og løs deretter ut i rekkefølge
Etter at eieren har endret noe, gjenta den samme lille skrivingen og bekreft at filen er synlig for serveren og kan fjernes etterpå. En kopiering som starter og deretter stopper, er et gjennomstrømningsspørsmål, ikke et tillatelsesspørsmål; en avvisning som kommer umiddelbart, er et tillatelsesspørsmål.
Før du slipper VPN-en, avmonterer du delingen og lukker åpne dokumenter. Å løse ut etter at tunnelen er borte lar Finder og programmene dine vente på en død sti. Hold SMB inne i det private nettet, ikke slå av brannmuren for å teste en teori, og ikke åpne en mappe for alle som en omvei. For saken tar du med adressen, kontonavnet, den mislykkede operasjonen, den nøyaktige meldingsteksten og klokkeslettet, og lar passord og profilfiler være utenfor.
- Adressen løses til en privat adresse som rutes gjennom tunnelen.
- Port 445 svarer, og
smbutil viewlister den tiltenkte delingen for den tiltenkte kontoen. - Skrivingen du trengte, bevises med en ny fil, ikke med et eksisterende dokument.