Android Can't Open Files on the VPN File Share

The phone is on the VPN, the file server answers a ping, and the file app still reports that it cannot connect, or it connects and no editor on the device will open what it lists. Those are two different failures, and neither one means the tunnel is broken. A VPN only supplies a route into the private network; browsing a share, authenticating to it, and handing a document to another app are separate steps with separate ways to fail. What follows is the order I check them in, and the point where I stop instead of guessing.

Check the service before you blame the tunnel

A ping reply or the NAS web page proves routing and nothing else. The service you actually need, SMB on 445, SFTP on 22, or WebDAV on 443, may be disabled, firewalled, or bound to an interface the VPN subnet cannot reach. From the phone, test that specific port with a client that shows the real error rather than a generic network banner. If the port is filtered, fix the service or the firewall rule, because no file app can work around a closed port.

Also check which source address the server sees. A split tunnel that excludes the share's subnet, or a per-app tunnel that leaves the file app outside the VPN, produces exactly the connected-but-unreachable symptom.

Resist the shortcut of enabling guest access or SMB1 because one client cannot authenticate. Those changes widen what the server accepts for every device on the network, and they fix nothing if the underlying problem is routing or name resolution. If the share needs a specific account, use it, including the domain or workgroup prefix the server expects.

Use a file app that speaks the protocol itself

Android has no built-in browser for network shares, so the client app is a real dependency rather than a detail. Pick one that implements the protocol you actually run and is still maintained, because a client built for an Android release you no longer use fails in ways that look like network faults. When discovery does not cross subnets, type the host explicitly instead of waiting for the app to find it.

Try the server by IP once to separate DNS from routing. If the IP works and the name does not, the phone is resolving through a DNS server that cannot see your private zone.

Know what the receiving app is handed: a URI, not a path

If your file app implements a DocumentsProvider, Android's Storage Access Framework can show its contents in the system picker, and the app you pick from receives a content:// URI plus a permission grant. That grant is not a filesystem path, which is why an editor that insists on a raw pathname cannot open the document even though the picker listed it. The Android document-access guide describes the model: the provider owns the bytes and the consumer reads them through the system. Apps that accept the URI work, and apps that call open() on a path do not. This is the most common reason a share works in the file app and fails everywhere else.

The alternative is a deliberate copy: pull the file into the editor's own storage, edit it, then upload it back. That is a fine workflow, but it creates a second copy and a conflict question, so decide which side wins before you start editing on a train.

Per-app VPN policy deserves a look here too. The package that performs the network read is often the provider app rather than the editor, so include the right package in the tunnel instead of judging by the icon you tapped.

Test read, write, and permission persistence separately

A directory listing only proves the read path. Use a harmless test file and walk the whole sequence: list, open, edit, save, then reopen the same file from a desktop client.

Watch for permission persistence after a reboot. Storage grants are temporary unless the app takes them persistently, and some editors re-request on every launch while others fail quietly and show you a stale copy. If a save appears to succeed, confirm it on the server side by checking the modification time or by reopening from another machine. Test a mid-save disconnect as well, because a VPN drop during an upload is exactly when a client is most likely to leave a partial file or a local change that never syncs.

Keep Android's URI permission separate from the server's authorization. Being allowed to open a document says nothing about the SMB account behind it.

Reserve mounted shares for the cases that need them

Root-level CIFS mounts and kernel filesystem modules still exist, and they give every app the illusion of a local directory. They also require root, they break on kernel changes, and they hide network failures inside the filesystem layer where they are harder to diagnose. For editing documents on a phone, the provider or copy workflow covers most of what people actually need.

Check whether the mount survives a network change before you build a workflow on it. A share mounted from a laptop on a desk behaves differently from a phone that hops between Wi-Fi and cellular, and a stale mount can make an app hang rather than fail cleanly.

If you are still stuck, work the list in order and stop at the first step that fails: port reachable, protocol client installed, share authenticated, picker shows the file, editor accepts the URI, save lands on the server. That step tells you which component to fix, and it is rarely the tunnel.