You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Nemo hangs after phone being plugged in for a while #3764
Nemo hangs whenever I try to open it by the terminal or by the desktop icon.
But, the bug stopped when I unplugged my phone which Nemo had previously recognized as a storage device, despite the phone being set to "No data transfer."
Steps to reproduce
Make sure Nemo is running
Plug in an android phone, and make sure its "Use USB for" setting is set to "No Data Transfer". Nemo will not hang right there, but it will regardless recognise the phone as a storage device, and open it to desktop to reveal an empty folder. This happens even if "No data transfer" was set even before the phone was plugged in to the computer.
Sorry, but this step is uncertain, not fully sure what happens to cause this bug but I suspect that it has something to do with Nemo's cache expiring or something? The bug seems to happen completely randomly, sometimes hours after an initial OS boot so I'm not sure what it could be.
Open Nemo. If whatever has required has happened, it'll hang. Opening Nemo in terminal will result in a timeout.
Unplug the phone, and Nemo will immediately open up as normal.
Expected behavior
Instead of hanging or waiting eternally, it should recognize the drive isn't behaving properly or is refusing to connect and move on to the next drive instead of waiting an unreasonable amount of time.
Additional information
The version of Android for the phone is Android 15.
When running "nemo" in terminal, it hangs until eventually it receives a time-out from the system.
I have been unable to find the source of the problem.
I am uncertain of whether this happens with iOS too.
Omg I can't believe this is what's happening to me! I've had issues with Nemo on both PopOS and Ubuntu 24.04 when after a while it becomes unresponsive and then takes several minutes to restart. I just tried unplugging my /e/OS phone which was set to no data transfer and just like that it opened.
I'm also having this extremely frustrating issue. Whenever I plug the phone in, after a while, Files hangs. As soon as I unplug the phone, Files works again normally.
Phone: Motorola g84 5G
Phone OS: e/OS
Connection: Type C to Type C, Via a hub
Computer: HP EliteBook 845 G8
OS Version: Linux Mint 22.3 - Cinnamon 64-bit
Kernel Version: 7.0.0-30-generic
It's been going on for at least a few years, so it'd be good to see it get some attention because unplugging your phone is not an obvious fix for the file browser not working.
Same issue with Motorola Moto G56 5G — GVFS/PTP errors and Nemo timeout (Linux Mint 22.3)
I can confirm experiencing a very similar issue on Linux Mint 22.3 Cinnamon with a Motorola Moto G56 5G connected via USB.
Interestingly, another user in this thread reported the same behavior with a Motorola G84 5G, which may indicate a broader compatibility issue involving Motorola Android devices, GVFS/PTP and Nemo.
I collected diagnostic logs during the incident on October 18, 2026.
System information
Distribution: Linux Mint 22.3 Zena
Desktop environment: Cinnamon 6.6.9
File manager: Nemo 6.6.3
Kernel: 7.0.0-38-generic
GVFS: 1.54.4
libgphoto2: 2.5.31
Phone: Motorola Moto G56 5G
USB VID:PID: 22b8:2e82
Problem description
Nemo suddenly stopped opening directories, including my home directory.
Running the following commands:
nemo -q
nemo ~
resulted in Nemo becoming unresponsive and eventually producing this error:
Could not register nemo as a remote: Истекло время ожидания
The Russian text means "Connection timed out."
I also verified that the user D-Bus session remained responsive:
PTP: reading event an error 0x05 occurred
Device 0 (VID=22b8 and PID=2e82) is a Motorola Moto G (ID2).
Android device detected, assigning default bug flags
After reconnecting the phone, another GVFS error appeared:
Error 1: Get Storage information failed.
Timeline — October 18, 2026
All times are local (UTC+02:00).
12:08:17 — Repeated GVFS PTP I/O errors while the phone was connected.
12:10:17 — Additional PTP errors.
12:11:56 — The USB device was disconnected.
12:14:29 — Nemo debug output showed successful creation and loading of the home directory window after the phone was disconnected.
12:15:49 — The Motorola device was connected again. GVFS subsequently reported a storage information error.
Nemo is currently working again. The issue appears intermittent, and I have not yet established a reliable reproduction procedure.
Interesting detail: USB device identification
Although my phone is a Motorola Moto G56 5G, the Linux kernel reports the following USB product string:
The device model reported by the USB descriptor differs from the actual phone model.
I am including this observation because it may be relevant when investigating device detection and compatibility.
Possible cause
Based on the available evidence, I suspect that Nemo may be performing a blocking operation while querying a connected Android device through GVFS/PTP.
If the device does not respond correctly, Nemo may become unresponsive instead of continuing normally.
However, the logs establish only a correlation between the GVFS errors and the Nemo failure, not a definitive root cause.
Expected behavior
Nemo should remain responsive even when an attached Android device fails to provide storage information or respond to PTP requests.
Problems accessing an external device should not prevent users from opening local directories.
Additional information
I noticed that commits referencing this issue propose asynchronous disk information queries in the Nemo places sidebar.
Could the maintainers confirm whether those changes are expected to address this behavior and whether they are available in any released version?
I have attached a sanitized diagnostic archive containing:
System and package versions
GVFS/PTP error messages
USB connection and disconnection events
Nemo debug output after recovery
Thank you for investigating this issue. I hope the additional logs and the information about another affected Motorola device will help identify the root cause.
Activity
mattbatt commentedon Jun 9, 2026
This is happening to me too. I just came searching for an answer.
loosestrife commentedon Jun 23, 2026
yeah basically im running this script to find out why if i get a core from it i can analyze it and find this particular hang and fix it
geekysquirrel commentedon Jul 18, 2026
Omg I can't believe this is what's happening to me! I've had issues with Nemo on both PopOS and Ubuntu 24.04 when after a while it becomes unresponsive and then takes several minutes to restart. I just tried unplugging my /e/OS phone which was set to no data transfer and just like that it opened.
eburger01 commentedon Aug 28, 2026
I'm also having this extremely frustrating issue. Whenever I plug the phone in, after a while, Files hangs. As soon as I unplug the phone, Files works again normally.
Phone: Motorola g84 5G
Phone OS: e/OS
Connection: Type C to Type C, Via a hub
Computer: HP EliteBook 845 G8
OS Version: Linux Mint 22.3 - Cinnamon 64-bit
Kernel Version: 7.0.0-30-generic
The same bug is reported in:
#3394
#3270
It's been going on for at least a few years, so it'd be good to see it get some attention because unplugging your phone is not an obvious fix for the file browser not working.
places-sidebar: query disk-full info async to avoid hangs on unrespon…
places-sidebar: query disk-full info async to avoid hangs on unrespon…
0x00000109 commentedon Oct 18, 2026
Same issue with Motorola Moto G56 5G — GVFS/PTP errors and Nemo timeout (Linux Mint 22.3)
I can confirm experiencing a very similar issue on Linux Mint 22.3 Cinnamon with a Motorola Moto G56 5G connected via USB.
Interestingly, another user in this thread reported the same behavior with a Motorola G84 5G, which may indicate a broader compatibility issue involving Motorola Android devices, GVFS/PTP and Nemo.
I collected diagnostic logs during the incident on October 18, 2026.
System information
Problem description
Nemo suddenly stopped opening directories, including my home directory.
Running the following commands:
resulted in Nemo becoming unresponsive and eventually producing this error:
The Russian text means "Connection timed out."
I also verified that the user D-Bus session remained responsive:
Result:
This suggests that the entire D-Bus session was not unresponsive.
Relevant GVFS errors
The user journal repeatedly contained:
Additional messages included:
After reconnecting the phone, another GVFS error appeared:
Timeline — October 18, 2026
All times are local (UTC+02:00).
Nemo is currently working again. The issue appears intermittent, and I have not yet established a reliable reproduction procedure.
Interesting detail: USB device identification
Although my phone is a Motorola Moto G56 5G, the Linux kernel reports the following USB product string:
The device model reported by the USB descriptor differs from the actual phone model.
I am including this observation because it may be relevant when investigating device detection and compatibility.
Possible cause
Based on the available evidence, I suspect that Nemo may be performing a blocking operation while querying a connected Android device through GVFS/PTP.
If the device does not respond correctly, Nemo may become unresponsive instead of continuing normally.
However, the logs establish only a correlation between the GVFS errors and the Nemo failure, not a definitive root cause.
Expected behavior
Nemo should remain responsive even when an attached Android device fails to provide storage information or respond to PTP requests.
Problems accessing an external device should not prevent users from opening local directories.
Additional information
I noticed that commits referencing this issue propose asynchronous disk information queries in the Nemo places sidebar.
Could the maintainers confirm whether those changes are expected to address this behavior and whether they are available in any released version?
I have attached a sanitized diagnostic archive containing:
Thank you for investigating this issue. I hope the additional logs and the information about another affected Motorola device will help identify the root cause.
nemo-recovered-debug-excerpt.log
phone-usb-events.log
gvfs-ptp-events.log
system-versions.txt