60

I'm using Ubuntu 12.04, and when I rigth click on a my flash drive icon (in the Unity left bar) I get two options that have me confused: eject and safely remove.
The closer I came to an answer was this forum thread, which concludes that (for a flash drive) they are both equal and also equivalent to use the umount command. However, this last assertion seems to be false.
If I use umount from the console to unmount my flash dive, and then I use the command lsblk, I still see my device (with nothing under MOUNTPOINT, of course). On the other hand, if I eject or safely remove my flash drive, lsblk does not list it anymore.

So, my question is, what would be the console command/commands that would really reproduce the behaviour of eject and safely remove?

LGenzelis
  • 721
  • 1
  • 6
  • 8

2 Answers2

94

If you are using systemd then use udisksctl utility with power-off option:

power-off

Arranges for the drive to be safely removed and powered off. On the OS side this includes ensuring that no process is using the drive, then requesting that in-flight buffers and caches are committed to stable storage.

I would recommend first to unmount all filesystems on that usb. This can be done also with udisksctl, so steps would be:

udisksctl unmount -b /dev/sda1
udisksctl power-off -b /dev/sda

If you are not using systemd then old good udisks should work:

udisks --unmount /dev/sda1
udisks --detach /dev/sda
Community
  • 1
jimmij
  • 47,140
  • Oh man - i only now realized the question was how to do this from the command-line - not what is the difference between one thing and another. i wont delete my answer because i think it offers some perspective - but yours is the right answer for linux systems, i think (dont even know if this is a bsd relevant question anyway...). – mikeserv Jan 12 '15 at 09:17
  • 4
    udisksctl power-off appears not to be equivalent to the "safely remove" in my case. With a micro-SD card in my internal card reader, device /dev/sdd, no mounted filesystems, when I use the command udisksctl power-off -b /dev/sdd, the reader's LED turns off, but then the whole device becomes inoperable, I guess because it, well, literally powered off entirely. I have to reboot the system for it to become usable again. – ack Jan 16 '16 at 09:03
  • 1
    For @ack : you can disable/enable the (possibly internal) hub where the reader is connected. Because it's a hub, it will also drop and then re-enumerate everything, including the missing device. Hope you can read this example: udisksctl power-off -b /dev/mmcblk0 mmc0: card aaaa removed usb 3-1.8: USB disconnect, device number 41 cd /sys/bus/usb/devices/usb3/3-1 echo 0 > authorized echo 1 > authorized hub 3-1:1.0: USB hub found usb 3-1: authorized to connect usb 3-1.8: New USB device found, idVendor=0bda, idProduct=0129 mmc0: new ultra high speed SDR50 SDHC card at address aaaa – A.B Sep 18 '17 at 19:03
  • Does udisks and udisksctl exists on unix systems? @jimmij – alper Jun 06 '20 at 02:36
20

umount is perfectly safe for the disk. Once you've done that you have successfully unmounted the filesystem and you needn't worry along those lines. The primary difference between eject and umount doesn't concern the disk at all - rather it is about the USB port's 5v power output.

After umount you can still see your disk listed in lsblk because it is still powered on and attached. umount an internal hard disk's file-system and you'll see the same behavior for the same reason. But when you eject a USB device you power it down and it ceases to draw the 5v it would typically - I think it trickles down to .5v but that class happened a long time ago.

lsblk -f /dev/disk/by-id/usb-SanDisk_Cruzer_200522428118F4325EC2-0:0
NAME   FSTYPE LABEL   UUID                                 MOUNTPOINT
sdd                                                        
├─sdd1 vfat   USBESP  3AD6-C7CC                            
└─sdd2 ext4   USBROOT 5afbfe93-6955-44ec-8c4f-cf381f8ef174

Here is its usb bus path...

cat /sys/bus/usb/devices/5-3/manufacturer 
SanDisk

Even though I almost never mount it, it's been plugged in and blinking for a long time, I guess...

cat /sys/bus/usb/devices/5-3/power/{level,connected_duration}
on
1777877440

I should do something about that:

echo 1 | sudo tee /sys/bus/usb/devices/5-3/remove

Now I'll have a look at it again...

cat /sys/bus/usb/devices/5-3/power/level                            
cat: /sys/bus/usb/devices/5-3/power/level: No such file or directory

Hmmm...

lsblk -f /dev/disk/by-id/usb-SanDisk_Cruzer_200522428118F4325EC2-0:0
lsblk: /dev/disk/by-id/usb-SanDisk_Cruzer_200522428118F4325EC2-0:0: not a block device
mikeserv
  • 58,310
  • 1
    Thanks. After umount an external hdd, is it safe to remove the external hdd from the computer? – Tim Mar 04 '15 at 21:05
  • 2
    I don't think umount is equivalent to "safely remove", and neither is udisksctl power-off, please see my comment on the other answer. Compare with the behaviour in Windows for example. My guess is that Windows does a bit more than just 'unmount' the filesystems on the device. I have observed it spinning down external hard drives, turning off LEDs on card readers (without subsequently rendering the device unusable unless replugged or the system rebooted), etc. – ack Jan 16 '16 at 09:15
  • 2
    @ack - what does Windows have to do with this? and why are you guessing? and you do not have to reboot for it to become usable again. you umount it. then you power it off. and i never suggested anything regarding udiskctl one way or the other. – mikeserv Jan 20 '16 at 23:04
  • 2
    @mikeserv "Safely remove hardware" is the expression used in Windows. It is likely that other systems copied that phrase because of user familiarity. It is important to distinguish it from mere filesystem unmounting. An example of where this matters greatly is when the OS is uncertain about a storage device's write caching. I've personally experienced quite significant data loss (corrupted superblock and files) after merely unmounting and unplugging an external hard disk. I later found out that Linux had warned about this: "No Caching mode page found", "Assuming drive cache: write through". – ack Jan 22 '16 at 15:57
  • 1
    @ack - no, that's not important. your problem is probably your acpi. it doesn't have anything to do with operating system exactly - just that your board manufacturer only wrote drivers for one os. those little multicard devices require fairly low-level access to the card target - they have to be able to do stuff like eye-fi. they're not block devices - they're character devices. they're nothing at all like usb disks. the board-rom has to handle them separately, and if your vendor poorly supports it (its not unusual - try booting from one) youre out of luck. but its not linux's problem. – mikeserv Jan 22 '16 at 16:44
  • @mikeserv about what Windows has to do with this, I'd say it's a point of comparison and especially with actual HDDs it's not a bad idea to compare behaviors and for example making your you actiually park the reading head before you remove power, not sure if umount does that. – My1 Dec 10 '21 at 07:14
  • When you ran cat /sys/bus/usb/devices/5-3/manufacturer, how were you able to tell that 5-3 was the correct sysfs subfolder? Or did you check them all until you found the right one? – AJM Aug 07 '23 at 11:55