When installing the system with [coreos-installer](https://coreos.github.io/coreos-installer/) utility, **if the image contains an embedded Ignition configuration**, after the installation completes, the system will reboot. **Question**: Is there a way to override this behaviour to shutdown instead of rebooting? For example via kernel arguments or something similar? **Why**: The reason I want this behaviour is that I'm installing Fedora CoreOS via a live ISO on VirtualBox, and I have the Ignition configuration embedded into the ISO. Since the installation starts automatically, I don't have to input commands and shutdown manually. However, once the installation process completes, the system _reboots_, starting the live environment again and re-installing the system in a loop, until I manually stop the VM and "remove" the live ISO media. So I have to intercept when the installation is done, which is a little inconvenient.

I know that the **eject** command can be used to eject almost any hardware component attached, but can it be used to eject USB drives? Is it possible to eject USB drives and external HDD's with the **eject** command?

Lately when I write to an external drive formatted as NTFS* and then eject it, and wait a full minute before un-powering, then upon re-powering it won't auto-mount and manual mount attempts give an error. It wasn't like this before as it started around 2 months ago. An Ext4-formatted drive doesn't have this problem, and can even be hot-unplugged without issues (discovered by having a bad dock). Log excerpt: (Important point: $MFTMirr does not match $MFT)

Mar 10 14:42:39 confucius kernel: usb 4-1.1: new SuperSpeed USB device number 10 using xhci_hcd
Mar 10 14:42:39 confucius kernel: usb 4-1.1: New USB device found, idVendor=1058, idProduct=107c, bcdDevice=10.42
Mar 10 14:42:39 confucius kernel: usb 4-1.1: New USB device strings: Mfr=2, Product=3, SerialNumber=1
Mar 10 14:42:39 confucius kernel: usb 4-1.1: Product: Elements 107C
Mar 10 14:42:39 confucius kernel: usb 4-1.1: Manufacturer: Western Digital
Mar 10 14:42:39 confucius kernel: usb 4-1.1: SerialNumber: 574343344E30353730323533
Mar 10 14:42:39 confucius kernel: usb-storage 4-1.1:1.0: USB Mass Storage device detected
Mar 10 14:42:39 confucius kernel: scsi host5: usb-storage 4-1.1:1.0
Mar 10 14:42:39 confucius mtp-probe: checking bus 4, device 10: "/sys/devices/pci0000:00/0000:00:1c.0/0000:02:00.0/usb4/4-1/4-1.1"
Mar 10 14:42:39 confucius mtp-probe: bus: 4, device: 10 was not an MTP device
Mar 10 14:42:39 confucius mtp-probe: checking bus 4, device 10: "/sys/devices/pci0000:00/0000:00:1c.0/0000:02:00.0/usb4/4-1/4-1.1"
Mar 10 14:42:39 confucius mtp-probe: bus: 4, device: 10 was not an MTP device
Mar 10 14:42:40 confucius kernel: scsi 5:0:0:0: Direct-Access     WD       Elements 107C    1042 PQ: 0 ANSI: 6
Mar 10 14:42:40 confucius kernel: sd 5:0:0:0: Attached scsi generic sg4 type 0
Mar 10 14:42:40 confucius kernel: sd 5:0:0:0: [sdd] Spinning up disk...
Mar 10 14:42:49 confucius kernel: .........ready
Mar 10 14:42:49 confucius kernel: sd 5:0:0:0: [sdd] 732558336 4096-byte logical blocks: (3.00 TB/2.73 TiB)
Mar 10 14:42:49 confucius kernel: sd 5:0:0:0: [sdd] Write Protect is off
Mar 10 14:42:49 confucius kernel: sd 5:0:0:0: [sdd] No Caching mode page found
Mar 10 14:42:49 confucius kernel: sd 5:0:0:0: [sdd] Assuming drive cache: write through
Mar 10 14:42:49 confucius kernel: sdd: sdd1
Mar 10 14:42:49 confucius kernel: sd 5:0:0:0: [sdd] Attached SCSI disk
Mar 10 14:42:50 confucius kernel: ntfs3: Max link count 4000
Mar 10 14:42:50 confucius kernel: ntfs3: Enabled Linux POSIX ACLs support
Mar 10 14:42:50 confucius kernel: ntfs3: Read-only LZX/Xpress compression included
Mar 10 14:43:05 confucius kernel: ntfs3: sdd1: volume is dirty and "force" flag is not set!
Mar 10 14:43:05 confucius udisksd: $MFTMirr does not match $MFT (record 3).
Mar 10 14:43:05 confucius udisksd: Failed to mount '/dev/sdd1': Input/output error
Mar 10 14:43:05 confucius udisksd: NTFS is either inconsistent, or there is a hardware fault, or it's a
Mar 10 14:43:05 confucius udisksd: SoftRAID/FakeRAID hardware. In the first case run chkdsk /f on Windows
Mar 10 14:43:05 confucius udisksd: then reboot into Windows twice. The usage of the /f parameter is very
Mar 10 14:43:05 confucius udisksd: important! If the device is a SoftRAID/FakeRAID then first activate
Mar 10 14:43:05 confucius udisksd: it and mount a different device under the /dev/mapper/ directory, (e.g.
Mar 10 14:43:05 confucius udisksd: /dev/mapper/nvidia_eahaabcc1). Please see the 'dmraid' documentation
Mar 10 14:43:05 confucius udisksd: for more details.

Doing a disk check in Windows takes very long, I think in the order of 5 hours. This isn't a workable situation for us. Is there a way that I can troubleshoot this error in a reasonable manner (not taking 5 hours each time), or a way to just fix this by discarding/ignoring one of the $MFT? * drive shares data with Windows PCs --- Nemo has auto-mounting enabled. I eject with the eject button in Nemo (i.e. not umount)

I'd like to digitalize my CD collection. The quickest way to do this is to make a command that pulls in the CD drive, invokes abcde to rip and auto-eject the drive, and bind that command to a key. The only part needed to write that command that I don't know is what command can be used to pull in my CD drive automatically, basically an inverse of eject. Does anyone know such a command?

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**?

OS is Debian 10. File manager is Thunar. I've noticed that when I copy a few dozen gigabytes to my USB flash drive, the process only takes a minute or two. Then when I go to eject, the ejection process can take an hour or more. The USB drive is fine, it's just a lot of data to flush from the disk cache. The issue is this: I have no clue how much time is left on the ejection process. There **must** be a way to see the progress on this. Or better yet, is there a way to copy files to a USB flash drive and skip the disk cache entirely, just for that physical device? I know how to skip the disk cache for dd, but that is useless here. And of course, sync has no progress bar and as far as I know doesn't allow you specify a physical device.

For my work I'm preparing a live USB with Clonezilla. It runs a custom bash script to clone disks. This USB is going to be cloned to several other USBs so they can be used in multiple machines. It's not possible to run Clonezilla to RAM since the image to clone (22G) is in the USB. I want to replicate, in my script, the standard behavior of live Linux distributions installer, that ask to remove the USB medium and then press enter to reboot the machine. Example script using eject, but this doesn't seem right:

eject /dev/sdb
read -r -p 'Remove USB and press Enter' # not executed since the USB is no longer plugged
reboot

I want to be *very* sure that the USB(s) are removed safely, since they are from work, they are many, and of course taking the risk of ruining them is not an option. **What would be the best and safest way to do this?** Now, why so much effort for a seemingly trivial thing? The USBs are going to be deployed to hundreds of machines. All that can be automated is needed to gain time and avoid errors. The users need to check the cloning worked, hence the reboot. But if the USB is still plugged, the machine will boot it instead of the local OS. This question is related but I understand it doesn't apply to a live system. ___ This is the script that seems to do this, from a Lubuntu that I got unsquashing the filesystem.squashfs file from the ISO. I'm still trying to understand it, any help appreciated.

#! /bin/sh

# Author: Mathieu Trudel-Lapierre 
#         Tollef Fog Heen 
#         Marco Amadori 
#

PATH=/usr/sbin:/usr/bin:/sbin:/bin
NAME=casper
SCRIPTNAME=/etc/init.d/${NAME}
DO_SNAPSHOT=/sbin/${NAME}-snapshot

# Exit if system was not booted by casper
[ -f /run/.casper-boot ] || exit 0

# Exit if the system was booted from an ISO image rather than a physical CD
grep -qs find_iso= /proc/cmdline && exit 0

# Read configuration variable file if it is present
[ -r /etc/$NAME.conf ] && . /etc/$NAME.conf

# Try to cache everything we're likely to need after ejecting.  This
# is fragile and simple-minded, but our options are limited.
cache_path() {
    path="$1"

    if [ -d "$path" ]; then
        for f in $(find "$path" -type f); do
            cache_path "$f"
        done
    elif [ -f "$path" ] && [ ! -L "$path" ]; then
        if [ -x "$path" ]; then
            if file -L "$path" | grep -q 'dynamically linked'; then
                for lib in $(ldd "$path" | awk '{ print $3 }'); do
                    cache_path "$lib"
                done
            fi
        fi
        echo -n >> "$path"
    fi
}

do_stop ()
{
    logger -t ${NAME} "resyncing snapshots and caching reboot files..."

    if [ ! -z "${ROOTSNAP}" ]; then
        $DO_SNAPSHOT --resync-string="${ROOTSNAP}"
    fi

    if [ ! -z "${HOMESNAP}" ]; then
        $DO_SNAPSHOT --resync-string="${HOMESNAP}"
    fi

    # check for netboot
    if [ ! -z "${NETBOOT}" ] || grep -qs netboot /proc/cmdline || grep -qsi root=/dev/nfs /proc/cmdline  || grep -qsi root=/dev/cifs /proc/cmdline ; then
        return 0
    fi

    # Don't prompt to eject the SD card on Babbage board, where we reuse it
    # as a quasi-boot-floppy. Technically this uses a bit of ubiquity
    # (archdetect), but since this is mostly only relevant for
    # installations, who cares ...
    if type archdetect >/dev/null 2>&1; then
        subarch="$(archdetect)"
        case $subarch in
            arm*/imx51)
                return 0
                ;;
        esac
    fi

    prompt=1
    if grep -qs noprompt /proc/cmdline || [ -e /run/casper-no-prompt ]; then
        prompt=
    fi

    for path in $(which halt) $(which reboot) /bin/chvt /etc/rc?.d /etc/default $(which stty) /bin/plymouth /lib/plymouth /lib/*/plymouth /lib/systemd /etc/systemd /lib/*/libnss_files* /etc/nsswitch.conf /usr/share/fonts/truetype/dejavu/DejaVuSans.ttf /usr/share/fonts/truetype/ubuntu/Ubuntu-R.ttf /usr/share/fonts/truetype/ubuntu/UbuntuMono-R.ttf /etc/fonts/fonts.conf /etc/fonts/conf.d/60-latin.conf; do
        cache_path "$path"
    done

    device="$(grep " /cdrom " /proc/mounts | cut -d' ' -f1)" || device=
    # If /cdrom isn't mounted, don't try to eject it
    if [ -z "$device" ]; then
        return 0
    fi

    # If the device exists but can't be found in /sys/block, it's most likely a partition
    # so unmount it (lazy mode) and sync
    if [ -b "$device" ] && [ ! -f "/sys/block/$(basename $device)/removable" ]; then
        umount -l $device >/dev/null 2>&1
        sync
        # from now on operate on the partition's block device
        device=/dev/$(basename "$(readlink -f /sys/class/block/$(basename $device)/..)")
    fi

    # If we're still there, then we're probably a cdrom or other media
    # ship the eject if the kernel says the media isn't removable
    if [ "$(cat /sys/block/$(basename $device)/removable)" = "0" ]; then
        return 0
    fi

    # XXX - i18n
    MSG="Please remove the installation medium, then press ENTER: "
    MSG_FALLBACK="Please remove the installation medium, then reboot."

    if [ "$prompt" ]; then
        if [ -x /bin/plymouth ] && plymouth --ping; then
            chvt 63
            plymouth message --text="$MSG"
            clear > /dev/tty1
            echo $MSG_FALLBACK > /dev/tty1
        else
            stty sane  /dev/console
        fi
    fi

    eject -p -m $device >/dev/null 2>&1

    [ "$prompt" ] || return 0

    if [ -x /bin/plymouth ] && plymouth --ping; then
        plymouth watch-keystroke > /dev/null
    else
        read x < /dev/console
    fi
}

