Bug 747114 - Cannot umount USB devices
Summary: Cannot umount USB devices
Alias: None
Product: Fedora
Classification: Fedora
Component: dbus
Version: 16
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: David Zeuthen
QA Contact: Fedora Extras Quality Assurance
: 826519 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2011-10-18 20:36 UTC by Germano Massullo
Modified: 2013-03-06 04:08 UTC (History)
18 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2013-02-14 01:04:48 UTC

Attachments (Terms of Use)
Full "sudo lshw" report for mcomment #1 (17.89 KB, text/plain)
2012-03-05 19:09 UTC, Martin Gregorie
no flags Details

Description Germano Massullo 2011-10-18 20:36:33 UTC
A lot of times, when I paste medium-large files into USB mass storages, I can see that KDE immediately tells me that the copy is complete. Looking the activity led of Kingston usb mass storage, I can see that the computer is not copying. When finally I click on umount button, the computer starts copying the files inside the USB mass storage.. But, during this copy, I have the following system error:

org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

In the past I saw that after this error. the USB mass storage seemed umounted. If I tried to remount it without physically removing it from USB port, the mount failed. To make the computer read again the USB mass storage, you had to physically remove it and mount it again. After that you could see that the copied data was corrupted.
Instead, today, when I had the same problem, after the umount, I was able to remount it without physically removing it, and the data seemed okay.
This bug happened also with other USB mass storages like pen drives and Android phones on both my computers.

To check if it was a KDE problem, I tried to copy and umount from the console (as normal user), but I had the identical error message

With Fedora 14 this did not happen

Comment 1 Martin Gregorie 2012-03-05 19:08:30 UTC
I'm seeing the same problem with Fedora 16. 

I make backups to a USB disk attached to my house server using rsync. The server is never logged in from its console, so X-server isn't used (the whole backup process is done by running bash scripts from the command line. The overall sequence looks like this:

- plug the USB disk into a USB port
- login as root via ssh from another Linux box running Fedora 15.
- run a series of backups
- logout of root
- unplug the USB drive and put it back in its firesafe.

Each backup is carried out by a bash script that does the following steps:
- mounts the USB drive via its label
- does the backup with rsync
- obtains the device name with: 
     usb_device=$(df | grep "$usb_disk" | cut -d' ' -f1)

- unmounts the drive
- runs fsck as:
     fsck $usb_device

However, fsck always fails with a message saying that the disk is mounted, which it isn't, as running "ls -a /mountpoint" shows clearly that no filing system is mounted in that directory (it contains '.', '..' and nothing else.

The hardware etc. details:
           AMD Athlon(tm) 64 X2 Dual Core Processor 6000+ w/4Gb RAM
           motherboard is a Gigabyte revision 0 GA-M68M-S2P
           Linux version 3.2.7-1.fc16.i686.PAE
           (gcc version 4.6.2 20111027 (Red Hat 4.6.2-1) 
           (GCC) ) #1 SMP Tue Feb 21 01:30:59 UTC 2012

Comment 2 Martin Gregorie 2012-03-05 19:09:45 UTC
Created attachment 567719 [details]
Full "sudo lshw" report for mcomment #1

Comment 3 Konrad Karl 2012-03-28 15:47:59 UTC
try:  (on a fully uptodate F16 x86_64, dont know about i686)

systemctl disable cups.service and reboot. 

after that umount behaves normally again here.

systemctl start cups.service is enough to get the umount problems back.

I am using this small script using an USB memory stick (with LED :-)
luks/ext4 on /dev/sdb1

No idea so far how cups prevents unmounting. by mere luck I had a
spare identical system which was last updated on Mar 19 which behaved
OK. Then I updated in small chunks and the problems become visible when
cups update was involved..... grr.

Hope this helps,

----- snip -----
echo "luksOpen..."
echo -n somepassword |cryptsetup luksOpen /dev/sdb1 cmemstick
[ $ret -ne 0 ] && { echo "luksOpen fail"; exit 1; }
echo "mount..."
mkdir -p /a
mount /dev/mapper/cmemstick /a || { echo "mount fail"; exit 1; }
echo "copying..."
cp /tmp/somebigfile /a/foobar
echo "umount..."
umount /a
echo "luksClose..."
cryptsetup luksClose cmemstick || { echo "luksClose fail"; exit 1; }
echo "dmsetup table..."
dmsetup table |grep -w cmemstick
echo OK

