Skip to content

# Standalone daemon (mtp-mountd): auto-mount MTP devices on hotplug, for every app #17

Description

@LinuxBoy-96

TL;DR: mtp-mount's FUSE layer already makes cp/rsync/everything work over MTP. Proposal: split the mount logic into a library crate, and add a small daemon binary that auto-mounts devices on hotplug. Result: working MTP for the entire Linux desktop, no glib, no gvfs.

Why

gvfs is how desktops do MTP today, and its FUSE layer refuses plain writes:

POSIX write:        open() → write() → write() → close()
                     └ size unknown here
MTP protocol:       SendObjectInfo(size) → SendObject
                     └ size REQUIRED here
gvfs FUSE answer:   EOPNOTSUPP
mtp-mount answer:   spool locally, upload on close()  ✅

Users hit this constantly (cp: operation not supported threads go back 20 years; COSMIC alone has a dozen open issues on it — cross-ref: https://github.com/pop-os/cosmic-files/issues/1926 mtp-mount already has the right answer. It's just manual and single-device today.

What

Two crates in this workspace:

mtp-mount-core — the existing mount logic (inodes, sparse read cache, write spool, safe overwrites) extracted as a library. The current CLI becomes a thin consumer; its UX doesn't change.

mtp-mountd — a small systemd --user service on top:

  1. Watch USB hotplug (nusb has this). Device appears → mount at $XDG_RUNTIME_DIR/mtp/<serial>/. Device unplugged → clean unmount.
  2. One session + one mount per device, concurrently.
  3. Announce mounts so desktops can show the device. v1 can be just the predictable directory (inotify-watchable) — near zero new code. D-Bus can come later.
  4. Ship the unit file, log to journal.

Steps 1–2 are extensions of existing code. Step 3 v1 is almost free. The real new work is the crate split and service hardening.

Open questions

  • Announcements v1: directory-only, socket, or D-Bus?
  • Devices with multiple storages: one mount each, or subdirs under one mount?
  • gvfs running on the same machine: document masking gvfs-mtp-volume-monitor, or detect-and-warn?

Who benefits

Every app that opens files: file managers (COSMIC is a good candidate— see cross-ref), rsync, editors, previewers, terminals. Any desktop, any distro.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions