Android n’ouvre pas les fichiers du partage VPN

Le téléphone est sur le VPN, le serveur de fichiers répond à un ping, et l’application de fichiers annonce toujours qu’elle ne peut pas se connecter ; ou elle se connecte et aucun éditeur de l’appareil n’ouvre ce qu’elle liste. Ce sont deux pannes différentes, et aucune ne signifie que le tunnel est cassé. Un VPN ne fournit qu’une route vers le réseau privé ; parcourir un partage, s’y authentifier et remettre un document à une autre application sont des étapes distinctes, avec chacune sa façon d’échouer. Voici l’ordre dans lequel je les vérifie, et le point où je m’arrête au lieu de deviner.

Vérifiez le service avant d’accuser le tunnel

Une réponse à un ping ou la page web du NAS prouve le routage et rien d’autre. Le service dont vous avez réellement besoin, SMB sur 445, SFTP sur 22 ou WebDAV sur 443, peut être désactivé, bloqué par le pare-feu ou lié à une interface que le sous-réseau du VPN n’atteint pas. Depuis le téléphone, testez ce port précis avec un client qui affiche la vraie erreur plutôt qu’une bannière réseau générique. Si le port est filtré, corrigez le service ou la règle du pare-feu, car aucune application de fichiers ne contourne un port fermé.

Vérifiez aussi quelle adresse source le serveur voit. Un tunnel divisé qui exclut le sous-réseau du partage, ou un tunnel par application qui laisse l’application de fichiers hors du VPN, produit exactement le symptôme connecté mais injoignable.

Ne prenez pas le raccourci d’activer l’accès invité ou SMB1 parce qu’un client ne peut pas s’authentifier. Ces changements élargissent ce que le serveur accepte pour chaque appareil du réseau et ne règlent rien si le problème de fond est le routage ou la résolution de noms.

Utilisez une application de fichiers qui parle le protocole elle-même

Android n’a pas de navigateur intégré pour les partages réseau, l’application cliente est donc une vraie dépendance et non un détail. Choisissez-en une qui implémente le protocole que vous utilisez réellement et qui est encore maintenue, car un client conçu pour une version d’Android que vous n’utilisez plus échoue d’une manière qui ressemble à une panne réseau.

Essayez le serveur par IP une fois pour séparer le DNS du routage. Si l’IP fonctionne et le nom non, le téléphone résout via un serveur DNS qui ne voit pas votre zone privée.

Ce que reçoit l’application qui ouvre : une URI, pas un chemin

Si votre application de fichiers implémente un DocumentsProvider, le Storage Access Framework d’Android peut afficher son contenu dans le sélecteur du système, et l’application que vous choisissez reçoit une URI content:// avec une autorisation. Cette autorisation n’est pas un chemin du système de fichiers, c’est pourquoi un éditeur qui exige un chemin brut ne peut pas ouvrir le document. Le guide Android d’accès aux documents décrit le modèle : le fournisseur possède les octets et le consommateur les lit via le système.

L’alternative est une copie délibérée : tirer le fichier dans le stockage propre à l’éditeur, le modifier puis le renvoyer. C’est un bon flux de travail, mais il crée une seconde copie et une question de conflit, alors décidez quel côté gagne avant de commencer à éditer dans un train.

La politique de VPN par application mérite aussi un regard. Le paquet qui fait la lecture réseau est souvent l’application fournisseur et non l’éditeur, donc incluez le bon paquet dans le tunnel au lieu de juger sur l’icône.

Testez lecture, écriture et persistance de l’autorisation séparément

Un listage de répertoire ne prouve que le chemin de lecture. Prenez un fichier de test inoffensif et parcourez toute la séquence : lister, ouvrir, modifier, enregistrer, puis rouvrir le même fichier depuis un client de bureau.

Surveillez la persistance de l’autorisation après un redémarrage. Les autorisations de stockage sont temporaires sauf si l’application les rend permanentes, et certains éditeurs les redemandent à chaque lancement tandis que d’autres échouent en silence et vous montrent une copie périmée. Si un enregistrement semble réussi, confirmez-le côté serveur via l’heure de modification.

Gardez l’autorisation URI d’Android distincte de l’autorisation du serveur. Être autorisé à ouvrir un document ne dit rien du compte SMB derrière.

Réservez les partages montés aux cas qui en ont besoin

Les montages CIFS au niveau racine et les modules de système de fichiers du noyau existent encore et donnent à chaque application l’illusion d’un répertoire local. Ils exigent cependant root, cassent lors des changements de noyau et cachent les pannes réseau dans la couche du système de fichiers, où elles sont plus difficiles à diagnostiquer.

Vérifiez si le montage survit à un changement de réseau avant de bâtir un flux de travail dessus. Un partage monté depuis un portable sur un bureau se comporte autrement qu’un téléphone qui saute entre Wi-Fi et réseau mobile, et un montage périmé peut figer une application.

Si vous êtes encore bloqué, parcourez la liste dans l’ordre et arrêtez-vous à la première étape qui échoue : port joignable, client du protocole installé, partage authentifié, sélecteur affiche le fichier, éditeur accepte l’URI, enregistrement arrive au serveur. Cette étape vous dit quel composant corriger, et c’est rarement le tunnel.