do_stop

I'm running Ubuntu Desktop 20.10 for my RPi 4 and have configured Plex to run on the intranet. I've got an externally powered 16Tb external hard drive with all the proper permissions to operate. The usage for this will be a media server in my vehicle (kids can watch media on long trips). The entire system is somewhat automated. Power on the car and it supplies power to the RPi 4, router, and external hard drive. RPi 4 Boots Ubuntu, automatically logs in to username "pi", /dev/sda1 (Elements) mounts automatically, firefox opens to the plex server localhost. The system works as intended once. ***What I'm running into:*** The entire system is hard shutdown when the car turns off. Therefore, the External Hard Drive is never unmounted or ejected. The folder "/media/pi/Elements" becomes unreadable and locked in the directory. When the /dev/sda1 mounts on the next power up, the new directory of the folder becomes "/media/pi/Elements1". Plex then has the mapping of media in a different location and the system wont work. In order to fix it, I have to ensure the External Hard Drive isn't plugged in, "cd" to the /media/pi directory, and run the "rm -R Elements" command and plug in the External Hard Drive again. I don't plan on having a dedicated screen, keyboard, and mouse in the car to reset this every time it happens unless I absolutely need to. ***Is there a way to lock the /dev/sda1 to the "Elements" folder permanently or possibly remove the need to unmount/eject the drive so the external drive directory doesn't lock and corrupt?***

