Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Feature Request: Comprehensive RC API Improvements for Headless & Wrapper Use Cases #9120

@Hakanbaban53

Description

@Hakanbaban53

The associated forum post URL from https://forum.rclone.org

https://forum.rclone.org/t/rc-api-vfs-stats-fails-with-more-than-one-vfs-active-for-multiple-mounts-but-rejects-unique-suffixes-from-vfs-list/53081/3

What is your current rclone version (output from rclone version)?

Latest stable (I always checking via selfupdate)

What problem are you are trying to solve?

I am a hobby UI developer working on a cross-platform GUI wrapper for Rclone. I have encountered several critical limitations in the Remote Control (RC) API that make it difficult to manage Rclone instances robustly, especially when handling encrypted configurations, multiple mounts, or automated setups.

Current limitations force wrappers to rely on brittle workarounds (like parsing stdout/stderr or managing separate processes) instead of a clean API integration.

How do you think rclone should be changed to solve that?

Here is a consolidated list of limitations and proposed improvements to the RC API:

1. Path Configuration vs. Cache/Temp Paths

  • Limitation: config/setpath only accepts path (for the config file) and rejects cache or temp. One must use options/set to change CacheDir, but config/paths continues to report the old path (locked at startup), creating a disconnect between the API report and actual state.
  • Proposal: Update config/setpath to accept cache and temp. Ensure that changes trigger a dynamic reload of these paths internally so config/paths reports the correct active paths immediately.

2. Encrypted Configuration Safely Detection

  • Limitation: config/get returns the config if unlocked, but fails/hangs if locked. There is no safe, non-blocking way to just check if the config is encrypted/locked without potentially hanging the process on an interactive prompt (if not suppressed).
  • Proposal: Add a config/status endpoint that returns metadata:
    { "encrypted": true, "locked": true, "path": "/..." }
    This allows clients to check status safely before deciding to prompt the user for a password.

3. Passive Password Prompt Blocking (Deadlock)

  • Limitation: If an encrypted config is locked and an RC command tries to access it, Rclone halts and waits for input on stdin. This freezes the entire RC server.
    • Using --ask-password=false is not a viable workaround because it causes a CRITICAL failure at startup (CRITICAL: Failed to load config file ...: unable to decrypt configuration and not allowed to ask for password), crashing the process or preventing the RC server from even starting to receive config/unlock.
  • Proposal: When running with --rc:
    1. Default to non-interactive mode for config passwords.
    2. Fail fast instead of crashing: Return a specific API error (e.g., 401 ConfigLocked) if the config cannot be loaded, but keep the RC server running so config/unlock can be called.

4. Configuration Encryption Management via RC

  • Limitation: No endpoints exist to encrypt an existing plain config, decrypt an encrypted one, or change the password.
  • Proposal: Add endpoints:
    • config/encrypt (args: password)
    • config/decrypt (args: password)
    • config/changepassword

5. Importing Remote Configurations

  • Limitation: Cannot "import" a full JSON configuration object (from config/get dump) into another instance easily. OAuth remotes (OneDrive, iCloud, etc.) are complex to reconstruct via atomic config/create calls without re-triggering auth flows.
  • Proposal:
    • Add a raw or blob parameter to config/create to accept a full JSON dump.
    • Or add config/import to merge a standard config section or JSON object directly.

6. Process Restart Capability

  • Limitation: core/quit exists, but there is no core/restart.
  • Proposal: Add core/restart to gracefully shut down and respawn the Rclone process with the exact same initial arguments. This is essential for applying setting changes that require a reboot (like mount flags or environment variables).

7. Multiple VFS Instance Addressing

  • Limitation: When multiple mounts exists for the same remote, vfs/list shows unique IDs (e.g., remote:[0], remote:[1]). However, commands like vfs/stats, vfs/refresh, vfs/forget often reject these suffixed names and ambiguous requests fail.
  • Proposal: Standardize VFS answering. All vfs/* commands should accept the unique IDs returned by vfs/list to target specific mount instances reliably.

8. Self Update via RC

  • Limitation: There is no command in RC to update the remote rclone instance (equivalent to rclone selfupdate). This prevents managing the rclone version of remote or headless instances via the API.
  • Proposal: Add core/selfupdate (or similar) endpoint to trigger a self-update operation on the running instance. After update, the instance should restart automatically with the same arguments.

How to use GitHub

  • Please use the 👍 reaction to show that you are affected by the same issue.
  • Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
  • Subscribe to receive notifications on status change and new comments.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions