Android öffnet keine Dateien auf der VPN-Freigabe
Ein VPN gibt dem Telefon eine Route, keinen Dateibrowser. Prüfen Sie die Erreichbarkeit des Dienstes, das Protokoll des Clients und ob Ihr Editor eine URI akzeptiert.
Das Telefon ist im VPN, der Dateiserver antwortet auf einen Ping, und die Dateiapp meldet trotzdem, sie könne keine Verbindung herstellen; oder sie verbindet, und kein Editor auf dem Gerät öffnet, was sie auflistet. Das sind zwei verschiedene Fehler, und keiner bedeutet, dass der Tunnel defekt ist. Ein VPN liefert nur eine Route ins private Netz; eine Freigabe durchsuchen, sich daran anmelden und ein Dokument an eine andere App übergeben sind getrennte Schritte mit je eigenen Arten zu scheitern. Im Folgenden die Reihenfolge, in der ich sie prüfe, und der Punkt, an dem ich aufhöre statt zu raten.
Prüfen Sie den Dienst, bevor Sie den Tunnel beschuldigen
Eine Ping-Antwort oder die Weboberfläche des NAS beweist Routing und sonst nichts. Der Dienst, den Sie wirklich brauchen, SMB auf 445, SFTP auf 22 oder WebDAV auf 443, kann deaktiviert, von der Firewall blockiert oder an eine Schnittstelle gebunden sein, die das VPN-Subnetz nicht erreicht. Testen Sie vom Telefon genau diesen Port mit einem Client, der den echten Fehler zeigt statt eines allgemeinen Netzwerkbanners. Ist der Port gefiltert, korrigieren Sie den Dienst oder die Firewall-Regel, denn keine Dateiapp umgeht einen geschlossenen Port.
Prüfen Sie auch, welche Quelladresse der Server sieht. Ein Split-Tunnel, der das Subnetz der Freigabe ausschließt, oder ein Tunnel pro App, der die Dateiapp außerhalb des VPN lässt, erzeugt genau das Symptom verbunden, aber unerreichbar.
Nehmen Sie nicht die Abkürzung über Gastzugriff oder SMB1, nur weil ein Client sich nicht anmelden kann. Solche Änderungen erweitern, was der Server für jedes Gerät im Netz akzeptiert, und sie beheben nichts, wenn das Grundproblem Routing oder Namensauflösung ist.
Nutzen Sie eine Dateiapp, die das Protokoll selbst spricht
Android hat keinen eingebauten Browser für Netzwerkfreigaben, der Client ist also eine echte Abhängigkeit und kein Detail. Wählen Sie einen, der das Protokoll implementiert, das Sie tatsächlich fahren, und noch gepflegt wird, denn ein Client für eine Android-Version, die Sie nicht mehr nutzen, scheitert auf Arten, die wie Netzwerkfehler aussehen.
Probieren Sie den Server einmal per IP, um DNS vom Routing zu trennen. Funktioniert die IP und der Name nicht, löst das Telefon über einen DNS-Server auf, der Ihre private Zone nicht sieht.
Was die empfangende App bekommt: eine URI, keinen Pfad
Implementiert Ihre Dateiapp einen DocumentsProvider, kann Androids Storage Access Framework dessen Inhalt im Systemauswahldialog zeigen, und die gewählte App erhält eine content:// URI samt Berechtigung. Diese Berechtigung ist kein Dateisystempfad, deshalb kann ein Editor, der auf einem rohen Pfad besteht, das Dokument nicht öffnen. Androids Leitfaden zum Dokumentzugriff beschreibt das Modell: der Anbieter besitzt die Bytes, der Verbraucher liest sie über das System.
Die Alternative ist eine bewusste Kopie: die Datei in den eigenen Speicher des Editors ziehen, bearbeiten und zurückschicken. Das ist ein guter Ablauf, erzeugt aber eine zweite Kopie und eine Konfliktfrage, also entscheiden Sie vor dem Bearbeiten im Zug, welche Seite gewinnt.
Auch die VPN-Richtlinie pro App verdient einen Blick. Das Paket, das den Netzwerkzugriff ausführt, ist oft die Anbieter-App und nicht der Editor, also nehmen Sie das richtige Paket in den Tunnel auf, statt nach dem Symbol zu urteilen.
Testen Sie Lesen, Schreiben und Bestand der Berechtigung getrennt
Eine Verzeichnisliste beweist nur den Lesepfad. Nehmen Sie eine harmlose Testdatei und gehen Sie die ganze Folge durch: auflisten, öffnen, bearbeiten, speichern, dann dieselbe Datei von einem Desktop-Client erneut öffnen.
Achten Sie darauf, ob die Berechtigung einen Neustart übersteht. Speicherberechtigungen sind vorläufig, sofern die App sie nicht dauerhaft macht, und manche Editoren fragen bei jedem Start neu, während andere still scheitern und eine veraltete Kopie zeigen. Scheint ein Speichern zu gelingen, bestätigen Sie es serverseitig über die Änderungszeit.
Halten Sie Androids URI-Berechtigung getrennt von der Autorisierung des Servers. Öffnen zu dürfen sagt nichts über das SMB-Konto dahinter.
Halten Sie eingebundene Freigaben für die Fälle bereit, die sie brauchen
CIFS-Einhängepunkte auf Root-Ebene und Kernel-Dateisystemmodule gibt es noch, und sie geben jeder App die Illusion eines lokalen Verzeichnisses. Sie verlangen aber Root, brechen bei Kernel-Änderungen und verstecken Netzwerkfehler in der Dateisystemschicht, wo sie schwerer zu diagnostizieren sind.
Prüfen Sie, ob das Einhängen einen Netzwerkwechsel übersteht, bevor Sie einen Ablauf darauf aufbauen. Eine vom Laptop am Schreibtisch eingebundene Freigabe verhält sich anders als ein Telefon, das zwischen WLAN und Mobilfunk wechselt, und ein veralteter Einhängepunkt lässt eine App hängen.
Wenn Sie weiter feststecken, gehen Sie die Liste der Reihe nach durch und stoppen beim ersten Schritt, der scheitert: Port erreichbar, Protokollclient installiert, Freigabe authentifiziert, Auswahl zeigt die Datei, Editor akzeptiert die URI, Speichern kommt am Server an. Dieser Schritt sagt, welche Komponente zu reparieren ist, und es ist selten der Tunnel.