Make Rclone more user friendly with a little effort

Feature
1

What problem are you are trying to solve?

Rclone is one of the most complex applications I have used on Linux during my seven-year journey. I was only able to get it working after two unsuccessful attempts because I did not have enough time to read all of the documentation required to mount a Google Drive.

As a Product Owner and UX designer, I see that users:

  1. Are often unaware that the Rclone Web GUI exists.
  2. Become frustrated when trying to configure mounts that start automatically at system startup.

This negatively affects user adoption, reduces engagement from the developer community, and results in weaker support from Linux distributions. Consequently, allocating resources to further Web GUI development may appear difficult to justify.

That said, perhaps the current approach is intended to encourage the use of third-party GUI solutions. However, I have not found any GUI that I would consider trustworthy enough to recommend.

How do you think Rclone should be changed to address these issues?

  1. Start the Web GUI automatically after installation.
  2. During the first launch, ask whether the user wants Rclone mounts to start automatically at login, similar to the approach described here: Systemd rclone mount · rclone/rclone Wiki · GitHub
  3. Create a desktop or application menu shortcut that launches the Web GUI.
  4. Save all user-created mounts under http://127.0.0.1:34397/mounts and provide a way to delete them. Templates for Google Drive, Dropbox, and S3 would be helpful, although not essential.
  5. Remove all of the above integrations when Rclone is uninstalled.

In short, this is not about creating something entirely new. Most of the required pieces already exist; the main challenge is bringing them together into a more cohesive user experience.

2

Hey, I’m the creator and maintainer of both the integrated WebUI and the separate native UI.

This is great feedback, and I appreciate you taking the time to write it out. Some of these requests can sound simple on the surface, but they often have more moving parts than expected. For example, rclone does not really have an uninstaller in the traditional sense. It is a self-contained binary, so it does not have the same install/uninstall flow as a typical Windows application.

If you have used Rclone UI, the native UI, and ran into issues, you have probably seen some of the complexity that comes with adding more functionality. That said, none of this is set in stone. Things are always evolving, and my goal, along with Nick and the rest of the team, is to provide the best experience possible for different kinds of users: veterans, beginners, older systems, unusual distros, macOS users, and everything in between.

To clarify the current approach: the integrated WebUI is intended to stay lightweight. It is an under-1MB web GUI bundled with rclone, but rclone is first and foremost a CLI tool. The WebUI is a useful bonus feature, not the main product. Many users, integrators, and scripters do not need a UI at all.

For users who want a richer graphical experience, the native UI, Rclone UI, is the better place for that. It can move faster, experiment more freely, and support features that would not necessarily make sense inside the core rclone binary.

This separation is useful because the CLI needs to remain stable, robust, and predictable, while the native UI can grow independently. Compared to many other CLI tools, rclone is already quite large, and it keeps growing. Feature creep and prioritization is something you're surely familiar with. For some environments and use cases, binary size matters a lot, so adding more features is not always an obvious win.

So the short version is: the feedback is valid, and I do understand where it is coming from. I can assure you that this won't fall on deaf ears because it's something I have discussed with Nick. As mentioned, there are more moving pieces and things to take into account than "extra feature = win"

The goal right now is to have a stable and bug-free WebUI, and a native UI that is good for 99% of people (both in terms of stability and also feature-wise).

Templates

This is an effort I've started a few months ago, you can see them right here: Templates | Rclone UI

