Removable drives and media not automatically mounted/listed

Bug #1210898 reported by Jack Fromm on 2013-08-11
104
This bug affects 27 people
Affects Status Importance Assigned to Milestone
Thunar Volume Manager
Confirmed
Medium
thunar-volman (Ubuntu)
High
Alvaro A.Cordoba

Bug Description

After inserting an external drive, flash drive or data CD/DVD, the drives show up unmounted in the side pane even though in Volume Manager the preferences have been set to automount and display contents.

ProblemType: Bug
DistroRelease: Ubuntu 13.10
Package: thunar 1.6.2-0ubuntu1
ProcVersionSignature: Ubuntu 3.10.0-6.17-generic 3.10.3
Uname: Linux 3.10.0-6-generic x86_64
ApportVersion: 2.12-0ubuntu3
Architecture: amd64
Date: Sat Aug 10 20:16:41 2013
InstallationDate: Installed on 2013-08-08 (2 days ago)
InstallationMedia: Xubuntu 13.10 "Saucy Salamander" - Alpha amd64 (20130804)
MarkForUpload: True
SourcePackage: thunar
UpgradeStatus: No upgrade log present (probably fresh install)

I have "Mount removable drives when hot-plugged" option enabled.
However, thunar-volman fails to mount any removable media.

I've made the following script as a workaround for the issue:

cat /usr/local/bin/thunar-volman
#!/bin/sh
sleep 1
exec /usr/bin/thunar-volman $@ >/tmp/thunar-volman.log 2>&1

Mount succeeds if thunar-volman is started after a small delay.
If I comment "#sleep 1", mount fails and the output of /tmp/thunar-volman.log looks as follows:
cat /tmp/thunar-volman.log
thunar-volman: Could not detect the volume corresponding to the device.

/usr/bin/thunar-volman --version
thunar-volman 0.8.0 (Xfce 4.10)

Copyright (c) 2004-2007 Benedikt Meurer <email address hidden>
Copyright (c) 2010-2011 Jannis Pohlmann <email address hidden>

All rights reserved.

Please report bugs to <http://bugzilla.xfce.org/>.

Thanks,
Val.

The problem seems to be in the inconsitency between thunar and thunar-volman.

Thunar seems to be using UDEV events to detect device add/remove, while thunar-volman uses GVolumeMonitor to find a volume corresponding to the added device and mount it. The problem is gvolume monitor has not set-up the new device volume by the time thunar-volman is started. Obviously UDEV events are emitted first and there's no guarantee GVolumeMonitor manages to set up a volume fast enough for thunar-volman to use it.

I'm not thunar expert, but probably the best way to fix it would be to use the the same event monitoring mechanism in both thunar and thunar-volman. For example, if thunar started thunar-volman based on GVolumeMonitor "volume-added" events AOT UDEV device add events, thunar-volman would detect the volume and mount it without any problems.

Thanks,
Val.

Confirm it.
Inspire in thunar-volman code now try to add support to remobable devices in pragha, and I found this problem.

Now I did a quick test, and adding a sleep (5) before tvm_g_volume_monitor_get_volume_for_kind, solves all the problems.

ONLY A TEST!.

Created attachment 4608
Mount devices with a timeout of 5 seconds.

Tested in Fedora 17 with xfce 4.10.
Only wait 5 seconds to make sure that glib detect the volume.

Auto-mounting worked fine in 4.8. What has changed since then? Maybe

Adding a sleep at the beginning of twm_block_device_mount doesn't work for me. However, adding a sleep in main() does.

Further, adding a loop inside twm_block_device_mount with a sleep and retry of the tvm_g_volume_monitor_get_volume_for_kind doesn't help at all, even when the total delay runs into several minutes, and even when a new volume monitor is created.

I find this very strange - it is almost as if the contents of the volume monitor are fixed at thread invocation time and can't change thereafter. There is something about volume monitor not being thread-safe, but I don't understand just what this means.

I have the same problem in Xubuntu 12.10 with XFCE 4.10.
With the workaround it seems to work now.

