Android kan bestanden op de VPN-share niet openen

De telefoon zit op de VPN, de fileserver antwoordt op een ping, en toch meldt de bestandsapp dat er geen verbinding mogelijk is, of de app verbindt wel en geen enkele editor op het toestel opent wat er in de lijst staat. Dat zijn twee verschillende storingen, en geen van beide betekent dat de tunnel stuk is. Een VPN levert alleen een route naar het privénetwerk; een share doorbladeren, je erbij authenticeren en een document aan een andere app geven zijn afzonderlijke stappen met afzonderlijke manieren om te mislukken. Hieronder staat de volgorde waarin ik ze controleer, en het punt waarop ik stop in plaats van te gokken.

Controleer de dienst voordat je de tunnel de schuld geeft

Een ping-antwoord of de NAS-webpagina bewijst alleen routing en niets anders. De dienst die je echt nodig hebt, SMB op 445, SFTP op 22 of WebDAV op 443, kan uitgeschakeld, door de firewall geblokkeerd of gebonden zijn aan een interface die het VPN-subnet niet kan bereiken. Test vanaf de telefoon die specifieke poort met een client die de echte fout toont in plaats van een algemene netwerkmelding. Als de poort gefilterd is, repareer dan de dienst of de firewallregel, want geen enkele bestandsapp kan een gesloten poort omzeilen.

Controleer ook welk bronadres de server ziet. Een split tunnel die het subnet van de share uitsluit, of een per-app-tunnel die de bestandsapp buiten de VPN laat, levert precies het symptoom verbonden-maar-onbereikbaar op.

Weersta de kortsluiting om gasttoegang of SMB1 aan te zetten omdat één client niet kan authenticeren. Zulke wijzigingen verruimen wat de server voor elk apparaat in het netwerk accepteert, en ze lossen niets op als het onderliggende probleem routing of naamresolutie is. Als de share een specifiek account nodig heeft, gebruik dat dan, inclusief het domein- of werkgroepprefix dat de server verwacht.

Gebruik een bestandsapp die het protocol zelf spreekt

Android heeft geen ingebouwde browser voor netwerkshares, dus de clientapp is een echte afhankelijkheid en geen detail. Kies er een die het protocol implementeert dat je daadwerkelijk draait en nog wordt onderhouden, want een client die voor een Android-versie is gebouwd die je niet meer gebruikt, faalt op manieren die op netwerkstoringen lijken. Als discovery niet over subnets heen komt, typ je de host expliciet in in plaats van te wachten tot de app hem vindt.

Probeer de server één keer via IP om DNS van routing te scheiden. Als het IP werkt en de naam niet, dan resolveert de telefoon via een DNS-server die je privézone niet kan zien.

Weet wat de ontvangende app krijgt: een URI, geen pad

Als je bestandsapp een DocumentsProvider implementeert, kan het Storage Access Framework van Android de inhoud in de systeemkiezer tonen, en de app die je kiest ontvangt een content://-URI plus een toestemming. Die toestemming is geen bestandssysteempad, en daarom kan een editor die op een ruwe padnaam staat er niet bij, ook al stond het document in de kiezer. De Android-documentatie over documenttoegang beschrijft het model: de provider bezit de bytes en de verbruiker leest ze via het systeem. Apps die de URI accepteren werken, apps die open() op een pad aanroepen niet. Dit is de meest voorkomende reden dat een share in de bestandsapp werkt en overal elders faalt.

Het alternatief is een bewuste kopie: haal het bestand naar de eigen opslag van de editor, bewerk het en upload het daarna terug. Dat is een prima workflow, maar het maakt een tweede kopie en een conflictvraag, dus beslis welke kant wint voordat je in de trein gaat bewerken.

Per-app-VPN-beleid verdient hier ook aandacht. Het pakket dat de netwerkread uitvoert is vaak de providerapp en niet de editor, dus neem het juiste pakket op in de tunnel in plaats van af te gaan op het pictogram dat je hebt aangetikt.

Test lezen, schrijven en het behoud van rechten apart

Een mapweergave bewijst alleen het leespad. Gebruik een onschadelijk testbestand en doorloop de hele reeks: tonen, openen, bewerken, opslaan en daarna hetzelfde bestand opnieuw openen vanaf een desktopclient.

Let op het behoud van rechten na een herstart. Opslagrechten zijn tijdelijk tenzij de app ze blijvend vastlegt, en sommige editors vragen ze bij elke start opnieuw terwijl andere stil falen en je een verouderde kopie tonen. Als een opslagactie geslaagd lijkt, controleer dat dan aan de serverkant via de wijzigingstijd of door vanaf een andere machine opnieuw te openen. Test ook een onderbreking midden in het opslaan, want een VPN-uitval tijdens een upload is precies het moment waarop een client het vaakst een gedeeltelijk bestand of een lokale wijziging achterlaat die nooit synchroniseert.

Houd de URI-toestemming van Android gescheiden van de autorisatie op de server. Mogen openen van een document zegt niets over het SMB-account erachter.

Bewaar gemounte shares voor de gevallen die ze nodig hebben

CIFS-mounts op rootniveau en kernel-filesystemmodules bestaan nog steeds, en ze geven elke app de illusie van een lokale map. Ze vereisen ook root, ze breken bij kernelwijzigingen en ze verbergen netwerkstoringen in de filesystemlaag, waar ze moeilijker te diagnosticeren zijn. Voor het bewerken van documenten op een telefoon dekt de provider- of kopieerworkflow het meeste van wat mensen echt nodig hebben.

Controleer of de mount een netwerkwijziging overleeft voordat je er een workflow op bouwt. Een share die vanaf een laptop op een bureau is gemount gedraagt zich anders dan een telefoon die tussen Wi-Fi en mobiel netwerk springt, en een verouderde mount kan een app laten hangen in plaats van netjes te falen.

Als je er nog steeds niet uitkomt, werk de lijst in volgorde af en stop bij de eerste stap die faalt: poort bereikbaar, protocolclient geïnstalleerd, share geauthenticeerd, kiezer toont het bestand, editor accepteert de URI, opslaan komt op de server aan. Die stap vertelt je welk onderdeel je moet repareren, en dat is zelden de tunnel.