After having read the section about zpool export in man zpool, I am worried somehow: > Exports the given pools from the system. All devices are marked as > exported, but are still considered in use by other subsystems. The > devices can be moved between systems (even those of different > endianness) and imported as long as a sufficient number of devices are > present. What does "but are still considered in use by other subsystems" mean? And what does "as long as a sufficient number of devices are present" mean? Background: I have a fairly complex backup script which replicates VM storage on a production server to a standby server, based on ZFS snapshots (to be precise, it is a system of various scripts on the host and in the VMs which work together to freeze the file systems in the VMs, take the ZFS snapshots, thaw the filesystems in the VMs, and replicate the snapshots to the standby server). This part is working like a charm. But actually, I need a sort of backup in addition to the replication. That is, I would like to backup the VM storage onto a disk which I can afterwards remove from the box where it is attached to, and store it safely at another location. I have thought thoroughly about the best method and have come to the following idea: - In the standby server, mount a SATA / SAS HDD tray so that I can plug and unplug HDDs there (or use one of its existing trays which are connected to its backplane). - At the standby server, plugin a new HDD and make a new ZPOOL, consisting of only one VDEV which consists only of that HDD. - Let the production server replicate its VM storage to that new ZPOOL *in addition* to the ZPOOL to which it replicates already. - After the replication, export the new ZPOOL, unplug the new HDD, and store it at a safe place. \*\* - At the standby server, plug in a second new HDD which also represents a ZPOOL, and repeat the previous two steps. \*\*\*\* - And so on ... (for example, daily replace the HDD currently attached to the standby server by the other one, or use 7 HDDs and rotate them on a weekly basis, etc.). \*\* This is the step which I am not comfortable with (after having read the section cited above). On one hand, it should be no problem to remove the HDD after the ZPOOL (whose only device it is) has been exported, because file systems get dismounted (and hence flushed) before the export. On the other hand, the manual says that this HDD will still be "considered in use by other subsystems" even after exporting the pool, which makes me believe that it is a bad idea to simply remove it in this situation. Therefore, I would like to know what this statement exactly means, and how I can make the HDD being considered **not** in use any more by other subsystems. \*\*\*\* I am aware that I'll have to put some effort into this. The plan is to create a script along with an appropriate udev rule to have the standby server recognize when the HDD is plugged in and to import the existing ZPOOL (the HDD will be connected directly via SATA-3 or SAS 12G, not via USB). But this is not part of this question. To summarize: What exactly does zpool export do, or, in other words, what steps do I need to perform before I can safely physically remove a HDD which is the only device in a ZPOOL after that ZPOOL has been exported?

