By Greg Nowak. Last updated 2026-09-06.
Getting photos, recordings or documents from an Android phone onto a Linux computer should be a routine job. When it fails, a simple handover can hold up a website update, client delivery or internal task.
Start with your desktop’s file manager. If you need a folder path for terminal tools, or the desktop connection fails, jmtpfs remains a useful fallback on distributions that package it. The workflow below covers both routes, including how to disconnect cleanly.
Start with the phone and cable
Before installing anything, check the connection:
- Unlock the phone and connect it with a USB cable that supports data transfer.
- Tap the phone’s USB notification and select File transfer. The wording varies between devices.
- Accept any file-access prompt shown on the phone.
- Open your Linux file manager and look for the phone in its sidebar or device list.
Google’s Android transfer instructions confirm the phone-side steps and highlight a common trap: some USB cables only support charging. If nothing appears, try another data cable and a direct USB port before changing Linux settings.
Android generally shares files through MTP, the Media Transfer Protocol. This does not expose the phone as an ordinary USB disk. Desktop integration handles that difference for everyday copying; Debian’s MTP guidance describes support through GNOME and KDE, alongside command-line alternatives.
Choose the method that fits the job
| Your situation | Start here | Practical consideration |
|---|---|---|
| You need a few photos or documents | Your desktop file manager | Try one small copy before selecting everything. |
| A terminal tool needs a folder path | A jmtpfs mount in your home directory | Release the desktop’s connection first. |
| The phone charges but does not appear | USB mode, cable and port checks | Installing another transfer tool may not address the cause. |
| A transfer fails on one file | A small, isolated test copy | Record the exact error before renaming or deleting anything. |
Mount Android with jmtpfs
The following installation command applies to Debian and Ubuntu releases that provide jmtpfs, including Debian 13 and Ubuntu 24.04. Package availability varies by release; use your distribution’s repositories.
sudo apt update
sudo apt install jmtpfsFinish any desktop transfer, eject or unmount the phone in the file manager if that option is available, and close applications browsing it. Then create an empty mount directory under your own account:
mkdir -p "$HOME/mnt/android"
jmtpfs "$HOME/mnt/android"
ls "$HOME/mnt/android"The listing should reveal the storage areas exposed by your phone. Browse those names before constructing a copy command: labels such as “Internal shared storage” vary by device and language.
Connect only the intended phone for this simple workflow. You can list detected MTP devices with:
jmtpfs -lThe jmtpfs manual documents device selection, mounting and unmounting. It also notes that a locked phone can cause an input/output error.
Use sudo for package installation, but run the mount as your normal user. Earlier versions of this article included -o allow_other. That option removes FUSE’s restriction to the mounting user, permitting access by other local users subject to applicable permissions. It is unnecessary for a personal transfer; see the FUSE mount options.
When the phone is busy or the mount fails
A “device busy” error can mean another application already holds the MTP connection. The libmtp project’s troubleshooting guidance identifies competing desktop services as a known cause.
First stop active transfers and release the phone from other applications. Reconnect it, select File transfer again, and retry with one client. Closing a file-manager window alone may leave its background service connected.
The old suggestion here to kill kiod or kiod5 was a workaround for a particular desktop setup. Avoid treating those process names as a universal fix. If the conflict persists, identify the MTP service used by your desktop before stopping it; signing out and back in after saving your work is another way to clear the session.
For a permissions error, check access to both the mount directory and USB device through your distribution’s device-access configuration. Running everything as root can hide the underlying problem.
If copying fails consistently on one item, test that file separately and note its name, size and error message. Files previously copied from an iPhone are not, by themselves, evidence of a mounting problem. Diagnose the failure before changing the originals.
Check the copy, then disconnect
For business files, I recommend copying into a clearly named local project folder, opening representative files, and checking that the expected items arrived. Keep the originals until the copy has been checked and backed up. Work on the local copies once the transfer is complete.
Close files and terminals using the mount, then unmount it:
cd "$HOME"
fusermount -u "$HOME/mnt/android"If your distribution provides only fusermount3, use fusermount3 -u with the same path. If unmounting reports that the folder is busy, close the remaining applications using it and retry before unplugging.
For a recurring team task, document the working cable, USB setting, destination folder and verification step. That gives the next person a repeatable handover. If small technical obstacles keep interrupting delivery, contact Greg to discuss the workflow and where practical help would make a difference.
Related on GrN.dk
- OpenAI File Search: Internal Docs Need Governance Before Trust
- Search Console Can See Social Posts—Your Reports Need a New Map
- A Voice Agent Is Only Ready When the Human Handoff Works
Need help with this kind of work?
Talk to Greg about your technical workflow Get in touch with Greg.
