Android kan ikke åpne filer på VPN-fildelingen

Telefonen er på VPN-en, filserveren svarer på ping, og likevel melder filappen at den ikke får kontakt, eller den kobler til og ingen editor på enheten åpner det som listes opp. Dette er to forskjellige feil, og ingen av dem betyr at tunnelen er ødelagt. En VPN gir bare en rute inn i det private nettverket; å bla gjennom en deling, autentisere seg mot den og gi et dokument videre til en annen app er separate trinn med hver sin måte å feile på. Nedenfor står rekkefølgen jeg sjekker dem i, og punktet der jeg stopper i stedet for å gjette.

Sjekk tjenesten før du gir tunnelen skylden

Et ping-svar eller nettsiden til NAS-en beviser bare ruting og ingenting annet. Tjenesten du faktisk trenger, SMB på 445, SFTP på 22 eller WebDAV på 443, kan være slått av, blokkert av brannmuren eller bundet til et grensesnitt som VPN-subnettet ikke når. Test den aktuelle porten fra telefonen med en klient som viser den virkelige feilen i stedet for en generell nettverksmelding. Er porten filtrert, må du rette tjenesten eller brannmurregelen, for ingen filapp kommer rundt en lukket port.

Sjekk også hvilken kildeaddresse serveren ser. En split tunnel som utelater subnettet til delingen, eller en per-app-tunnel som lar filappen stå utenfor VPN-en, gir nøyaktig symptomet tilkoblet men utilgjengelig.

Motstå snarveien med å slå på gjestetilgang eller SMB1 fordi én klient ikke får autentisert seg. Slike endringer utvider det serveren godtar for hver enhet i nettverket, og de reparerer ingenting hvis det underliggende problemet er ruting eller navneoppslag. Trenger delingen en bestemt konto, bruk den, inkludert domene- eller arbeidsgruppeprefikset serveren forventer.

Bruk en filapp som snakker protokollen selv

Android har ingen innebygd leser for nettverksdelinger, så klientappen er en reell avhengighet og ikke en detalj. Velg en som implementerer protokollen du faktisk kjører og som fortsatt vedlikeholdes, for en klient bygget for en Android-versjon du ikke bruker lenger, feiler på måter som ligner nettverksfeil. Når oppdagelsen ikke krysser subnett, skriv vertsnavnet eksplisitt i stedet for å vente på at appen finner det.

Prøv serveren via IP én gang for å skille DNS fra ruting. Virker IP-en og ikke navnet, slår telefonen opp gjennom en DNS-server som ikke ser den private sonen din.

Vit hva mottakerappen får: en URI, ikke en sti

Hvis filappen din implementerer en DocumentsProvider, kan Androids Storage Access Framework vise innholdet i systemvelgeren, og appen du velger fra, mottar en content://-URI pluss en tillatelse. Den tillatelsen er ikke en filsystemsti, og derfor kan ikke en editor som krever et rå stinavn åpne dokumentet selv om velgeren listet det opp. Androids veiledning for dokumenttilgang beskriver modellen: leverandøren eier bytene og forbrukeren leser dem gjennom systemet. Apper som godtar URI-en, virker, og apper som kaller open() på en sti, gjør det ikke. Dette er den vanligste grunnen til at en deling virker i filappen og feiler overalt ellers.

Alternativet er en bevisst kopi: hent filen inn i editorens eget lager, rediger den og last den opp igjen. Det er en helt fin arbeidsflyt, men den lager en andre kopi og et konfliktsprørsmål, så bestem hvilken side som vinner før du begynner å redigere på toget.

VPN-policy per app fortjener også et blikk her. Pakken som gjør nettverkslesingen, er ofte leverandørappen og ikke editoren, så ta med riktig pakke i tunnelen i stedet for å dømme etter ikonet du trykket på.

Test lesing, skriving og hvor lenge tillatelsene varer hver for seg

En mappeliste beviser bare lesestien. Bruk en ufarlig testfil og gå gjennom hele sekvensen: liste, åpne, redigere, lagre og deretter åpne samme fil på nytt fra en skrivebordsklient.

Følg med på om tillatelsene varer etter en omstart. Lagringstillatelser er midlertidige med mindre appen tar dem varig, og noen editorer spør på nytt ved hver oppstart mens andre feiler stille og viser deg en utdatert kopi. Ser en lagring ut til å lykkes, bekreft den på serversiden ved å sjekke endringstiden eller ved å åpne på nytt fra en annen maskin. Test også et avbrudd midt i lagringen, for et VPN-brudd under opplasting er nettopp når en klient oftest etterlater en delvis fil eller en lokal endring som aldri synkroniseres.

Hold Androids URI-tillatelse atskilt fra autorisasjonen på serveren. Å få lov til å åpne et dokument sier ingenting om SMB-kontoen bak det.

Spar monterte delinger til tilfellene som trenger dem

CIFS-monteringer på rotnivå og filsystemmoduler i kjernen finnes fortsatt, og de gir hver app illusjonen av en lokal mappe. De krever også root, de bryter sammen ved kjerneendringer, og de skjuler nettverksfeil inne i filsystemlaget der de er vanskeligere å diagnostisere. For å redigere dokumenter på en telefon dekker leverandør- eller kopieringsarbeidsflyten det meste folk faktisk trenger.

Sjekk om monteringen overlever en nettverksendring før du bygger en arbeidsflyt på den. En deling montert fra en laptop på et skrivebord oppfører seg annerledes enn en telefon som hopper mellom Wi-Fi og mobilnett, og en utdatert montering kan få en app til å henge i stedet for å feile ryddig.

Hvis du fortsatt står fast, gå gjennom listen i rekkefølge og stopp ved første trinn som feiler: porten nås, protokollklienten er installert, delingen er autentisert, velgeren viser filen, editoren godtar URI-en, lagringen lander på serveren. Det trinnet forteller deg hvilken komponent du skal rette, og det er sjelden tunnelen.