Created attachment 70057 [details] /etc/fstab Some (but not all!) USB sticks aren't automatically mounted when they are plugged in. Out of 9 USB sticks I tried, six failed and only three worked. The pattern is always similar: The disk is recognized, but gvfs thinks it contains no volumes until the the volume is mounted some other way (e.g. using mount(8) as root.) I'm using Debian's unstable packages of gvfs 1.14.1 and udisks2 2.0.0.
Created attachment 70058 [details] output of gvfs-mount -li with a non-working USB stick attached
Created attachment 70059 [details] output of udisksctl dump with a nonworking USB stick (Kingston-DataTraveler) attached
Created attachment 70060 [details] output of gvfs-mount -io when a non-working USB stick is attached
(In reply to comment #2) > Created attachment 70059 [details] > output of udisksctl dump with a nonworking USB stick (Kingston-DataTraveler) > attached This is /dev/sdb and we correctly identify it has having a DOS/MBR partition table on it. But there are no partitions and this is why you're not seeing anything. Please try two things 1. attach output of 'udevadm info --export-db' (as root) 2. attach output of dmesg where the device is detected - should look like [a] 3. try restarting udisks ('systemctl restart udisks2.service') 4. whilst attaching the device, paste the output of 'udevadm monitor --udev --property' (as root) Thanks. [a] : [173110.401031] usb 2-1: new high-speed USB device number 3 using ehci_hcd [173110.517249] usb 2-1: New USB device found, idVendor=03f0, idProduct=3307 [173110.517254] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [173110.517258] usb 2-1: Product: v125w [173110.517262] usb 2-1: Manufacturer: HP [173110.517265] usb 2-1: SerialNumber: 3S0208300278 [173110.517770] scsi7 : usb-storage 2-1:1.0 [173111.520668] scsi 7:0:0:0: Direct-Access HP v125w 1.00 PQ: 0 ANSI: 2 [173111.521694] sd 7:0:0:0: Attached scsi generic sg2 type 0 [173111.523403] sd 7:0:0:0: [sdb] 3913664 512-byte logical blocks: (2.00 GB/1.86 GiB) [173111.523895] sd 7:0:0:0: [sdb] Write Protect is off [173111.523900] sd 7:0:0:0: [sdb] Mode Sense: 33 07 03 f0 [173111.524647] sd 7:0:0:0: [sdb] No Caching mode page present [173111.524653] sd 7:0:0:0: [sdb] Assuming drive cache: write through [173111.527770] sd 7:0:0:0: [sdb] No Caching mode page present [173111.527775] sd 7:0:0:0: [sdb] Assuming drive cache: write through [173111.528406] sdb: sdb1 sdb2 [173111.530642] sd 7:0:0:0: [sdb] No Caching mode page present [173111.530646] sd 7:0:0:0: [sdb] Assuming drive cache: write through [173111.530650] sd 7:0:0:0: [sdb] Attached SCSI removable disk
Created attachment 70076 [details] output of 'udevadm info --export-db' (as root)
Created attachment 70077 [details] output of dmesg where the device is detected
Created attachment 70078 [details] output of 'udevadm monitor --udev --property' (as root) whilst attaching the device
(In reply to comment #4) > This is /dev/sdb and we correctly identify it has having a DOS/MBR partition > table on it. But there are no partitions and this is why you're not seeing > anything. Using fdisk or cfdisk I see no difference between devices that work and devices that don't work. They all have an intact DOS partition (/dev/sdb1). I've attached the output you requested. (The system has been restarted a number of times with no effect.)
(In reply to comment #7) > Created attachment 70078 [details] > output of 'udevadm monitor --udev --property' (as root) whilst attaching the > device Looks like sdb1 never ever appears. And from dmseg, there's this: > [19130.748070] sd 48:0:0:0: [sdb] Attached SCSI removable disk > [19130.751125] sr1: scsi3-mmc drive: 8x/40x writer xa/form2 cdda tray > [19130.751398] sr 48:0:0:1: Attached scsi CD-ROM sr1 > [19130.751565] sr 48:0:0:1: Attached scsi generic sg3 type 5 > [19130.757091] sdb: detected capacity change from 2049900032 to 0 where the last line is very suspect. So either there's a (hardware) problem with your device or with the kernel drivers. There's nothing we can do in udev or udisks about it, sorry. Closing NOTOURBUG. I would recommend trying another kernel, other hardware or maybe even another USB port? Hope this helps.
(In reply to comment #9) > So either there's a (hardware) problem with your device or with the kernel > drivers. I am not convinced. As you have recommended, I have tried another kernel and completely different hardware and it turns out the same devices don't ever get automounted by gvfs. That last suspect line in dmesg output was actually atypical. I'm attaching the output of dmesg and udevadm again, with another device (a 16 GiB SanDisk Cruzer). Please have a look at it and if there's something I can try to get this fixed I'll respond in a timely manner.
Created attachment 70898 [details] output of 'udevadm info --export-db' (as root) [SanDisk Cruzer]
Created attachment 70899 [details] output of dmesg where the device is detected [SanDisk Cruzer]
Created attachment 70900 [details] output of 'udevadm monitor --udev --property' (as root) whilst attaching the device [SanDisk Cruzer] I've truncated this output, as it seems to be stuck in an endless loop.
(In reply to comment #13) > Created attachment 70900 [details] > output of 'udevadm monitor --udev --property' (as root) whilst attaching the > device [SanDisk Cruzer] > > I've truncated this output, as it seems to be stuck in an endless loop. I guess this is the root problem. Maybe you have something that reacts to uevents (e.g. sdb added) and keeps opening the device non-readonly thus causing a change event to be generated in an endless loop? It's hard to pinpoint since any random package can drop udev rules in {/lib,/etc}/udev/rules.d or start daemons that listen to uevents etc. For example, judging from the debug output, there's this UDISKS_PARTITION_TABLE=1 UDISKS_PARTITION_TABLE_COUNT=1 UDISKS_PARTITION_TABLE_SCHEME=mbr which suggests you have udisks 1.x installed. FWIW, I don't think this is what is causing the problem but FYI we not support that version anymore (except for security updates). Please use udisks 2.x (comment 0 suggests this is what you are using) and, ideally, uninstall udisks 1.x. I'm sorry but I still don't see why this is an udisks problem and/or how I can help - good luck finding out what is causing the root problem is!
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.