Is there any way to completely caching for USB storage devices (I mean for example 32GB USB Hard Drives, NTFS, FAT32 formatted etc.), for Linux? **(like Microsoft's Windows)** People coming from **MS Windows** background are just removing the usb drive without ejecting it so the data corrupts. I have only found solution for a mounted drive, but I want to make it default so there will be no ejecting problem in the future. Thanks!

When working from command line I usually use an USB mass storage device with customary: sudo mount /dev/sde1 /mnt -o rw,umask=0000 ... use it... sudo umount /mnt This works fine *IF* you let the stick in its slot a few seconds AFTER umount has terminated (and shell prompt is back). Having a stick equipped with activity LED I can clearly see there's activity for a sizable amount of time AFTER umount (there's ample time to reach for the stick and yank it away AFTER prompt returns, but BEFORE it goes quiet). Waiting for activity to terminate ensures filesystem on stick is not corrupted. I suspect Device driver is still working. Question is: Which command (if any) could ensure device can be removed as soon as prompt returns? Note: eject does not work (for this).

I have a Cruzer disk on key which was recognized automatically by my RedHat6-beta OS. I removed it always using the GUI option "Safely remove", but one time by mistake I selected "Eject" and from then it is not recognized. I tried to mount it according to some Google's results, including editing the fstab file - no success. Does someone have an idea how to solve that? Thank you all in advance.

