Classic confinment request for rclone-ui

store-requests classic-confinement
1

To make the review of your request easier, please use the following template to provide all the required details and also include any other information that may be relevant.

I understand that strict confinement is generally preferred over classic.

I’ve tried the existing interfaces to make the snap to work under strict confinement.

Note that snappy-debug can be used to identify possible required interfaces. See docs/debug-snaps for more information.

Hello, I am the creator of Rclone UI and a member of the main/upstream rclone Github org.

I’m requesting classic confinement access to publish the rclone-ui snap.

We have tried sandboxing in the flatpak version but we get many issues due to it and have introduced a message to have the user give full host access in order to operate as expected. This isn’t the best solution, especially for non-techies who expect the app to “just work”.

Reasoning

Rclone UI is a frontend for the rclone CLI tool. It needs classic confinement for two reasons that cannot be satisfied by plugs:

1. Executing the user’s rclone binary

The app locates and executes the user’s existing rclone installation. rclone can be installed in many locations depending on how the user set it up:

  • /usr/bin/rclone (apt/package manager)

  • /snap/bin/rclone (snap)

  • ~/.local/bin/rclone (manual install)

  • /usr/local/bin/rclone (rclone’s own installer script)

  • Any custom $PATH location

There is no single plug that grants execute access to arbitrary binaries across the filesystem. The personal-files and system-files plugs could cover known paths, but they don’t handle custom installations, and requiring users to reconfigure after installing rclone differently would be a poor experience.

2. Arbitrary filesystem paths access

rclone operates on any directory the user chooses — local backup sources, mount points, external drives, network shares, and paths outside $HOME (e.g. /mnt/data, /media/user/drive). The home and removable-media plugs cover common cases, but far from all valid rclone source/destination paths. Commands like core/disks (or simply listing folders/disks without having the user select them through a native dialog beforhand) would give faulty or incomplete results.

As the core purpose is browsing and moving files between arbitrary locations, restricting filesystem access would fundamentally limit the app’s functionality and what users expect from it.

Alternatives considered

  • Bundling rclone inside the snap: This would solve binary access but not filesystem access. It would also prevent users from using their existing rclone configuration and version, and would require us to keep the bundled version in sync.

  • Strict with personal-files/system-files: Would require enumerating every possible rclone install path and still wouldn’t cover custom locations.

  • Strict with home + removable-media: Covers ~75% of use cases but breaks for users with data on non-standard mount points, which is common for the rclone user base (NAS mounts, custom partitions, etc.).

2

Hey @rclone-ui

I think same reasoning as for Classic confinment request for rclone-manager applies here

3

Thanks for the clarification.

I understand why strict confinement is preferred, and I also understand the concern around granting classic confinement for apps intended for a broad audience.

That said, I respectfully think the suggested strict-confinement approach would make rclone-ui significantly harder to maintain and would result in a worse product for users. The issue is not only whether individual cases can be worked around with specific interfaces or by asking users to move paths under ~/snap/...; it is that rclone-ui is meant to be a frontend for an existing rclone setup, including user-selected binaries, custom mount points, external filesystems, NAS paths, and workflows that may already exist outside the snap environment.

Supporting those cases under strict confinement would require a growing set of snap-specific assumptions and workarounds. Over time, that would turn the app into a collection of special cases rather than a clean upstream GUI for rclone, and it would be difficult to maintain properly.

Rclone UI comes from a verifiable source, and Snap publishing has been a real request from a vast user base.

I appreciate that the current guidelines exist for good reasons. My concern is that this may be a case where the guidelines do not map cleanly to the application’s actual purpose. If classic confinement is not considered appropriate under the current categories, could this be considered for senior review?

Cheers!