Transfer files

Copy files to and from a device over the platform connection.

You can copy files to and from a device through the platform, over the outbound connection the device already keeps open. Nothing listens on the device for this, so file transfer works on devices behind NAT or a restrictive firewall, exactly like a remote shell does.

Both the dashboard and the cuttle command-line tool use the same transfer service on the device, so it does not matter which one you use.

Before you copy files onto a device

A device’s system image is read-only, and anything you write outside the persistent areas is gone after the next reboot. Choose the destination accordingly:

Destination	Use for
`/isodevice/config`	Files that configure the device, such as boot and shutdown hooks. Survives reboots and OS upgrades.
`/isodevice/data`	Payload a workload reads or writes. Survives reboots and OS upgrades.
Anywhere else	Short-lived files only — a script you are about to run, or data you are about to collect.

See how persistence works for the full storage model.

From the dashboard

Open the device’s Device overview page and click the vertical triple dots next to the page title.

Upload files — enter the destination directory in Path on device, then select or drag in one or more files. The files keep their own names under that directory.
Download file — enter the full path of a single file in Path on device. The file downloads through your browser when the transfer completes.

Both actions need the connect to device permission (services/proxies.edgelq.com/permissions/projects.connect), the same permission that governs the remote terminal.

Uploaded files are not executable

Files uploaded from the dashboard land with 0644 permissions. A script you intend to run — a boot or shutdown hook, say, which is skipped silently unless it is executable — needs chmod +x afterwards. The command line keeps the local file’s mode instead.

From the command line

cuttle devices scp takes the same two arguments as ordinary scp, with the device side written as <device-name>:<path>. Whichever argument carries the device name decides the direction — you cannot copy between two devices.

Upload a file:

cuttle devices scp ./hook.sh \
  projects/your-project/regions/us-west2/devices/pi03:/isodevice/config/hooks/

Download a file:

cuttle devices scp \
  projects/your-project/regions/us-west2/devices/pi03:/isodevice/data/report.csv \
  ./report.csv

Add -r to transfer a whole directory, and -v to print per-file progress:

cuttle devices scp -r -v ./bundle \
  projects/your-project/regions/us-west2/devices/pi03:/isodevice/data/

How paths are interpreted

On upload, a trailing slash on the remote path means “into this directory”:

…:/isodevice/data/ keeps the local file name.
…:/isodevice/data/report.csv renames the file on the device.
With -r, a trailing slash creates the local directory itself on the device; without one, only its contents are copied into the remote path.

The remote path of an upload must be absolute — it has to begin with /.

On download, what matters is whether the local path already exists as a directory:

If it does, the file is written into it under its remote name.
If it does not, the local path is used as the output file name.
With -r, an existing local directory receives the remote directory beneath it; a local path that does not exist yet is created and becomes the root of the downloaded tree.

Not available on Windows

cuttle devices scp and cuttle devices collect-debug-bundle are not built for Windows. Use the dashboard to transfer files from a Windows machine. See the command restrictions in Operating with the cuttle CLI.

Collecting files for support

To gather the logs and system state an investigation usually needs, use cuttle devices collect-debug-bundle rather than copying files one at a time.

Remote access — administering a device without inbound ports.
Boot & shutdown hooks — the most common reason to upload a file.
Storage — what lives where on the device’s disk.