Android no pot obrir fitxers al recurs compartit de la VPN

El telèfon és a la VPN, el servidor de fitxers respon al ping, i l'aplicació de fitxers encara diu que no es pot connectar, o es connecta i cap editor del dispositiu no obre el que llista. Són dues fallades diferents, i cap de les dues no vol dir que el túnel estigui trencat. Una VPN només proporciona una ruta cap a la xarxa privada; navegar per un recurs compartit, autenticar-s'hi i lliurar un document a una altra aplicació són passos separats amb maneres de fallar separades. El que ve a continuació és l'ordre en què els comprovo, i el punt on paro en lloc d'endevinar.

Comprova el servei abans de culpar el túnel

Una resposta de ping o la pàgina web del NAS demostren encaminament i res més. El servei que realment necessites, SMB al 445, SFTP al 22 o WebDAV al 443, pot estar desactivat, filtrat pel tallafoc o lligat a una interfície que la subxarxa de la VPN no pot assolir. Des del telèfon, prova aquest port concret amb un client que mostri l'error real en lloc d'un avís genèric de xarxa. Si el port està filtrat, arregla el servei o la regla del tallafoc, perquè cap aplicació de fitxers no pot esquivar un port tancat.

Comprova també quina adreça d'origen veu el servidor. Un túnel dividit que exclou la subxarxa del recurs compartit, o un túnel per aplicació que deixa l'aplicació de fitxers fora de la VPN, produeixen exactament el símptoma de connectat però inaccessible.

Resisteix la drecera d'activar l'accés de convidat o SMB1 perquè un sol client no pot autenticar-se. Aquests canvis amplien el que el servidor accepta per a tots els dispositius de la xarxa, i no arreglen res si el problema de fons és l'encaminament o la resolució de noms. Si el recurs compartit necessita un compte concret, fes-lo servir, inclòs el prefix de domini o de grup de treball que el servidor espera.

Fes servir una aplicació de fitxers que parli el protocol ella mateixa

Android no té cap navegador integrat per a recursos compartits de xarxa, així que l'aplicació client és una dependència real i no un detall. Tria'n una que implementi el protocol que realment executes i que encara es mantingui, perquè un client fet per a una versió d'Android que ja no uses falla de maneres que semblen errors de xarxa. Quan el descobriment no travessa subxarxes, escriu l'amfitrió explícitament en lloc d'esperar que l'aplicació el trobi.

Prova el servidor per IP una vegada per separar el DNS de l'encaminament. Si la IP funciona i el nom no, el telèfon resol a través d'un servidor DNS que no pot veure la teva zona privada.

Sàpigues què rep l'aplicació destinatària: un URI, no una ruta

Si la teva aplicació de fitxers implementa un DocumentsProvider, el Storage Access Framework d'Android pot mostrar-ne el contingut al selector del sistema, i l'aplicació que tries rep un URI content:// més un permís concedit. Aquest permís no és una ruta del sistema de fitxers, i per això un editor que insisteix en un nom de ruta cru no pot obrir el document encara que el selector l'hagi llistat. La guia d'accés a documents d'Android descriu el model: el proveïdor posseeix els bytes i el consumidor els llegeix a través del sistema. Les aplicacions que accepten l'URI funcionen, i les que criden open() sobre una ruta no. Aquesta és la raó més habitual per la qual un recurs compartit funciona a l'aplicació de fitxers i falla a tota la resta.

L'alternativa és una còpia deliberada: porta el fitxer a l'emmagatzematge propi de l'editor, edita'l i torna'l a pujar. És un bon flux de treball, però crea una segona còpia i una qüestió de conflicte, així que decideix quin costat guanya abans de començar a editar en un tren.

La política de VPN per aplicació també mereix una mirada aquí. El paquet que fa la lectura de xarxa sovint és l'aplicació proveïdora i no l'editor, així que inclou el paquet correcte al túnel en lloc de jutjar per la icona que has tocat.

Prova lectura, escriptura i persistència dels permisos per separat

Un llistat de directori només demostra la ruta de lectura. Fes servir un fitxer de prova inofensiu i recorre tota la seqüència: llista, obre, edita, desa i torna a obrir el mateix fitxer des d'un client d'escriptori.

Vigila la persistència dels permisos després d'un reinici. Els permisos d'emmagatzematge són temporals tret que l'aplicació els prengui de manera persistent, i alguns editors els tornen a demanar a cada arrencada mentre que d'altres fallen en silenci i et mostren una còpia antiga. Si un desament sembla reeixir, confirma'l al costat del servidor comprovant l'hora de modificació o tornant a obrir el fitxer des d'una altra màquina. Prova també una desconnexió a mig desar, perquè una caiguda de la VPN durant una pujada és exactament quan un client té més probabilitats de deixar un fitxer parcial o un canvi local que no s'ha sincronitzat mai.

Mantingues el permís d'URI d'Android separat de l'autorització del servidor. Que et permetin obrir un document no diu res sobre el compte SMB que hi ha darrere.

Reserva els recursos muntats per als casos que els necessiten

Els muntatges CIFS d'arrel i els mòduls de sistema de fitxers del nucli encara existeixen, i donen a cada aplicació la il·lusió d'un directori local. També requereixen root, es trenquen amb canvis de nucli i amaguen les fallades de xarxa dins de la capa de sistema de fitxers, on són més difícils de diagnosticar. Per editar documents en un telèfon, el flux del proveïdor o de la còpia cobreix la major part del que la gent necessita realment.

Comprova si el muntatge sobreviu a un canvi de xarxa abans de construir-hi un flux de treball. Un recurs muntat des d'un portàtil damunt d'una taula es comporta diferent d'un telèfon que salta entre Wi-Fi i mòbil, i un muntatge obsolet pot fer que una aplicació es pengi en lloc de fallar net.

Si encara estàs encallat, recorre la llista en ordre i atura't al primer pas que falla: port abastable, client del protocol instal·lat, recurs autenticat, selector que mostra el fitxer, editor que accepta l'URI, desament que arriba al servidor. Aquest pas et diu quin component arreglar, i poques vegades és el túnel.