Fetching One File Does Not Need a Full Network VPN

A request for VPN access often hides one folder and one file behind it. Granting a route to the whole office network answers the request and hands over far more than the task requires. Replacing a mapped share with an upload page can be just as wrong in the other direction, because it changes how people work. The decision starts with what has to happen to the file.

Three requirements look alike here and behave very differently: copying a finished PDF, editing a document in place, and running an application against a shared directory.

Start From the Edit, Not the Folder

If the file is finished and only needs reading, a transfer account is enough. If it will be edited, the question becomes who else edits it and how conflicts resolve, which is a workflow question rather than a network one. If the application opens documents directly from the directory, the latency and locking behaviour of the storage layer matter. Answering that first prevents a solution that connects perfectly and still cannot be used.

Shared editing introduces a problem no transfer can solve. A user downloads a spreadsheet, edits it offline and uploads it after somebody else changed the original, and the encrypted connection has no opinion about the overwrite. Agreement on overwrite, conflict or versioning has to exist before the access method does.

SFTP Is a Transfer Protocol, Not a Share

SFTP moves files over an encrypted SSH transport, which is exactly what a copy needs and not what a mapped drive needs. It is not FTP, and a product offering FTPS offers a different protocol rather than SFTP. Mounting an SFTP directory through a filesystem layer does not promise the locking, permission or application behaviour of the original share. Check the client application's requirements before calling that a drop-in replacement.

sftp [email protected]
put report.pdf /upload/report.pdf
get /shared/template.docx

That is the whole workflow for a finished file: connect, put, get. A transfer-only account also needs the SSH service constrained, not just the filesystem. A chroot or ForceCommand internal-sftp limits what the session can run, and disabling TCP forwarding and tunnelling closes the paths that would otherwise turn a file account into a network entry point. Restricting the visible directory alone proves nothing about what the account can reach.

If You Need the Share, Do Not Publish It

Sometimes the original share really is the requirement, and the answer is not to expose SMB to arbitrary internet clients. Microsoft's guidance is to block direct SMB traffic at the boundary, and for good reason: the protocol was not built to face untrusted networks. SMB over QUIC and comparable designs exist, with specific platform requirements at both ends, and they are not a universal switch for an arbitrary Samba server. If neither applies, the work is to provide a supported access path rather than a forwarded port.

The browser-based option is a legitimate third answer when the work fits it. It brings its own decisions: accounts, sharing links, expiry, retained versions and which copy is authoritative. A link anyone can open and a workspace that requires sign-in represent different access policies, and neither should be chosen by accident.

What to Verify Before Handing Over Access

sftp [email protected] <<< "get /shared/template.docx /tmp/probe.docx"
ssh [email protected] "cat /etc/passwd"

Whichever design you pick, scope it to the intended data and the intended operations. The first command should succeed and the second should be refused; if both succeed, the account is broader than the task. Then remove the account and repeat the first, which should now fail. Keep the owner of the source files identifiable, so a later question about the authoritative copy has an answer. The outcome worth recording is a usable and revocable file workflow, not a missing connection icon.

Write down which protocol the user's application actually needs, and which three tests you ran. Those two lines prevent most of the rework.