Thanks to vaxon77

Debian Wheezy, XFCE 4.10. When gvfs 1.16 and udisks2 2.1 is installed, Thunar mounts cd/dvd only if xfburn is launched. Mounts work normal with gvfs 1.12 and udisks 1.0.4

(In reply to programmist11180 from comment #7)
> Debian Wheezy, XFCE 4.10. When gvfs 1.16 and udisks2 2.1 is installed,
> Thunar mounts cd/dvd only if xfburn is launched. Mounts work normal with
> gvfs 1.12 and udisks 1.0.4

I have experienced the same problem with the software you mentioned. Also, I couldn't mount my android phone to. When I've downgraded gvfs and udisks to debian's 'stable' branch, i.e. gvfs 1.12 and udisk 1.0.4, I've got automount worked both for cd/dvd and android phone.

Jack Fromm (jjfrv8) wrote :
Ubuntu QA Website (ubuntuqa) wrote :

This bug has been reported on the Ubuntu Package testing tracker.

A list of all reports related to this bug can be found here:
http://packages.qa.ubuntu.com/qatracker/reports/bugs/1210898

tags: added: package-qa-testing
Ubuntu QA Website (ubuntuqa) wrote :

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/1210898

tags: added: iso-testing
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in thunar (Ubuntu):
status: New → Confirmed
2CV67 (2cv67) wrote :

This sounds like the problem I reported on Ubuntu Forum back in May 2013 using 12.10:
http://ubuntuforums.org/showthread.php?t=2146129

Still the same today in 13.04.

Basically, when hot-plugging a camera, it sometimes appears in Thunar as mounted & calls up Shotwell as required.
But more often than not, it appears in Thunar as unmounted & fails to call Shotwell.

I would be pleased to provide further details or run any tests.

Is there any further investigation of this problem?

The problem remains when using gvfs of version 1.18.2-2

I compiled the patch in comment 3, which appears to fix the problem, at the cost of a delay in mounting.

Sergio Benjamim (sergio-br2) wrote :

interesting. If Thunar is already open, and I plug an flash drive, then it will mount and open an other Thunar window, like I told in Bug #1261460.

But if I plug my flash drive without one Thunar window open, then it will not mount automatically, I can see this in /media/my-user/

tags: added: trusty

This sounds very much like https://bugzilla.xfce.org/show_bug.cgi?id=9193 which has a proposed workaround.

The crux of the problem is that thunar-volman tries to access information about the volume before the information is available. Adding a delay solves the problem, but not in a pleasant way.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725978
CD/DVD/ any optical disk mount can be broken by udisks2.

Changed in thunar (Ubuntu):
importance: Undecided → Low
Changed in hundredpapercuts:
status: New → Confirmed
importance: Undecided → Low

A simple way to fix CD/DVD mount and others with udisks2: add to /etc/rc.local:

echo 2000 > /sys/module/block/parameters/events_dfl_poll_msecs

and reboot (Or, if you don't want to reboot now, you can execute this command from the root).

See for more details:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725978
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=713877

I have the exact same problem, that gets fixed either with the script or the patch (setting it to 1s, instead of 5s).

Please, fix this issue :)

Besides, I detected that thunar needs to be running, either as a daemon or a window open.

Elfy (elfy) wrote :

Plugged in Sansa mp3 player.

Recognised, did some media player movement.

Unmounted and ejected - thunar crashed.

Further attempts to plugin and mount mp3 player fail. Reboot of machine - no difference. Cold start - can now plugin and mount mp3 player.

Elfy (elfy) wrote :

An update to mount means that the only thing that failed for me now works.

Elfy (elfy) wrote :

spoke too soon ...

affects: thunar (Ubuntu) → thunar-volman (Ubuntu)

I have uploaded a patched version of thunar-volman to https://launchpad.net/~thad-fisch/+archive/test for testing purpose.

Jarno Suni (jarnos) wrote :

The repository did not work for Sausy:
sudo apt-get update says:

W: Failed to fetch http://ppa.launchpad.net/thad-fisch/test/ubuntu/dists/saucy/main/binary-amd64/Packages 404 Not Found

W: Failed to fetch http://ppa.launchpad.net/thad-fisch/test/ubuntu/dists/saucy/main/binary-i386/Packages 404 Not Found

Jarno, sorry that I did not mention it, but the PPA is targeting Trusty ("Fixes for Xubuntu 14.04 LTS").

Elfy (elfy) wrote :

PPA works here - though I am affected by a slightly different issue - Sansa Clip wasn't visible ~90% of insertions

Now shows up and automounts.

Pasi Lallinaho (knome) wrote :

Marking as high since the same bug also causes some drives/media to not be listed at all, which makes it impossible to mount them at all from the GUI. The bugfix in the PPA fixes this issue as well, as reported by Elfy in comment #14.

summary: - Thunar does not automatically mount removable drives and media
+ Removable drives and media not automatically mounted/recognized
summary: - Removable drives and media not automatically mounted/recognized
+ Removable drives and media not automatically mounted/listed
Changed in thunar-volman (Ubuntu):
importance: Low → High
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package thunar-volman - 0.8.0-4ubuntu1

---------------
thunar-volman (0.8.0-4ubuntu1) trusty; urgency=medium

  * Fix auto-mounting of removable devices. LP: #1210898
 -- Thaddaeus Tintenfisch <email address hidden> Fri, 11 Apr 2014 21:59:42 +0200

Changed in thunar-volman (Ubuntu):
status: Confirmed → Fix Released
Pasi Lallinaho (knome) on 2014-04-14
Changed in thunar-volman (Ubuntu):
assignee: nobody → Thaddäus Tintenfisch (thad-fisch)

I'm also affected by this bug.

Why nobody fix thunar-volman? The bug report is open since 2012....

I desisted and started using udiskie instead. Never had a problem again.

Changed in thunar-volman:
importance: Unknown → Medium
status: Unknown → Confirmed

Bug is still present in 0.8.0-4ubuntu1.

Still a problem

$ thunar-volman -V
thunar-volman 0.8.0 (Xfce 4.10)

$ thunar -V
Thunar 1.6.3 (Xfce 4.10)

Please fix.

Matthew Haughton (snafu109) wrote :

For anyone still experiencing this issue I've opened a new bug against thunar-volman version 0.8.0-4ubuntu1. Please add to that report if, like me, you still have a problem.

Bug #1320542

Matthew Haughton (snafu109) wrote :

I've closed the bug I opened in my previous comment as "Invalid" - my issue was that the thunar daemon wasn't running. When I added 'thunar --daemon' to the list of applications to autostart when XFCE starts it did start working as expected.

Mattia Rizzolo (mapreri) on 2014-05-18
no longer affects: hundredpapercuts

Hi there.
I wrote the proposed patch, but honestly not recommend it..

This may solve the problems, but it really is not a problem of thunar!. it's definitely a problem between udev/udisk and glib!.

Please, Those who have problems, test the comented on:

https://bugzilla.xfce.org/show_bug.cgi?id=9193#c14

With it work properly, and no require changes in any code..

R E Pas (repas1000) on 2014-12-26
affects: thunar-volman (Ubuntu) → thunar-volman-plugin (Ubuntu)
affects: thunar-volman-plugin (Ubuntu) → thunar-volman (Ubuntu)

https://bugzilla.xfce.org/show_bug.cgi?id=9193#c14

doesn't work reliably for me. It may be that it doesn't help at all, except to cause the race condition to sometimes come out the "right" way.

The problem is still active with Thunar 1.6.6 and thunar-volman 0.8.0. I'm going to try to add some patches to the current versions.

My patch that tries to get the volume up to three times, with a 1-second delay between each time, hides the problem successfully.

However, a better solution would be to have thunar-volman only called when the volume has been set up. This is known, as the volume has to be set up for the icon to appear on the desktop.

> https://bugzilla.xfce.org/show_bug.cgi?id=9193#c14
>
> doesn't work reliably for me. It may be that it doesn't help
> at all, except to cause the race condition to sometimes come
> out the "right" way.

I honestly do not know. In the latest versions of fedora not
have problems and use this change by default.. :S

On thunar volman 0.8.1 added my patch.. :S

http://git.xfce.org/xfce/thunar-volman/commit/?id=f3f8ba9d92923492d93672676dffc5f65c068ea9

As they added to the patch, Please at least reduce the time to one or two seconds. 5 seconds is completely unnecessary.

I see that 0.8.1 has your patch.

I think that better than waiting 1 second would be to try immediately and only then wait for a bit. I modified the code accordingly, ending up with

static gboolean
tvm_block_device_mount_volume (TvmContext *context, GVolume *volume)
{
  GMountOperation *mount_operation;

  /* check if we have a volume */
  if (volume != NULL)
    {
      /* check if we can mount the volume */
      if (g_volume_can_mount (volume))
        {
          /* try to mount the volume asynchronously */
          mount_operation = gtk_mount_operation_new (NULL);
          g_volume_mount (volume, G_MOUNT_MOUNT_NONE, mount_operation,
                          NULL, (GAsyncReadyCallback) tvm_block_device_mount_finish, context);
          g_object_unref (mount_operation);
        }
      else
        {
          g_set_error (context->error, G_FILE_ERROR, G_FILE_ERROR_FAILED,
                       _("Unable to mount the device"));

          /* finish processing the device */
          tvm_device_handler_finished (context);
        }
    }
  else
    {
      g_set_error (context->error, G_FILE_ERROR, G_FILE_ERROR_FAILED,
                   _("Could not detect the volume corresponding to the device"));

      /* finish processing the device */
      tvm_device_handler_finished (context);
    }
    return FALSE;
}

static gboolean
tvm_block_device_mount_retry (TvmContext *context)
{
  GVolume *volume;

  volume =
    tvm_g_volume_monitor_get_volume_for_kind (context->monitor,
                                              G_VOLUME_IDENTIFIER_KIND_UNIX_DEVICE,
                                              g_udev_device_get_device_file (context->device));

  /* if no volume then call anyway to do not-found processing */
  tvm_block_device_mount_volume (context,volume);
  return FALSE;
}

static gboolean
tvm_block_device_mount (TvmContext *context)
{
  GVolume *volume;

  g_return_if_fail (context != NULL);

  /* determine the GVolume corresponding to the udev device */
  volume =
    tvm_g_volume_monitor_get_volume_for_kind (context->monitor,
                                              G_VOLUME_IDENTIFIER_KIND_UNIX_DEVICE,
                                              g_udev_device_get_device_file (context->device));
  if (volume != NULL)
    {
      tvm_block_device_mount_volume(context,volume);
    }
  else
    {
      /* clean up and try again in one second */
      g_object_unref (context->monitor);
      context->monitor = g_volume_monitor_get ();
      g_timeout_add_seconds(1, (GSourceFunc) tvm_block_device_mount_retry, context);
    }
  return FALSE;
}

What's the best way to get this put into thunar-volman?

> I see that 0.8.1 has your patch.

Yes .. Even though I recommended do it. hah :S

> I think that better than waiting 1 second would be to try
> immediately and only then wait for a bit. I modified the
> code accordingly, ending up with

Looks better.. =)

> What's the best way to get this put into thunar-volman?

Clone the repo, commit your change with a good description
and make a patch from this commit. ;)

Then attach it here.

If you doubt, do it with a graphical interface as gitg- =)

Regards.

Created attachment 6191
Try to get GVolume right away and only if that fails wait for 1 second

This should change the total delay from 5 seconds per partition to at most 1 second for an entire physical device.

OK, done.

Hopefully this will get picked up faster than your patch.

No action yet that I can see. Does anyone know how to get this patch looked at? The current setup with its 5 second delay is getting annoying.

Changed in thunar-volman (Ubuntu):
assignee: nobody → Alvaro A.Cordoba (alvaroacordoba)
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Related blueprints

Remote bug watches

Bug watches keep track of this bug in other bug trackers.