I have a Seagate FreeAgent Go external USB hard drive that was mounted but mysteriously decided to reconnect itself:

Sep 30 15:07:06 feinman kernel: [243901.551604] usb 1-1.2: USB disconnect, device number 3
Sep 30 15:07:06 feinman kernel: [243901.553828] sd 6:0:0:0: [sdb] Synchronizing SCSI cache
Sep 30 15:07:06 feinman kernel: [243901.553893] sd 6:0:0:0: [sdb]  Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK
Sep 30 15:07:10 feinman kernel: [243905.336557] usb 1-1.2: new high-speed USB device number 4 using ehci_hcd
Sep 30 15:07:10 feinman kernel: [243905.431219] scsi7 : usb-storage 1-1.2:1.0
Sep 30 15:07:11 feinman kernel: [243906.427207] scsi 7:0:0:0: Direct-Access     Seagate  FreeAgent Go     0148 PQ: 0 ANSI: 4
Sep 30 15:07:11 feinman kernel: [243906.428303] sd 7:0:0:0: Attached scsi generic sg1 type 0
Sep 30 15:07:11 feinman kernel: [243906.430317] sd 7:0:0:0: [sdc] 625142447 512-byte logical blocks: (320 GB/298 GiB)
Sep 30 15:07:11 feinman kernel: [243906.430860] sd 7:0:0:0: [sdc] Write Protect is off
Sep 30 15:07:11 feinman kernel: [243906.430865] sd 7:0:0:0: [sdc] Mode Sense: 1c 00 00 00
Sep 30 15:07:11 feinman kernel: [243906.431386] sd 7:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Sep 30 15:07:11 feinman kernel: [243906.493674]  sdc: sdc1
Sep 30 15:07:11 feinman kernel: [243906.496109] sd 7:0:0:0: [sdc] Attached SCSI disk

It changed from sdb to sdc, causing a number of problems for me. What can I do to further track down the cause?

I thought it might be a problem with it sleeping but when I cat /sys/class/scsi_disk/6\:0\:0\:0/allow_restart, I see that it's already 1.

  • This issue has yet to repro, but, to be on the safe side, I've gone ahead and replaced it with something more appropriate for my task. – Sydius Oct 3 '12 at 4:52

If you need for whatever reason to access the device file (like /dev/sdb1), and not the mount point itself, you should be using UUID's instead of the more traditional "sd*" labels.

Type blkid to find what the labels of the drives are, for example the output may look like that:

/dev/sda3: UUID="e04c6aa5-4341-491f-8226-ddf79021115d" TYPE="ext3"

The device ID which will not change is then


You are guaranteed that the UUID is unique and specific. You can use it also in your fstab directly:

UUID=e04c6aa5-4341-491f-8226-ddf79021115d /data ext3 relatime,errors=remount-ro 0 1

I would suggest that either the whole computer is going to sleep, or perhaps the drive is not just being spun down but the whole thing is actually turned off (its controller is turning off, disconnecting from the USB bus in the process.

You would know if it's the former from other messages preceding the ones you posted. Is there a light on the device to tell you if it is the latter?

If neither of the above I'll also suggest that you try plugging into a different USB port on your computer. I've run into flaky ones in the past and moving devices has helped.

If you can't stop this from happening you may want to use the udev trick in the post you mentioned to enforce a different rule--one to be sure the drive is always given the same name, for example /dev/seagate, in order to avoid the complications you are seeing. For this you use the SYMLINK parameter rather than the RUN parameter. See this, for example.

Note--since it's not the known problem with allow_restart, this may well be a new bug.


If you assign a volume name to the partition in question it will always mount at the same point in the /media folder. Example if you call it 'BACKUP' then it's mount point will always be /media/BACKUP as long as there is no other device with the same name, or if you make the directory permanently in /media.

Scripts can then access the drive on /media/BACKUP reliably.

The actual device name can change if automount can not assign the usual device name for any reason. There may be another device mounted, or as in this case the device has lost it's connection for some reason and the old device name was not available again yet. A USB device that disconnects during normal use would be a serious problem, and the most likely cause is usually USB power problems. In this case it seems to have been a sleep or other power down operation that has triggered it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.