Skip to main content

File Manager

Inspect files, upload a file once, and synchronize the robot's storage.

nimbus file status
nimbus file sync
nimbus file upload-file /path/to/file

File status​

nimbus file status lists eligible local files and Nimbus Cloud Files, including cloud-only files waiting for download. Entries include destination, local/cloud presence, and available reasons or errors.

  • pending: waiting for local preparation or cloud download.
  • local: stored locally without confirmed cloud synchronization.
  • synced: last confirmed in the cloud, including downloaded or matched files.
  • uploading: an upload operation is active, including preparation and confirmation.
  • downloading: a cloud file is being downloaded; its local copy may not exist yet.
  • deleting: deletion is active or waiting for cloud confirmation.

Status can refresh cloud metadata without starting synchronization. The cloud inventory is fresh, stale, or unknown, with its last successful observation time. Cached stale information shows last-known presence; stale or unknown inventory cannot prove cloud absence. synced describes last confirmed content agreement, separately from presence. Completed AWS uploads disappear after local cleanup; RobotDisk data files can remain pending. Recordings, private files, and internal temporary files are excluded. Use nimbus record query-recordings for recording metadata. Notices explain incomplete scans or uncertain recording ownership.

Synchronization​

Both nimbus file sync and nimbus record sync run the same shared storage maintenance cycle: quota cleanup, recording metadata repair, a data-directory scan when connected, folder preparation, and managed Files synchronization. The data scan can queue recording uploads as well as process ordinary files.

With the SystemCloud recording provider, ordinary data files are adopted directly into resources. With AWS S3, they remain candidates for the configured S3 uploader. RobotDisk keeps data-directory files on disk. Managed Files synchronization is separate from that recording-provider setting.

Adding a file​

Use /var/lib/nimbus/files/resources/ as the writable Files folder. Paste completed files here, edit their contents, or delete them to synchronize those changes with Nimbus Cloud. Local Nimbus uploads and cloud downloads use the same folder. Identical contents share one resource, even under different filenames; edits that collide with another retained resource stay local with an error.

Sync accepts top-level regular files. Subfolders, symbolic links, and names ending in .tmp, .partial, or .lock are skipped. Copy with a .partial name, then rename when finished. Configured paths.NimbusHome and paths.NimbusData can change the default folder locations.

Content edits upload and confirm a replacement before retiring the previous cloud content. The cloud resource ID and download link can change; replacement is not atomic. Local pending edits are retained when the previous cloud copy is deleted.

Synchronization timing​

The manual cycle can wait one minute for data files to remain unchanged and another ten seconds for new or edited resources to remain unchanged. These waits do not include transfer time; files still being written may need a later cycle. Uploads and downloads require a working Backend connection. Recording and AWS uploads queued by the cycle may continue after either command returns. The commands report managed Files synchronization progress; their completion does not confirm every queued upload.

Automatic checks run every randomized two to five minutes, with additional checks on startup, authorization/reconnect, and resources-folder changes. This interval is not an upload completion deadline.

Managed Files synchronization can upload local files, download cloud files, and propagate deletions of previously synchronized files between the robot and the cloud.

One-off upload​

nimbus file upload-file /path/to/file uploads to the configured cloud destination and keeps the source. It does not add the file to managed Files storage. Managed Files paths are rejected; files outside the tracked folders do not gain a status entry or upload history.

Retention and troubleshooting​

Successful background recording and AWS data uploads normally remove the local payload. Managed synchronized Files stay locally and are excluded from recording cleanup. RobotDisk recordings remain subject to disk-space and recording quota cleanup, which can remove older unuploaded recordings even while offline. Either manual sync command includes quota cleanup.

Deleting a synchronized File through local Nimbus or the filesystem propagates to Backend. Deleting it in the cloud removes its unchanged local copy after successful reconciliation. An unavailable or incomplete local folder scan cannot establish deletion. A failed cloud listing postpones reconciliation and does not prove deletion. Keep a separate backup if needed.

If the resources folder or its mount becomes unavailable, recreating an empty folder does not resume inferred deletions. Restore the folder and retained files, then synchronize. Use Nimbus's explicit resource deletion for intentional removal of missing managed files.

If a file is stuck, check its reason/error, connection, destination, and free disk space. Adoption and download need room for the file plus a free-space reserve. Size, connection speed, and backlog affect transfer time; failed transfers retry in later cycles.