SMB-share op de Mac via VPN: eerst verbinden, dan schrijven testen
Finder koppelt de share maar weigert op te slaan? Scheid het VPN-pad, het SMB-account en de serverrechten voordat je een instelling wijzigt.
Als Finder de share via de VPN koppelt en daarna weigert een bestand op te slaan, doet de tunnel al zijn werk en gaat het meningsverschil over identiteit en rechten op de fileserver. Als de koppeling helemaal niet verschijnt, is niets voorbij dat punt getest. Beide gevallen eindigen in een vergelijkbare dialoog op macOS, daarom bouwen mensen VPN-profielen opnieuw voor een storing die de VPN niet kan veroorzaken. Ik begin met precies vast te leggen waar de verbinding stopt, en test daarna pas het schrijven met een wegwerptbestand in plaats van het document waarvoor ik kwam.
Drie voorwaarden bepalen waar je moet kijken
Je hebt drie antwoorden nodig voordat je een instelling aanraakt: lost de naam op naar een privéadres dat de tunnel routeert, accepteert de SMB-service precies het account dat je opgaf, en heeft dat account schrijfrechten op precies die share, map en bewerking. Elk faalt op een andere plek, en alleen de eerste is voor de VPN-beheerder.
| 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 |
De tabel verdient zijn plek omdat een Mac-login, een VPN-login en een SMB-account drie aparte identiteiten zijn. Het VPN-wachtwoord wijzigen opent nooit een share die de geregistreerde gebruiker weigert, en een client die verbinding meldt zegt niets over de server die je op het oog hebt.
Verbind op adres, niet door te bladeren
Een externe share kan volledig bereikbaar zijn en toch onzichtbaar blijven in de Netwerk-lijst van Finder. Ontdekking op een kantoor-LAN leunt op broadcast- en multicast-namen, en de meeste VPN’s dragen dat verkeer niet door de tunnel, dus een lege Netwerk-weergave is geen bewijs van een kapotte verbinding.
Start de bedoelde VPN met zijn normale client en rond de authenticatie af.
Kies in Finder Ga, dan Verbind met server, of druk op Command-K.
Typ het opgegeven adres. In dit voorbeeld is dat
smb://files.corp.example/team, een illustratieve naam en geen openbare dienst. Heb je alleen de servernaam, verbind daarmee en kies de geautoriseerde share uit de lijst die hij teruggeeft.Kies Geregistreerde gebruiker en voer het bestandsserviceaccount in, niet je Mac-account en niet het VPN-account. Gast is alleen juist als de eigenaar dat zegt.
Open de share en doe de ene taak waarvoor je kwam. Een maplijst bewijst de koppeling en niets meer.
Apple’s handleiding voor serververbinding documenteert deze Finder-werkwijze en de servicelogin erachter. Sla het adres op als favoriet zodat de volgende verbinding herhaalbaar is, en onthoud dat het hernoemen van de vermelding het label wijzigt, niet het doel.
Lees de fase waar het stopt
Noteer voordat je iets wijzigt welke fase faalt, met dezelfde namen die je in Finder hebt getypt. Begin met naamresolutie: dscacheutil -q host -a name files.corp.example print het adres dat macOS zal gebruiken, en netstat -rn laat zien of dat adres een route heeft via de tunnelinterface of via je thuisgateway.
Dan bereikbaarheid. nc -vz files.corp.example 445 zegt of de SMB-poort überhaupt antwoordt; als de resolutie werkt en 445 in een timeout loopt, zit je in routering, firewall of overlappende adressen en geen wijziging van share-rechten helpt. Als de poort antwoordt, vraag de server wat hij dat account biedt: smbutil view //[email protected] somt shares op, en smbutil statshares -a meldt de onderhandelde dialect en de ondertekeningsstatus van de gekoppelde sessie, wat je vertelt of de koppeling die je test de juiste is.
Identiteit verdient een eigen controle, want dat is de stap die mensen overslaan. Een koppeling kan leven als gast of als een ouder opgeslagen account terwijl je aanneemt de geregistreerde gebruiker te zijn, en dan meet elke schrijftest het verkeerde account.
Schrijftoegang heeft meer dan één poort
Twee lagen kunnen aan de serverkant nee zeggen, en beide zien er vanaf de Mac hetzelfde uit. Een share kan alleen-lezen zijn geëxporteerd terwijl de map eronder beschrijfbaar is, en een beschrijfbare share kan een bestandssysteem-ACL die jouw account weigert niet omzeilen; een submap kan ook eigen beleid hebben. Op Windows-servers zijn het share-recht en de NTFS-rechten gescheiden, en het effectieve recht is het strengste van de twee.
Bepaal dus wat er werkelijk geweigerd wordt: een bestand aanmaken, een bestaand bestand bewerken, een map maken, hernoemen of verwijderen. Dat is niet één recht, en een map waarin het tonen werkt kan ze allemaal weigeren. Een werkende koppeling is geen toestemming.
Vermoed je de verkeerde identiteit, werp de share dan uit, verwijder de verouderde vermelding in Sleutelhanger toegang en verbind opnieuw met het geregistreerde account. Finder hergebruikt graag een opgeslagen sessie en laat je rechten meten voor een gebruiker die de server niet als jou ziet.
Test schrijven zonder echte documenten aan te raken
Maak met toestemming van de eigenaar één klein bestand onder een nieuwe naam in de map die faalt: touch /Volumes/team/qa-write-test.txt wanneer de share daar is gekoppeld, of gewoon Bewaar als met een nieuwe naam vanuit de toepassing. Overschrijf nooit een document om toegang te testen, en bewaar de exacte fouttekst in plaats van hem te parafraseren, want de VPN kopieert hem niet.
Geef de eigenaar dan de bewerking die je hebt geprobeerd in plaats van een algemene klacht. Zij kunnen het sharebeleid, het groeplidmaatschap van het account en de rechten op die ene map controleren en je vertellen welke laag je heeft geweigerd. Als het bericht capaciteit, een vergrendeld bestand of een naamconflict noemt, is dat een ander probleem dat eigen onderzoek verdient.
Controleer de oplossing en werp dan in volgorde uit
Nadat de eigenaar iets heeft gewijzigd, herhaal je dezelfde kleine schrijfactie en bevestig je dat het bestand zichtbaar is voor de server en daarna verwijderbaar. Een kopie die begint en dan stokt is een doorvoervraag, geen rechtenvraag; een weigering die meteen komt is een rechtenvraag.
Voordat je de VPN loslaat, ontkoppel je de share en sluit je open documenten. Uitwerpen nadat de tunnel weg is laat Finder en je toepassingen op een dood pad wachten. Houd SMB binnen het privénetwerk, schakel de firewall niet uit om een theorie te testen, en open een map niet voor iedereen als omweg. Voor het ticket noteer je het adres, de accountnaam, de mislukte bewerking, de exacte berichttekst en de tijd, zonder wachtwoorden en profielbestanden.
- Het adres lost op naar een privéadres dat door de tunnel wordt gerouteerd.
- Poort 445 antwoordt en
smbutil viewsomt de bedoelde share op voor het bedoelde account. - Het schrijven dat je nodig had, wordt bewezen met een nieuw bestand, niet met een bestaand document.