Up until Fedora 14 I was successfully using cdctl to enable/disable the CD/DVD eject button on my laptop (Thinkpad T410). Sadly it has stopped working now. I've consulted the methods discussed in these 2 questions: - disable cd/dvd button on linux laptop (ubuntu) - Disable the DVD eject button on a Thinkpad running Linux None of which have worked for me. So I turn back to cdctl to see if we can't fix what's broken with it, since it's worked for so long. ### Debugging the issue So starting with cdctl switches I notice that most things seem to work just fine. ### Examples These things work. *ejects the drive* $ cdctl -e *list capabilities* $ cdctl -k Tray close : 1 Tray open : 1 Can disable eject : 1 Selectable spin speed : 1 Is a jukebox : 0 Is multisession capable: 1 Can read the MCN (UPC) : 1 Can report media change: 1 Can play audio discs : 1 Can do a hard reset : 1 Can report drive status: 1 According to that list cdctl even thinks that it can enable/disable the eject button. > Can disable eject : 1 So I continue on with debugging the issue. ### Debugging cdctl So I figure lets do an strace on cdctl to see if it can shed some light on what's going on. $ strace cdctl -o1 ... brk(0) = 0x1371000 open("/dev/cdrom", O_RDONLY|O_NONBLOCK) = -1 ENOENT (No such file or directory) open("/dev/cd", O_RDONLY|O_NONBLOCK) = -1 ENOENT (No such file or directory) open("/dev/scd0", O_RDONLY|O_NONBLOCK) = -1 ENOENT (No such file or directory) open("/dev/sr0", O_RDONLY|O_NONBLOCK) = 3 ioctl(3, CDROM_LOCKDOOR, 0x1) = 0 close(3) = 0 exit_group(0) = ? +++ exited with 0 +++ Curiously it seems like cdctl thinks it's disabling the button. $ strace cdctl -o1 ioctl(3, CDROM_LOCKDOOR, 0x1) = 0 $ strace cdctl -o0 ioctl(3, CDROM_LOCKDOOR, 0) = 0 **NOTE:** If I understand this right, the return of a 0 means it was successful. One thing that caught my eye here was the list of devices that cdctl is attempting to interact with. So I thought "what if I try these devices with eject"? ### eject command One of the other commands I used to use years ago was the eject command to interact with the CD/DVD device. I noticed that this command also now has a similar named switch: $ eject --help -i, --manualeject toggle manual eject protection on/off ### Example $ eject -i 1 /dev/sr0 eject: CD-Drive may NOT be ejected with device button $ eject -i 0 /dev/sr0 eject: CD-Drive may be ejected with device button So eject too thinks that it's disabling the button, yet it isn't either. Using strace here I see the same system calls: $ strace eject -i 1 /dev/sr0 |& grep ioctl ioctl(3, CDROM_LOCKDOOR, 0x1) = 0 $ strace eject -i 0 /dev/sr0 |& grep ioctl ioctl(3, CDROM_LOCKDOOR, 0) = 0 So now I'm wondering if UDEV or something else is potentially blocking or taking ownership of device? Thoughts?

