Feedback from a multi-Shared-Drive setup: 7 topics – which of these are welcome as issues?

[rorar]

Hi, and thanks for RClone Manager; it has been my daily driver for a while.

I recently set up Google Drive with My Drive plus eight Shared Drives under a
single mount, using rclone alias remotes and a combine on top. It works
well, but I hit a number of rough edges along the way.
Together with Claude Code (Opus 5) I looked into each one in the source before writing this, so the notes below point at concrete code rather than guesses.

Rather than opening seven issues at once, I'd like to ask first: which of
these are you interested in, and in what form? Some are clearly features,
some are small, some you may have deliberately decided against. I'm happy to
write up whichever ones you want, and to drop the rest.

Grouped by what they touch:

---

A. Shared Drives (2 topics, related)

There is currently no path through the UI to reach a Shared Drive. drive is
not in INTERACTIVE_REMOTES (src/app/shared/types/remote-config.ts), so
there's no wizard step, and the docs don't mention Shared Drives on any page.

The layout users already expect. Google's own clients put everything under
one root. Drive on the web lists My Drive and Shared drives side by side in
a single sidebar, and Google Drive for Desktop creates one Google Drive folder
which, per Google's own documentation, is where "you will find My Drive,
Shared drives, and other synced folders". Someone with eight Shared Drives
gets one entry point there, not nine.

That is the arrangement I rebuilt with alias + combine, and I'd suggest it
as the recommended default rather than one option among equals — everything
downstream follows from it: one path to bookmark, one tree for the file manager
and for desktop search to walk, one root for scripts and backup jobs, and no
per-drive mountpoint to keep track of. Separate mounts are still worth offering
for people who want exactly one Shared Drive and nothing else, but they
shouldn't be the only route.

One detail where Google's layout differs from mine and is probably better:
the shared drives sit one level deeper, grouped under a single Shared drives
folder, instead of flat beside My Drive. That keeps the root stable when
drives are added or removed.

What would help in the app: detecting the available drives after OAuth and
offering the mount layout as a choice. A UI that shows Shared Drives as
belonging to their parent account, rather than as unrelated sidebar entries,
would make a big difference once several exist.

Technically this needs no new rclone capability: the backend/command RC
endpoint with command=drives returns the list, and rclone backend drives -o config <remote>: even emits ready-made alias sections.

One caution if you do pick this up. team_drive carries Hide: 2
(OptionHideConfigurator) in rclone's provider metadata, and RClone Manager
currently ignores the Hide field entirely — it appears in
remote-config.ts but is never used for filtering. That "bug" is the only
reason the field is reachable today, and thus the only way to configure a
Shared Drive at all. It would be worth not honouring Hide until a proper
picker exists, otherwise the capability disappears.

Possibly related to #262, which is also about the Drive config form.

---

B. Preset system (2 topics, one code path)

Two things surprised me here:

• Presets are applied only when a remote is created through the app. Remotes
  added by editing rclone.conf get no VFS profile at all, so they silently run
  on rclone defaults. An "apply recommended presets" action on an existing
  remote would fix this.
• REMOTE_FAMILY_MAP in src/app/services/remote/remote-presets.ts covers
  s3, b2, gcs, googlecloudstorage, webdav; wrapper backends (combine,
  alias, union, crypt) don't appear anywhere in the file, so they fall
  through to BASE_PRESET. That preset sets Refresh: true, which for a
  combine means one recursive directory crawl per upstream on every mount
  start — nine in my case. rclone's own default for --vfs-refresh is off.

These two would probably be one issue, since they're the same code.

---

C. Mount robustness (3 topics, independent)

• Unmount failures give no next step. Device or resource busy is passed
  through raw. In my case a file manager held the mountpoint; fuser -vm found
  it in a second. Naming the blocking process, or offering a lazy unmount,
  would turn a dead end into a click. The Linux troubleshooting page currently
  covers Flatpak cases only.
• A dead mount is still reported as active. After a VFS teardown, the
  mountpoint remained in mount/listmounts and stayed green in the UI, while
  any access returned an I/O error. I couldn't find a liveness check anywhere.
• No warning on mountpoint collisions. Two remotes can be configured with
  the same mountpoint and both set to autostart. Since --allow-non-empty
  defaults to false, the second one just fails. I did this to myself during the
  migration.

---

D. Config handling (2 topics)

• Reloading rclone.conf after editing it externally. The remote list comes
  from get_cached_remotes, and the cache refreshes on init, engine start, and
  REMOTE_CACHE_CHANGED — which only fires for changes made through the app.
  The file watcher covers mounts and serves but not the config file. The
  working route today is About → Backend Cache: Clear, then Kill Process, which
  is hard to find and reads as more drastic than it is. Either a watcher on
  rclone.conf or a plain "reload config" entry in the menu would do it.
• Requiring system authentication before exporting a backup. Today an
  export is a single click, and the resulting archive is among the most
  sensitive artifacts the app produces. Confirming it through the OS
  authentication prompt would raise the bar for anyone with brief access to an
  unlocked session, and it makes the weight of the action visible at the moment
  it's taken. The app already uses the system keychain for master passwords, so
  the building block is in place. (I've reported a related finding through
  private vulnerability reporting rather than here.)

---

Documentation

Separately from the above: Shared Drives and rclone's wrapper backends
(combine, alias, union, crypt) aren't covered anywhere in the docs.

---

For reference: how I'd file these

So you can answer with numbers instead of prose, here is what each would look
like as an issue:

#	Working title	Group
1	[Feature]: Shared Drive support in Add Remote (detection, mount layout, tree view)	A
2	[Feature]: Document Shared Drives and wrapper backends	A
3	[Feature]: Presets for existing remotes and for wrapper backends	B
4	[Feature]: Actionable guidance when unmount fails with EBUSY	C
5	[Bug]: Mount reported as active after its VFS has died	C
6	[Feature]: Warn when two remotes share the same mount point	C
7	[Feature]: Reload rclone.conf without restarting the app	D
8	[Feature]: Require system authentication before exporting backups	D

Items 1 and 2 are worth keeping separate: the documentation page is something
another contributor could pick up independently. Item 3 merges the two preset
observations because they share a code path. Items 4–6 are unrelated to each
other despite sitting in the same group.

---

So; which of these would you like as issues? I'd rather send three that you
want than eight that you don't. And if any of them are already on your roadmap
or were decided against, just say so and I'll leave them alone.

Thanks for your work on this.

---

_{Researched and written together with Claude Code (Opus 5). Every code
reference above was verified against current main rather than inferred —
happy to share the exact commands used.}

[Hakanbaban53]

7 is bug and fixed on flow branch.

[rorar]

Cool, thanks! :)
Would it be okay for you to post 1-6 and 8?

[Hakanbaban53]

8 is actually a design choice combined with some misunderstanding on my part. When I said "Include Secret keys," I meant the app-related secrets, like the Rclone config password or remote connection passwords, etc. not the actual secret keys of rclone. That distinction wasn't clear, and I need to fix it.

[rorar]

Thanks you for taking care.
How about the other points? :)

[Hakanbaban53]

Honestly, every idea written under the Zarestia Dev repos has stuck in my brain. I can’t always tell when or where I’ll be able to implement them, but whenever I find a good place for a feature, I add it.

So I definitely haven’t skipped any of the ideas you’ve made, the only problem is that it sometimes takes a while to figure out where they fit best and how they can be most useful to users.

[Hakanbaban53]

Most of the UI and other things are actually based on user ideas, Reddit responses, or things I’ve come across in other repos. I try to keep those ideas in mind and eventually find the right place for them in the projects.