Comment 4 Konrad Karl 2012-03-28 16:20:34 UTC
BTW, the problem was introduced between cups-1.5.2-1 (my previous installed version and cups-1.5.2-2 from koji.

all later koji versions up to 1.5.2-8 from today cause the umount problems


Comment 5 Tim Waugh 2012-03-29 09:12:14 UTC
Could this be related to bug #807672?

Comment 6 Adam Williamson 2012-03-29 12:49:24 UTC
*** Bug 806909 has been marked as a duplicate of this bug. ***

Comment 7 Adam Williamson 2012-03-29 12:51:54 UTC
Tim: it sounds pretty likely.

Can those hitting this please try disabling PrivateTmp for cupsd - copy /lib/systemd/system/cupsd.service to /etc/systemd/system/cupsd.service and change PrivateTmp=yes to PrivateTmp=no in the copy in /etc - and see if that solves it?

Fedora Bugzappers volunteer triage team

Comment 8 Adam Williamson 2012-03-29 12:52:55 UTC
Tim: note that wwoods was saying yesterday on IRC that he had weird issues with loop devices that went away when he killed cupsd, so that might be another consequence.

Comment 9 Tim Waugh 2012-03-29 14:11:12 UTC
FWIW I changed the test update for cups (cups-1.5.2-8.1.fc16) earlier today so that it removes the PrivateTmp line altogether.

Comment 10 Martin Gregorie 2012-03-29 16:32:28 UTC
I've just tried again with on my Fedora 16 system, fully patched as of 2012-03-23 at approximately 19:00. 

This system does not a copy of cupsd.service, only cups.service and this does not
contain a PrivateTmp property. There is nothing in /etc/sysconfig that would seem to be connected with CUPS

As an elaboration of what I see at the point when fsck thinks the disk is busy:

- My script starts by creating a directory in /mnt which I set to the same 
  name as the partition label, i.e. Formac_1, and mounts the disk there, 
  using the partition label to mount it, so the diskmis mounted as 

- After the backup, the script unmounts the disk and deletes the directory
  it created using the command "rmdir Formac_1" before running fsck. After
  the failure the /mnt directory is empty, so the umount must have 
  successfully disconnected the disk from the filing system or rmdir would 
  have failed. Today the USB disk was mounted as /dev/sdc and, after fsck
  failed, both /dev/sdc and /dev/sdc1 were shown by "ls /dev/sd*".

- At this point I unplugged the USB drive, waited 5 seconds, and plugged it in
  again. After this both /dev/sdc and /dev/sdc1 were no longer present and
  the disk had been recognised and attached as /dev/sdd with /dev/sdd1 as the
  partition. cfdisk showed it as expected (partition label Formac_1, partition
  size correct and fsck reported the disk as not having been unmounted cleanly,
  ran a check and didn't find any errors.

Comment 11 Tim Waugh 2012-03-30 08:26:21 UTC
Martin: what does 'rpm -q cups' say?

Comment 12 Tim Waugh 2012-03-30 08:32:16 UTC
*** Bug 808109 has been marked as a duplicate of this bug. ***

Comment 13 Tim Waugh 2012-03-30 08:33:04 UTC
*** Bug 808121 has been marked as a duplicate of this bug. ***

Comment 14 Martin Gregorie 2012-03-30 09:38:38 UTC
Tim, 'rpm -q cups' says 'cups-1.5.2-1.fc16.i686'

Comment 15 Terry Barnaby 2012-03-30 10:00:46 UTC

Had no effect on my system.


Comment 16 Tim Waugh 2012-03-30 10:36:01 UTC
Martin Gregorie and Terry Barnaby seem to be seeing some other issue, whereas the PrivateTmp thing is certainly the cause of the issue Konrad Karl is seeing (cups-1.5.2-1.fc16 is the last version that did *not* have PrivateTmp=true).

I was added in to this bug report in the last week, and now that I look at the date of the original report I can see that it pre-dates the PrivateTmp=true issue by quite some time.  This suggests there is some other underlying issue to be discovered.

Comment 17 Terry Barnaby 2012-03-30 10:46:04 UTC
I agree, I believe the cups thing is just showing up a kernel bug.
There is no way a process should be able to stop umount working correctly, at least I hope !
I remember I had a similar, but slightly different, issue with USB disks when I first installed F16. I suspect some kernel fixes/bugIntroductions is going on in this area ...

Comment 18 Adam Williamson 2012-03-30 16:10:49 UTC
Tim: then should we un-dupe one of the 'dupes', make the other 'dupe' a dupe of that, and edit the update to say it fixes that bug, leaving this one open?

Fedora Bugzappers volunteer triage team

Comment 19 Tim Waugh 2012-04-02 12:15:10 UTC
Yes.  Resetting component back as it was before comment #3.

Comment 20 Germano Massullo 2012-06-06 09:01:05 UTC
Another example (this time on Fedora 17)
20 minutes ago, I started copying 7gb of data into my new 32gb microsd card. After a few minutes KDE notification system told me the file transfer has been completed, but the led on sdcard reader indicated the opposite. Only a few minutes later, the led on card reader stopped bliking. So why KDE indicates the system finished the file transfer when it was not true?

Comment 21 Kevin Kofler 2012-06-06 17:21:22 UTC
Re comment #20, this is called a write cache. If you aren't getting the D-Bus error on unmount anymore, there's no bug!

Comment 22 Tim Waugh 2012-09-19 08:52:53 UTC
*** Bug 826519 has been marked as a duplicate of this bug. ***

Comment 23 Fedora End Of Life 2013-01-16 22:33:25 UTC
This message is a reminder that Fedora 16 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 16. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '16'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 16's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 16 is end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" and open it against that version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 

Comment 24 Fedora End Of Life 2013-02-14 01:04:53 UTC
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.