Getting a file into a virtual machine, when Proxmox has no file manager

You have a file on your own computer and it needs to be inside a guest. You look through the interface for an upload button pointing that way, and there is not one.

That absence is a design decision, not an oversight, and understanding why makes the rest of this obvious. Proxmox VE manages the machine, not the inside of the machine. From the outside a guest's storage is a disk image: a large opaque blob. The hypervisor does not read the filesystem in it, which is precisely why it can host any operating system without knowing anything about it.

So every way in is a way of crossing that boundary on purpose, and each one crosses it differently.

The boring answer that is usually the right one

Copy it over the network, the same way you would to any other machine. A file copy over SSH, a file share, an object store, a web download from inside the guest.

This gets skipped surprisingly often because it feels too ordinary, as though virtualisation ought to offer something better. It does not, and it should not. The guest is a machine on your network; treat it like one. This path handles any size, keeps its own permissions, and does not involve the hypervisor at all.

The cases below are for when this one is not available.

When the guest is unreachable but running

The guest agent gives you a channel that does not use the network, because it runs over a virtual device between host and guest.

It genuinely can read and write files. The two operations exist as their own endpoints, and they are exactly what you want for dropping a configuration file or a key into a machine that has lost its network.

The limit worth knowing before you rely on it: a single write is capped at around 60 KB, and reads of larger files come back marked as truncated. This channel was built for small things. It is excellent for a config file and useless for an installer image, and finding that out mid-incident is worse than reading it here.

On the host used to check this, seven of eight virtual machines had the agent enabled, so for most people this path is already available and simply unknown.

When the guest is off

With the guest stopped, its disk image can be mounted on the host and its filesystem browsed directly. This is the most powerful option: full access, any size, no agent needed.

It also has the sharpest edge in this article.

The shortcut that quietly destroys things

Do not mount a running guest's filesystem from the host.

It often appears to work. You mount the image, you see files, you copy one in, nothing complains. Meanwhile the guest also has that filesystem mounted and is caching its own idea of what is on disk. Two independent writers, one filesystem, neither aware of the other. The result is corruption that shows up later, looking like a disk problem rather than like something you did.

If the guest is running, use the network or the agent. If you need the disk, stop the guest first.

When the guest will not boot at all

This is the moment you most want a file out, and the previous options have all failed.

Take the route through a backup. Backups can be inspected and individual files retrieved from them without restoring the whole guest. It is slower than everything else here, and it is the only path that still works when the machine itself is unusable.

Worth noticing: this is another reason a backup you have never opened is not yet a backup. The day you need a single file out of a dead machine is a bad day to discover the archive does not restore.

Containers are a different problem

A container does not have a disk image with an opaque filesystem inside. Its files sit on the host's own storage, so from the host they are simply there.

That asymmetry is why the container version of this question is its own separate search. Same task, completely different difficulty, and advice written for one is often wrong for the other.

What Atlas does, and its limits

Atlas offers a file browser for a guest, and the design choice inside it is the part worth stating.

It runs inside the guest and listens only on the guest's own loopback address, so it is not reachable from your network at all. You reach it through Atlas. That means adding a file browser does not add a service exposed to anything else on the LAN, which is the usual quiet cost of putting a web file manager on a machine.

The limits, plainly: it is per guest and has to be present in the guest you want to browse; it is a convenience for looking and moving individual files, not a transfer mechanism for large data; and it does not replace backups. For bulk data the network path above is still the right answer, and for a machine that will not boot, the backup route is still the only one.