Skip to main content
Sometimes the thing you need is a file in a container: a log that isn’t on stdout, a heap dump, a config as the app really read it. Lumovi copies a file or a folder out of a running container, and puts one into a folder there, the way kubectl cp does: it runs tar in the container, and reads or writes its archive. Both are in a running pod’s actions: its ⋯ menu (.), the row’s right-click menu, or the command palette.

​
Download a file or a folder

1

Choose Download files…

Open a running pod, and choose Download files… from its actions.
2

Say what to copy

Pick the Container, and type the path of the File or folder in the container, like /var/log/app.log. A path that doesn’t start with / is read from the container’s working directory.
3

Choose Download

Once the container starts sending it, your system’s dialog asks where to save it, starting in your Downloads folder. When it’s done, the dialog says where it is, with Show in folder.
A download runs tar in the container and changes nothing there. The dialog shows the command that does the same:

​
Upload a file or a folder

1

Choose Upload files…

Open a running pod, and choose Upload files… from its actions.
2

Pick what to send

Pick the Container, then Choose a file… or Choose a folder…. The dialog says its name, how many files it holds and their size.
3

Say where it goes

Type the Folder in the container. It starts as /tmp. What you picked is put in that folder, under its own name. The folder must be there already.
4

Choose Upload

On a production cluster, type the pod’s name first.
Files in that folder with the same names are replaced, and there’s no undo: the container’s files aren’t Kubernetes objects, so Lumovi keeps no earlier copy.
The dialog shows the command that does the same:
Uploaded files get the time they were unpacked, as with kubectl cp. Where tar runs as root in the container, they belong to root.

​
While it copies

The dialog shows how much has moved, of how much when that’s known, and how many files.
  • Hide closes the dialog and the copy goes on. A toast says how it ended.
  • Stop ends it.
  • A copy stops by itself when nothing has moved for a minute. Choosing where to save doesn’t count: take as long as you like.
  • Closing the page, or quitting the desktop app, stops every copy.
A download that stops early, for any reason, leaves nothing behind: “The copy was stopped. Nothing of it was kept.” The desktop app writes under a temporary name beside where you’re saving, and gives the file or folder its name only once it’s whole. An upload that stops early can’t take back what the container has already unpacked: “The copy was stopped. What was sent before that may be in the container.” On a server, a download’s address works once, for 30 seconds, and only for whoever asked for it. If the copy ends before your browser fetches it, the address answers 404, as it does for anyone else, and afterwards. Where Lumovi runs as several replicas, a browser’s requests must stay with one of them for a copy to work.

​
What it needs

  • A running container. The actions show on running pods only, and the dialog lists the containers that are running, debug containers too.
  • tar in the container. Without it, the dialog says “container has no tar, which copying files needs, as kubectl cp does”, with a kubectl debug command to copy, which starts a container with tools beside it. From there, the container’s files are under /proc/1/root. Or choose Debug… in the pod’s actions: see Debug containers.
  • create on pods/exec in the namespace, as a shell needs. See Permissions.
Windows containers aren’t supported: they have no tar.

​
What’s kept of a download

A container can send any archive it likes, so Lumovi trusts none of it:
  • Only files and folders are kept. Links, symbolic or hard, are never written, so none can lead out of the folder you save. Devices and pipes aren’t either. The dialog says how many were left out.
  • Only what’s under the path you asked for. An entry with an absolute path, with .. in it, or under another name stops the copy, and nothing of it is kept.
  • Only ordinary permission bits. Read, write and execute are kept; the bits that make a file run as someone else aren’t.
  • Where it’s saved is yours to say, in the desktop app, never the archive’s. A folder is saved as a new one: Lumovi doesn’t unpack over a folder that’s there, and asks you to save it under another name.
  • On Windows, a file whose name Windows can’t use is left out, and counted.
If the path is itself a link, nothing is copied: give the path it leads to. A file that grows while it’s read, like a log, is copied as it was when the copy began, and the dialog says so. Folders you upload are treated the same way: links in them aren’t followed and aren’t sent, and the dialog says how many.

​
Who may copy

Where your access doesn’t allow it, the action is disabled and says why. In a fleet, copies go the way shells do, through the cluster’s agent where it has one, with nothing more granted to it.

​
How much one copy carries

One copy carries 2 GiB of files at most, and 100,000 files and folders. Past either, it stops; past the size, it says “That’s more than one copy carries here, which is 2 GiB.”, and what sets the limit. A download that’s stopped this way keeps nothing.
Your organization’s policy sets another limit, in bytes, or turns copying off:
Without a policy that sets it, the desktop app follows LUMOVI_FILE_COPY_MAX_BYTES in its environment, as a server does.
Where it’s off, the actions still show, and a copy is refused with “Copying files is turned off here.”, recorded as refused.

​
What’s recorded

The audit log has two entries for each copy, Downloaded files from a container or Uploaded files to a container: one when it begins, before anything moves, and one for how it ended, whether it finished, failed or was stopped. A copy that’s refused, by your access, by read-only or because copying is off, has one. Each says who, the pod, the container, the path, and the kubectl cp command that does the same. The ending adds how many files and bytes were copied, how long it took, and what was left out. It never records what was in the files, the names of files inside a folder, or anything the container said: when tar fails, the page shows you its words, and the log keeps a sentence of Lumovi’s own. See Events.

Shells and debug containers

A terminal in a running container, or a debug container with tools.

Logs

Every pod of a workload, merged in the order lines were written.