RClone-manager as a "detached" manager

[bstordrup]

First of all - amazing application.

I had configured GoogleDrive automatically and started it via a crontab at boot. Works perfectly in the background. I then used RClone-manager to set up the same GoogleDrive connection on a different mountpoint - could reuse the already found configuration.

But what I miss is that I can exit RClone-manager and still have the GoogleDrive mounted.

In order to keep the GoogleDrive mounted after exiting RClone-manager would require (OTOMH)

• Adding a setting for whether full persisted mount should be used.
• Exporting a crontab job to the users crontab that makes the mount after boot
  • crontab -l 2>/dev/null; echo "@reboot rclone mount GoogleDrive: ~/<MountPoint> <params> --daemon"
• Running the first time mount command with the --deamon parameter in a spawned job so it will keep living after RClone-manager exits
• Finding a way to find the already mounted connections at application launch.
  • Could be a stored setting in configuration (settings.json)
  • Looking for running rclone instances and finding connection information.

Now, the ball has been thrown - feel free to comment.

Best regards,

Benny

[Hakanbaban53]

Hi Benny,

First of all, thank you so much for your kind words and amazing feedback! I'm really glad to hear that you like the application.

To explain the logic behind the app: it relies heavily on Rclone RC (Remote Control). Instead of using the standard CLI, it spins up an HTTP endpoint to manage Rclone remotely. Since Rclone provides its outputs in JSON format, it makes managing everything much cleaner.

Regarding your suggestions, I've actually tested the --daemon parameter before, but unfortunately, Rclone RC does not support it.

Currently, when the app exits, this endpoint is terminated as well. I did consider leaving the endpoint alive and reconnecting to it later, but I am introducing a critical security update in the upcoming release. If a user doesn't provide a custom username and password for the RC endpoint, the app will generate a random, in-memory username and password. This means once the app closes, those temporary credentials are lost, making it unfeasible to keep the endpoint running.

This brings me to a question: Is keeping the application running in the background a problem for your workflow?

I completely understand the concern regarding resource consumption, especially with Tauri-based apps, where the foreground Web UI can be heavy. However, I've added a Memory Optimization setting to address this. It is now set to true by default, meaning that as soon as the Web UI is closed and the app minimizes to the tray, the vast majority of resources are freed up.

I'd love to hear your thoughts on this! Thanks again for your valuable feedback.

Best regards,

[bstordrup]

Hi Hakan

A small follow up question. What is the difference between the rclone being installed with the application and the rclone being installed from the distro package management (residing in /usr/bin/rclone).

Having the application running in the background is not a major problem for my workflow - it's merely a bit annoying to have yet an application running in the background (I also have a MEGA and a NextCloud manager running). The --deamon approach would just launch the rclone in the background and run silently.

Could it be something to consider as an Advanced feature?

[Hakanbaban53]

Hi Benny,

To answer your follow-up questions:

1. Distro Rclone vs. Application Rclone

Functionally, there is no difference between them. When the app manages rclone, it pulls the official binary directly from the Rclone GitHub Releases and places it into the application’s local directory: ~/.local/share/com.rclone.manager.

The main reason the app handles its own binary instead of modifying your system-wide installation (/usr/bin/rclone) is to avoid conflicting with your distribution's package manager (pacman, dnf, apt, etc.). When you check for updates through the app, it verifies which binary you are currently using and checks for read/write permissions. If the active binary is in a system root directory where the app cannot write, it will simply install the new version into the local path mentioned above.

---

2. The Daemon Toggle as an Advanced Feature

That makes complete sense! Having multiple cloud managers (like MEGA and NextCloud) running in the background can definitely clutter the system tray, so wanting a silent, detached background process is a totally fair point.

Actually, yes—I can do that. I can add a "Daemon" toggle for mounts, which will work specifically for local rclone instances. It is definitely a feature worth building. The only real challenge right now is determining how the app will reliably track and monitor that independent process once it's detached, but I will find a solid solution for it.

Thanks again for the excellent suggestion!