Android kan inte öppna filer på VPN-filresursen

Telefonen är på VPN:et, filservern svarar på ping, och filappen rapporterar ändå att den inte kan ansluta, eller så ansluter den och ingen editor på enheten öppnar det som listas. Det är två olika fel, och inget av dem betyder att tunneln är trasig. Ett VPN ger bara en väg in i det privata nätverket; att bläddra i en resurs, autentisera sig mot den och lämna ett dokument till en annan app är separata steg med separata sätt att misslyckas. Nedan följer ordningen jag kontrollerar dem i, och punkten där jag stannar i stället för att gissa.

Kontrollera tjänsten innan du skyller på tunneln

Ett ping-svar eller NAS:ens webbsida bevisar bara routing och inget annat. Tjänsten du faktiskt behöver, SMB på 445, SFTP på 22 eller WebDAV på 443, kan vara avstängd, blockerad av brandväggen eller bunden till ett gränssnitt som VPN-subnätet inte når. Testa den specifika porten från telefonen med en klient som visar det verkliga felet i stället för ett allmänt nätverksmeddelande. Om porten är filtrerad, åtgärda tjänsten eller brandväggsregeln, för ingen filapp kan kringgå en stängd port.

Kontrollera också vilken källadress servern ser. En delad tunnel som utesluter resursens subnät, eller en per-app-tunnel som lämnar filappen utanför VPN:et, ger exakt symtomet ansluten-men-onåbar.

Stå emot genvägen att aktivera gäståtkomst eller SMB1 för att en klient inte kan autentisera sig. Sådana ändringar vidgar vad servern accepterar från varje enhet i nätverket, och de lagar ingenting om det underliggande problemet är routing eller namnmatchning. Om resursen kräver ett specifikt konto, använd det, inklusive domän- eller arbetsgruppsprefixet som servern förväntar sig.

Använd en filapp som talar protokollet själv

Android har ingen inbyggd webbläsare för nätverksresurser, så klientappen är ett verkligt beroende och inte en detalj. Välj en som implementerar protokollet du faktiskt kör och som fortfarande underhålls, för en klient byggd för en Android-version du inte längre använder misslyckas på sätt som ser ut som nätverksfel. När upptäckten inte korsar subnät, skriv värden uttryckligen i stället för att vänta på att appen hittar den.

Prova servern via IP en gång för att skilja DNS från routing. Om IP:t fungerar och namnet inte gör det, löser telefonen namn via en DNS-server som inte ser din privata zon.

Vet vad den mottagande appen får: en URI, inte en sökväg

Om din filapp implementerar en DocumentsProvider kan Androids Storage Access Framework visa innehållet i systemväljaren, och appen du väljer från får en content://-URI plus ett behörighetsbeviljande. Det beviljandet är inte en filsökväg, vilket är varför en editor som kräver ett rått sökvägsnamn inte kan öppna dokumentet trots att väljaren listade det. Androids guide för dokumentåtkomst beskriver modellen: leverantören äger byten och konsumenten läser dem genom systemet. Appar som accepterar URI:n fungerar, och appar som anropar open() på en sökväg gör det inte. Det är den vanligaste orsaken till att en resurs fungerar i filappen och misslyckas överallt annars.

Alternativet är en medveten kopia: hämta filen till editorns eget lagringsutrymme, redigera den och ladda sedan upp den igen. Det är ett helt bra arbetsflöde, men det skapar en andra kopia och en konfliktfråga, så bestäm vilken sida som vinner innan du börjar redigera på tåget.

VPN-policy per app förtjänar också en titt här. Paketet som utför nätverksläsningen är ofta leverantörsappen och inte editorn, så ta med rätt paket i tunneln i stället för att döma efter ikonen du tryckte på.

Testa läsning, skrivning och behörigheternas varaktighet separat

En kataloglista bevisar bara läs vägen. Använd en ofarlig testfil och gå igenom hela sekvensen: lista, öppna, redigera, spara och öppna sedan samma fil igen från en skrivbordsklient.

Håll koll på om behörigheterna består efter en omstart. Lagringsbehörigheter är tillfälliga om inte appen tar dem beständigt, och vissa editorer frågar igen vid varje start medan andra misslyckas tyst och visar en gammal kopia. Om en sparning verkar lyckas, bekräfta den på serversidan genom att kontrollera ändringstiden eller öppna filen igen från en annan maskin. Testa också ett avbrott mitt i sparningen, för ett VPN-avbrott under en uppladdning är precis när en klient oftast lämnar en partiell fil eller en lokal ändring som aldrig synkroniseras.

Håll Androids URI-behörighet åtskild från auktoriseringen på servern. Att få öppna ett dokument säger ingenting om SMB-kontot bakom det.

Spara monterade resurser till de fall som behöver dem

CIFS-monteringar på rotnivå och filsystemmoduler i kärnan finns fortfarande, och de ger varje app illusionen av en lokal katalog. De kräver också root, går sönder vid kärnändringar och gömmer nätverksfel inne i filsystemslagret där de är svårare att diagnostisera. För att redigera dokument på en telefon täcker leverantörs- eller kopieringsarbetsflödet det mesta av det folk faktiskt behöver.

Kontrollera om monteringen överlever en nätverksändring innan du bygger ett arbetsflöde på den. En resurs monterad från en laptop på ett skrivbord beter sig annorlunda än en telefon som hoppar mellan Wi-Fi och mobilnät, och en inaktuell montering kan få en app att hänga sig i stället för att misslyckas rent.

Om du fortfarande sitter fast, gå igenom listan i ordning och stanna vid första steget som misslyckas: porten nåbar, protokollklienten installerad, resursen autentiserad, väljaren visar filen, editorn accepterar URI:n, sparningen landar på servern. Det steget talar om vilken komponent du ska åtgärda, och det är sällan tunneln.