Solución:
Entonces tienes esto:
El administrador de archivos presenta esos mensajes de error, que provienen de GVfs, que transmite información de libmtp.
Prevención de ventanas emergentes de error del administrador de archivos
Desafortunadamente, todavía no he descubierto una forma de suprimir las ventanas emergentes de error en el administrador de archivos GNOME / MATE / Cinnamon. Quizás algún día, buscaré en el código fuente para ver dónde se puede desactivar o interceptar el error.
Como no tengo una respuesta para esto, pasemos a la siguiente mejor opción aceptable, que es …
Cerrar ventanas emergentes del Administrador de archivos por comando
Aquí hay un script que se puede usar para borrar las ventanas emergentes en GNOME, MATE y Cinnamon:
#!/bin/bash
function list_empty_windows() {
wmctrl -lp | awk "{if($5==""){print$3,$1}}"
}
function list_wm_pids() {
ps aux | grep cinnamon | perl -pe 's/.*+s+(d+)s+.*/1/'
pidof nautilus | tr ' ' 'n'
pidof caja | tr ' ' 'n'
pidof nemo | tr ' ' 'n'
}
function list_popup_windows() {
local empty_window_file=$(mktemp)
local window_manager_pid_file=$(mktemp)
list_empty_windows > "$empty_window_file"
list_wm_pids | sort > "$window_manager_pid_file"
join "$empty_window_file" "$window_manager_pid_file"
}
function main() {
list_popup_windows | cut -d ' ' -f 2 | xargs -n1 -P100 wmctrl -ic
}
main
Si desea un comando fácil de recordar, estos cerrarán todas las ventanas en su administrador de archivos y harán que su escritorio reinicie su administrador de archivos:
- GNOMO:
killall nautilus - COMPAÑERO:
killall caja - Canela:
killall nemo
Deshabilitar el montaje automático de Google Pixel
No parece haber una forma de recordar ignorar solo Google Pixel.
No recomiendo esto, y no lo he probado yo mismo, pero para destacar Google Pixel, es posible que deba comentar el producto 18d1 del proveedor 4ee1 (Google Pixel) y el producto 4ee2 del proveedor 18d1 (depuración de Google Pixel) en el udev reglas y hwdb.
Puede encontrar los registros con este comando:
grep -ri '18d1.*4ee[12]' /lib/udev
Después de comentar los registros udev de Google Pixel, es posible que deba reiniciar su entorno de escritorio, reiniciar y / o ejecutar alguna combinación de los siguientes comandos:
sudo udevadm hwdb --update
sudo udevadm control --reload-rules
sudo udevadm trigger
Nuevamente, esto no está probado, y no lo recomiendo especialmente porque para montar Google Pixel nuevamente, tendría que deshacer los cambios manuales de udev.
Explicación
De acuerdo a /var/log/syslog, GNOME hace que aparezca el error porque el dispositivo USB desapareció en el segundo intento de inicializarlo:
Jan 24 01:32:41 node51 kernel: [613604.065259] usb 3-2: new SuperSpeed USB device number 96 using xhci_hcd
Jan 24 01:32:41 node51 kernel: [613604.082734] usb 3-2: New USB device found, idVendor=18d1, idProduct=4ee1
Jan 24 01:32:41 node51 kernel: [613604.082739] usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Jan 24 01:32:41 node51 kernel: [613604.082741] usb 3-2: Product: Pixel
Jan 24 01:32:41 node51 kernel: [613604.082743] usb 3-2: Manufacturer: Google
Jan 24 01:32:41 node51 kernel: [613604.082745] usb 3-2: SerialNumber: XXXXXXXXXXXX
Jan 24 01:32:41 node51 kernel: [613604.083855] usb 3-2: Enable of device-initiated U1 failed.
Jan 24 01:32:41 node51 kernel: [613604.084154] usb 3-2: Enable of device-initiated U2 failed.
Jan 24 01:32:42 node51 org.gtk.vfs.Daemon[4988]: Device 0 (VID=18d1 and PID=4ee1) is a Google Inc (for LG Electronics/Samsung) Nexus 4/5/7/10 (MTP).
Jan 24 01:32:43 node51 org.gtk.vfs.GPhoto2VolumeMonitor[4988]: (process:5256): GVFS-GPhoto2-WARNING **: device (null) has no BUSNUM property, ignoring
Jan 24 01:33:34 node51 org.gtk.vfs.Daemon[4988]: PTP_ERROR_IO: failed to open session, trying again after resetting USB interface
Jan 24 01:33:34 node51 org.gtk.vfs.Daemon[4988]: LIBMTP libusb: Attempt to reset device
Jan 24 01:33:34 node51 org.gtk.vfs.Daemon[4988]: inep: usb_get_endpoint_status(): No such device
Jan 24 01:33:34 node51 org.gtk.vfs.Daemon[4988]: outep: usb_get_endpoint_status(): No such device
Jan 24 01:33:34 node51 org.gtk.vfs.Daemon[4988]: libusb_open() failed!: No such device
Jan 24 01:33:34 node51 org.gtk.vfs.Daemon[4988]: LIBMTP PANIC: Could not init USB on second attempt
Jan 24 01:33:34 node51 org.gtk.vfs.Daemon[4988]: ** (gvfsd:5151): WARNING **: dbus_mount_reply: Error from org.gtk.vfs.Mountable.mount(): Unable to open MTP device '[usb:003,096]'
En el ejemplo anterior, GVfs a través de libmtp identificó el dispositivo 096 del bus USB 003 como el dispositivo Google Pixel, pero el dispositivo Google Pixel ya se había desconectado. La próxima vez que Google Pixel se vuelva a conectar, Linux habrá asignado una nueva ID de dispositivo.
libmtp porque todavía está intentando funcionar con el dispositivo que desapareció. GVfs detecta el error y lo reenvía a Archivos GNOME o algún otro administrador de archivos basado en GNOME.
¿Quién tiene la culpa?
Según lo que he descubierto, estos tienen margen de mejora:
libmtp
libmtp es probablemente el principal responsable de causar este problema.
Debería mejorar el manejo de errores cuando un dispositivo MTP se conecta y se desconecta repentinamente. El error solo debe pasarse si el dispositivo aún existe. Si el dispositivo USB no existe, no tiene sentido intentar restablecerlo.
Informar problemas a libmtp
Androide
Android podría mejorar su implementación de MTP para que no se desconecte inmediatamente al conectarse a una computadora.
Informar problemas a Android
Nautilus / Caja / Nemo
Sería bueno si este software ofreciera una preferencia para suprimir los mensajes de error o mostrarlos de una manera menos emergente.
Informar problemas a GNOME
Informar problemas a MATE Caja
Informar problemas a Linux Mint Nemo
Tengo una solución para esto en Nemo:
Ir a Editar> Preferencias> Comportamiento y en Manejo de medios desmarque “Montar automáticamente medios extraíbles cuando se inserte y al iniciar”.
Cuando termine de cargar su teléfono, puede volver a habilitar la opción para reanudar el comportamiento predeterminado.