I was trying eject the USB stick drive from my Linux machine, when I accidentally clicked on wrong drive and ended up ejecting the SSD drive. Now that SSD also happens to the bootable SSD With stored data. After doing that I am not able to access file system icin. If I click on that drive from ubuntu UI, nothing happens. I haven't rebooted the machine since and I am able to view the data from the terminal shell. If I plug in another USB stick , it gets recognized but can't access that either. Is there a graceful way to come out of this situation without loosing data or without rebooting the machine ? Is there a graceful 'undo' command that I can use ?

### Problem After using the following command on my usb-drive (/dev/sdd): # physically plugging usb-drive in at /dev/sdd > umount /dev/sdd1 > eject /dev/sdd I am unable to undo this last action. How do I mount the drive again, programmatically? Physical access to the device is not an option, and neither is rebooting. --- ### What did you try? As you will see, the regular stuff won't work. > mount /dev/sdd1 mount: /dev/sdd1: can't find in /etc/fstab. We can see /dev/sdd1 does not exist anymore: > ls /dev/sdd* /dev/sdd So let's try to undo eject by using the same utility again: > eject --trayclose /dev/sdd > ls /dev/sdd* /dev/sdd This does not seem to do anything, so let's bind the usb-drive to the driver. > udevadm info /dev/sdd | grep DEVPATH E: DEVPATH=/devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1:1.0/host6/target6:0:0/6:0:0:0/block/sdd > echo -n "1-1:1.0" > /sys/bus/usb/drivers/usb-storage/unbind > ls -d /sys/bus/usb/drivers/usb-storage/1-1\:1.0 ls: cannot access '/sys/bus/usb/drivers/usb-storage/1-1:1.0': No such file or directory > echo -n "1-1:1.0" > /sys/bus/usb/drivers/usb-storage/bind > ls -d /sys/bus/usb/drivers/usb-storage/1-1\:1.0 1-1:1.0 Ok, so the unbind and bind worked. This is not the problem nor solution. Also, the device still seems to be powered. Let's try to trigger something. > udevadm trigger --name-match=/dev/sdd This does not seem to solve the problem either. Now let's try to read the partition table again, because /dev/sdd exists but /dev/sdd1 not. I found three different methods of achieving this: > partprobe /dev/sdd Error: Error opening /dev/sdd: No medium found > hdparm -z /dev/sdd /dev/sdd: re-reading partition table > partx -u /dev/sdd partx: cannot open /dev/sdd: No medium found > ls /dev/sdd* /dev/sdd Still no /dev/sdd1. Maybe try some rescan: > echo 1 > /sys/block/sdd/device/rescan > ls /dev/sdd* /dev/sdd Still nothing, let's verify what fdisk says about this: > fdisk -l | grep sdd Okay, nothing. Let's try to reset the usb-drive then. > echo 0 > /sys/bus/usb/devices/1-1\:1.0/authorized > echo 1 > /sys/bus/usb/devices/1-1\:1.0/authorized > ls /dev/sdd* ls: cannot access '/dev/sdd*': No such file or directory This made it worse, trial and error failed. I give up. What am I missing here? --- ### \*facepalm* why eject at all?! Well, I need this solution for actually another problem, in which Linux does not want to mount the usb-drive anymore after i/o errors occurred. Since physically plugging the usb-drive back in works for that problem, I need to know how to do this programmatically. And even if this will not solve my original problem, I want to know how to undo eject. --- ### EDIT: More details Here is an additional source from [kernel.org on usb hotplugging](https://www.kernel.org/doc/html/v4.13/driver-api/usb/hotplug.html) , telling what should be happening: > - Find a driver that can handle the device. That may involve loading a kernel module; newer drivers can use module-init-tools to publish their device (and class) support to user utilities. > - Bind a driver to that device. Bus frameworks do that using a device driver’s probe() routine. > - Tell other subsystems to configure the new device. Print queues may need to be enabled, networks brought up, disk partitions mounted, and so on. In some cases these will be driver-specific actions. It seems that the last step may still need to be done. Backed by further info on the state of the usb-drive after it is "ejected", showing that the usb-drive is powered and Linux can communicate with it: > cat /sys/block/sdd/device/state running > cat /sys/block/sdd/device/power/runtime_status active > cat /sys/block/sdd/device/power/runtime_suspended_time 0 > cat /sys/block/sdd/device/power/control on

