disk auto-mounter leaves unused directories in /media/<user>

Bug #1043772 reported by Rocko
28
This bug affects 4 people
Affects Status Importance Assigned to Milestone
udisks
In Progress
Low
udisks2 (Ubuntu)
Fix Released
Medium
Martin Pitt

Bug Description

If I have an external disk with the name "disk", in Quantal it now normally gets mounted at /media/rocko/disk.

However, if the disk is not cleanly unmounted (eg if X crashes), the /media/rocko/disk folder persists and the new time it is auto-mounted at /media/rocko/disk1, and then /media/rocko/disk2, etc.

This used to be a problem when disks were mounted at eg /media/disk, then /media/disk_, then /media/disk__, but this bug was fixed a while ago.

So the program that auto-mounts should really check if /media/<user>/<diskname> exists and is empty as part of the mount process.

Apologies if gnome-media is not the correct package for this bug.

ProblemType: Bug
DistroRelease: Ubuntu 12.10
Package: gnome-media 3.4.0-0ubuntu4
ProcVersionSignature: Ubuntu 3.5.0-11.11-generic 3.5.2
Uname: Linux 3.5.0-11-generic x86_64
ApportVersion: 2.5.1-0ubuntu3
Architecture: amd64
Date: Thu Aug 30 19:21:54 2012
InstallationMedia: Ubuntu 12.10 "Quantal Quetzal" - Alpha amd64 (20120606.2)
ProcEnviron:
 LANGUAGE=en_AU:en
 TERM=xterm
 PATH=(custom, no user)
 LANG=en_AU.UTF-8
 SHELL=/bin/bash
SourcePackage: gnome-media
UpgradeStatus: No upgrade log present (probably fresh install)

Related branches

Revision history for this message
Rocko (rockorequin) wrote :
Revision history for this message
Sebastien Bacher (seb128) wrote :

Hey Martin, could you have a look?

affects: gnome-media (Ubuntu) → udisks2 (Ubuntu)
Changed in udisks2 (Ubuntu):
assignee: nobody → Martin Pitt (pitti)
Revision history for this message
Doug McMahon (mc3man) wrote :

This happens with all mounts at /media/<username> / & includes doing a restart or shut down with the volume still mounted.
Obviously wasn't an issue when at /run/media/<username>, nor previously when at /media (as far as restarts/shutdowns with volumes mounted

Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in udisks2 (Ubuntu):
status: New → Confirmed
Martin Pitt (pitti)
Changed in udisks2 (Ubuntu):
status: Confirmed → Triaged
importance: Undecided → Low
Revision history for this message
In , Martin Pitt (pitti) wrote :

When you have an udisks mount and shut down the computer, or just udisks (during a package upgrade, or due to a crash), the mount point (in /media/ or /run/media/user/) is not automatically cleaned up. This is not such a big deal for mount points in /run, but upstream supports the /media/ case as well, and for long-running systems the "clean /run on boot" only helps to some degree as well.

calculate_mount_point() only checks whether a mount point already exists, not if there is something mounted on it already. So in above situations, you end up with an unused /run/media/user/mylabel/, and the device is instead mounted to /run/media/user/mylabel1/.

I think it would be better to check G_FILE_ATTRIBUTE_UNIX_IS_MOUNTPOINT if the directory already exists, and re-use it if it's not a mount point and the directory is empty. An easier implementation might be to try and g_remove() the mount point, which will fail if it is non-empty or mounted. If that succeeds, we re-create the mountpoint with up-to-date permissions.

Revision history for this message
In , Martin Pitt (pitti) wrote :

Created attachment 66602
patch and test case

This adds a test case and a fix. OK to push?

Revision history for this message
Martin Pitt (pitti) wrote :

Patch sent to upstream bug for review.

Changed in udisks2 (Ubuntu):
status: Triaged → In Progress
Revision history for this message
In , Zeuthen (zeuthen) wrote :

I don't think this is a good idea - the directory could have been created by the user for e.g. an /etc/fstab mount point.

Just use /run/media or put /media on tmpfs and you won't have this problem.

Revision history for this message
In , Martin Pitt (pitti) wrote :

> Just use /run/media or put /media on tmpfs and you won't have this problem.

You'd have it less, but it's still an issue on long-running systems.

So if we don't use rmdir() but instead add a "is mountpoint" and "is empty" test, would you be ok with that?

Changed in udisks:
importance: Unknown → Low
status: Unknown → In Progress
Revision history for this message
Martin Pitt (pitti) wrote :

Ah, this is a consequence of moving to non-tmpfs for /media, but leaving /run/udisks2/ on a tmpfs; we need to move the latter to /var/lib as well. I'll commit a test case upstream and adjust our "use /media" patch in Debian.

Changed in udisks2 (Ubuntu):
importance: Low → Medium
Revision history for this message
Martin Pitt (pitti) wrote :

Fixed in Debian packaging git.

Changed in udisks2 (Ubuntu):
status: In Progress → Fix Committed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package udisks2 - 1.99.0-4

---------------
udisks2 (1.99.0-4) experimental; urgency=low

  * Add debian/local/udisks2-inhibit: Hack to disallow udisks2 mount
    operations for anyone but root while a program is running. This is similar
    to udisks 1.x's "udisks --inhibit .." command. Install it into
    /usr/lib/udisks2/.
  * mount_in_media.patch: As on Debian and Ubuntu /media is not currently a
    tmpfs, we need to put the "mounted-fs" file to a persistent path as well.
    Otherwise udisks does not clean up old mount points that it created after
    a reboot. (LP: #1043772)
  * debian/udisks2.postinst: Migrate the mounted-fs file on upgrades.
  * Update 00git_testsuite.patch: Pull latest test suite updates from trunk.
    This now covers handling of existing mount points, and mounting read-only
    devices, which reproduces LP #435192.
 -- Martin Pitt <email address hidden> Fri, 07 Sep 2012 16:17:57 +0200

Changed in udisks2 (Ubuntu):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

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