They see decent usage (# of imports) without any forum thread or announcement. I get almost no submissions but that's to be expected.

I'd like to hear your feedback on those, maybe even add some new ones!

Just adding a provider (eg. Google) is usually not sufficient to have a useful template, and a lot of the flags deepend on the current system configuration, and the purpose of running the current operation.

These already deep-link to rclone:// for a future native integration, as well as compatibility with other third party clients.

4

Hi there!

I've used .deb to install it, and 'apt remove rclone'. So, it's not completely true.

I am not sure why ordinary users would choose rclone on Windows when native applications already exist and are highly tested and optimized. However, I am sure that businesses make extensive use of the rclone binary on Windows.

As a developer, I would be happy to spend a couple of days implementing features. As a user, however, I have accumulated a fair amount of frustration with the overall user experience.

Let's look at some real-world examples. FFmpeg is considered one of the most complex tools in existence. Yet I can simply type ffmpeg -i input.mp4 output.mkv and get what I need. The developers have invested considerable effort into sensible defaults and user-friendly behavior, so users are not forced to specify every possible option:

ffmpeg -hwaccel cuda -i input.mkv
-c h264_nvenc -preset p7 -tune hq -profile high
-rc vbr -cq 20 -b 8M -maxrate 10M -bufsize 15M
-c aac -b 320k -ac 2 -ar 48000
-map 0:v:0 -map 0:a:0
-y output.mp4

I submitted a ticket requesting more graceful error handling in FFmpeg. Although the underlying implementation changed, the issue was addressed in a later release. They listen to feedback from both their community and the businesses that rely on the project, including companies such as YouTube and Netflix.

Of course, rclone does not have as many contributors as FFmpeg. But does it really care?

Do those users rsync every file instead of File Explorer? Or is it business, not users?

Why is it not used by any Linux distribution? Why does Gnome removed Google Drive completely instead of using rclone?

Let me guess, is it for business use cases?

To summarize, nobody thinks about an Open Source community here, so Open Source community does not think about rclone.

5

I would like to clarify my main point. There is a threshold at which the time required for configuration outweighs the benefits of the features, and for private tasks that threshold can be quite low.

Let's pretend, for a moment, that the experience of ordinary users is a priority here.

A common UX principle is that users should be able to achieve a result before investing significant time in documentation. Requiring extensive manual setup before mounting a Google Drive is a critical barrier to adoption, meanwhile the most of the necessary building blocks already exist.

The most comprehensive solution would likely be to implement saved mounts and templates directly in rclone. However, the Web GUI already appears capable of handling much of the required functionality today, including saving and editing mount configurations. This could provide a practical intermediate solution with relatively modest development effort, while leaving room for a more integrated Go implementation in the future.

From my perspective, the most effective path to break the UX barrier appears to be:

App shortcut → Save mounts → Mount at startup

Needless to say, my objective is not to impose my opinion or dictate the project's direction. I simply see an opportunity for the project to become an industry-standard tool for data transfer, much as FFmpeg, together with VLC, has become a standard solution for media playback and conversion.

I am only sharing my vision for what the project could become. However, my community-focused perspective appears to be somewhat out of place here.

6

Reading your message has made me less inclined to contribute to the project. Seems like you have a problem for every solution.

At my current project we are implementing a macroblock parser for H.264/H.265 streams, including CAVLC and CABAC entropy decoders. When I read that scripting is considered "low-level plumbing", I cannot help but smile.

Regarding the technical points:

  1. All Linux distributions I am aware of use the same standard locations for desktop entries: /usr/share/applications system-wide and ~/.local/share/applications per user. A simple rclone.desktop file launching rclone gui is straightforward to package. Adding one more variable or file to an existing .deb or .rpm package is not a technical obstacle; it is a product decision.
  2. Almost all mainstream Linux distributions use systemd today. Only one flag and a configuration entry are needed to implement a mount-on-startup feature, along with optional status information. This also seems like a product decision.
  3. I do not care about Windows in this discussion. Windows already has native applications for most mainstream cloud providers. Linux users are in a different position: there is no universally accepted GUI for mounting network drives, Google Drive support removed or buggy, and Proton Drive's Linux offering is not here yet.

I am not insisting on any particular change. My point is that the current market situation creates an opportunity for rclone. There is a window, perhaps 6–12 months, during which it could grow among Linux users before competing solutions mature.

If that opportunity is intentionally ignored, that is entirely the maintainer's prerogative. However, in that case I would not expect the status quo around rclone adoption to change significantly.

7

please understand, i was the only member to welcome to the forum.
you have taken my comments out of context, making this personal and making over the top criticisms of this entire forum.

no worries, i will delete that post, drop off this topic.
good luck, good bye, good life

1 Like
8

I think we're both on the side of wanting more features in rclone, full stop.

Just explaining the broader implications and current gameplan, which isn't set in stone, and changes based on feedback like yours.

rclone is the industry standard in data transfer if you do a census, it's even a default install in some Linux distros.

I think, for some reason, that you're taking everything said here as being against what you're saying, when in fact it isn't the case. I'm fairly certain that it has been noted and is taken into account. Will you see a tappable shortcut or anything else tomorrow or next week? Definitely not, I hope that's understandable. The "6-12 months" period is always there.

The bigger the project, the more careful it has to be about pretty much everything, otherwise you get into this situation from hundreds/thousands of unverified lines and features:

I'm a weekly ffmpeg user myself, but if people start recommending to always run it in a sandbox, that ain't helping the growth. Node was also the king before Bun came, and now they got their act together. Same could happen to ffmpeg (but the second part isn't guaranteed).

I am not sure why ordinary users would choose rclone on Windows when native applications already exist and are highly tested and optimized. However, I am sure that businesses make extensive use of the rclone binary on Windows.

Specifically because it is based on the rclone binary. Those other tools aren't.

I think you're very opinionated which is usually a plus in my book :smiley:

If you're open, I'd like to share with you the next major version of RCUI (v4) and integrate your feedback!

9

I had no idea rclone had a gui. I looked, launched it, found it to be fantastic. What a great way to easily browse the status of each setup cloud destination. My main use is scripted overnight backups. (using Gentoo Linux)

10

Oh yeah, here we go. :laughing:

You mean yourself, correct?

Nothing of that is true.

But, why?

You can create an installation script if you want. Nobody is preventing you from doing that.

Again, nobody is preventing you from doing that yourself for your specific distribution.

I save my user-created mounts the way i like. And you can do the same.
You just need to learn to read documentation i guess.
Same goes for those "templates".

Just delete the files and its gone.
And if you have made an individual installation script for your usecase (see above), then also go write a deinstallation script for your usecase.

It's already perfect as it is.
If you think it's not, make a fork and when it's so much better people will start using your fork, but i doubt that.

What the heck are you talking about sir? What market situation? This is not a for-profit company.
And also nothing will replace rclone in 6-12 months. Where are you getting this BS from?
I really get very big vibecoder-vibes here and i find such posts actually subliminally insulting.

If you aren't able or even willing to put enough work into it by reading the documentation, i really don't think that you would be from any help here. :rofl:

1 Like
11

same :face_with_hand_over_mouth:

or "went", it seems. lol.

yeah i think rclone is doing finer than fine. considering it manages tens of millions of files at our organization, i have no doubt it's trillions of files globally.

i think the rclone forum is also doing fine.

2 Likes
12

I think your framing is pretty accurate — the core issue isn’t capability, it’s discoverability and workflow cohesion.

Rclone is powerful precisely because it’s very modular and explicit, but that also means it exposes a lot of low-level concepts to the user. For experienced Linux users that’s fine, but for most people the gap between “install tool” and “usable workflow” is still too wide.

The Web GUI point is especially interesting. Even when it exists, it feels like a separate component rather than the primary entry point, so users naturally miss it. In UX terms, it’s not just about having a GUI, but about making that GUI the default mental model of the tool.

I also agree that startup and persistence are where most friction happens. Mounts, credentials, and systemd integration are powerful, but they require the user to already understand the execution model before they can benefit from it — which is often the opposite order from how people actually learn a tool.