On my Mac, when I 'eject' a network-mounted share, my Mac presents me with the following message, and attempts to get processes to close open file handles and cleanly dismount the share. My question is, how exactly does it accomplish that? I suppose it enumerates file handles open with my share's path, and then sends some kind of signal to the processes that own those file handles? Just a guess, please fill me in, I'm very curious about it. I thought about asking this over on the Apple stack exchange, but I'm guessing this is actually a more generally-applicable UNIX question. If I'm wrong and macOS has a special/new way of doing this and this question needs to be closed and re-opened there, just let me know. EDIT: added screenshot.

The problem = I've got a simple question: what's the difference between ejecting flash drive using GNOME Files (formerly known as Nautilus ) button (see image below) and umount command? Before you will read rest of this question I encourage you to think if you expect any difference between results of clicking eject button in GNOME Files and typing umount command? If yes, then what's the difference? If no, then read on... --- 1st try: GNOME Files eject = When I insert my flash drive to my computer's USB socket, Debian automatically mounts it, which is reflected both in GNOME Files : and command line using e.g. df command: me@host:~$ df -h Filesystem Size Used Avail Use% Mounted on (...) /dev/sdf1 3,6G 3,6G 0 100% /media/me/Debian 9.1.0 amd64 1 or blkid command: root@host:~# blkid (...) /dev/sdf1: UUID="XXXX-XX-XX-XX-XX-XX-XX" LABEL="Debian 9.1.0 amd64 1" TYPE="iso9660" PTUUID="XXXXXXXX" PTTYPE="dos" PARTUUID="XXXXXXXX-XX" /dev/sdf2: SEC_TYPE="msdos" UUID="XXXX-XXXX" TYPE="vfat" PARTUUID="XXXXXXXX-XX" When I click eject button marked with a red circle: and I run those commands once again, there is no sdf string in commands' output (which is probably what I should expect after ejecting /dev/sdf1): root@host:~# df -h | grep sdf root@host:~# df -ah | grep sdf root@host:~# Note that I added -a (--all) flag to df command and I got the same (empty) result. root@host:~# blkid | grep sdf root@host:~# Note that now I'm unable to remount /dev/sdf1 without reinserting my flash drive: root@host:~# mkdir -p /mnt/test root@host:~# mount /dev/sdf1 /mnt/test mount: special device /dev/sdf1 does not exist --- 2nd try: umount command = Now repeat the hole procedure with only changing the way I unmount my flash drive. Instead of clicking eject button, I type: umount /dev/sdf1 Here is the result of df : root@host:~# df -h | grep sdf root@host:~# df -ah | grep sdf root@host:~# df result is probably as expected because it's the same as above... but here comes the blkid : root@host:~# blkid | grep sdf /dev/sdf1: UUID="XXXX-XX-XX-XX-XX-XX-XX" LABEL="Debian 9.1.0 amd64 1" TYPE="iso9660" PTUUID="XXXXXXXX" PTTYPE="dos" PARTUUID="XXXXXXXX-XX" /dev/sdf2: SEC_TYPE="msdos" UUID="XXXX-XXXX" TYPE="vfat" PARTUUID="XXXXXXXX-XX" Note that remounting works fine in opposite to the previous try: root@host:~# df -h | grep sdf root@host:~# mkdir -p /mnt/test root@host:~# ls /mnt/test | wc -l 0 root@host:~# mount /dev/sdf1 /mnt/test mount: /dev/sdf1 is write-protected, mounting read-only root@host:~# ls /mnt/test | wc -l 24 --- The question = Why is that? What is the precise, underlying reason of above differences in blkid output? Does GNOME Files do something more than umount command? It seems to me that GNOME File eject button is kind of 'permanent' unmount. Why?

I am trying to close and eject cd from the commandline. The purpose is to rip a lot of audio cds with abcde . I use eject and eject -t commands to open and close the cd drive. I mount my cdrom with this line in /etc/fstab: /dev/sr0 /media/cdrom0 udf,iso9660 user,noauto 0 0 The problem is that ejecting the cd means also to unmount it. After the unmount, there is no way to close it. When I start the computer, eject -t works and closes the tray. But if I open it again (with eject) eject -t does not find /dev/cdrom because it is not mounted (the tray is open and there is no cd mounted). Someone sees a simple solution? P-S : Debian (unstable) system.

In Ubuntu 16.04, I try to safely remove the flash disk from the command line. When I run the following script (from the https://unix.stackexchange.com/questions/178638/eject-safely-remove-vs-umount) : udisksctl unmount -b /dev/sdb1 udisksctl power-off -b /dev/sdb1 It says: Error powering off drive: Error opening /sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.1/remove: No such file or directory (udisks-error-quark, 0) When I type these commands from the keyboard, I don't get the error. Why, and how should I make the script running?

I have a USB external hard drive with several partitions, and I cannot spin down the hard drive to get it to eject. Any suggestions? I unmounted all partitions through Nautilus, but the drive is still spinning. Nautilus does not seem to have other options besides unmount in Ubuntu 13.10. After ensuring that no drives are mounted, I tried the udisks to detach the drive, but I get the following error: [lucas@lucas-ThinkPad-W520]~$ mount | grep ^'/dev' /dev/sda5 on / type ext4 (rw,errors=remount-ro) [lucas@lucas-ThinkPad-W520]~$ udisks --detach /dev/sdb Detach failed: One or more partitions are busy on /dev/sdb [lucas@lucas-ThinkPad-W520]~$ How can other partitions be busy if mount | grep ^'/dev' does not return any of my /dev/sdb partitions? Is there an easy way to detach my external hard drive? A simple solution would be nice... I am using Ubuntu 13.10 and my external hard drive is a backup my internal hard drive, setup via Clonezilla. **UPDATE** I tried lsof, results below: [lucas@lucas-ThinkPad-W520]~$ lsof /dev/sdb sdb sdb1 sdb2 sdb3 sdb4 sdb5 sdb6 [lucas@lucas-ThinkPad-W520]~$ lsof /dev/sdb [lucas@lucas-ThinkPad-W520]~$ lsof /dev/sdb1 [lucas@lucas-ThinkPad-W520]~$ lsof /dev/sdb2 [lucas@lucas-ThinkPad-W520]~$ lsof /dev/sdb3 [lucas@lucas-ThinkPad-W520]~$ lsof /dev/sdb4 [lucas@lucas-ThinkPad-W520]~$ lsof /dev/sdb5 [lucas@lucas-ThinkPad-W520]~$ lsof /dev/sdb6 [lucas@lucas-ThinkPad-W520]~$