I have some USB-attached HDDs connected to a laptop running Debian 12. Recently I had a problem ejecting them using the file manager and the Disks app, something on the drives was still "in use" even when I had closed every open application.

Since then I've learned of the existence of 'lsof', but at the time my experience of Windows and macOS suggested that, under these kinds of circumstances, performing a shutdown will clear the holds on the drives and cleanly eject them during the process. So as I didn't know what else to do I shut down Debian using the menu.

The last thing I saw before the laptop powered off was a series of messages reporting that both external drives had failed to unmount cleanly, and this was confirmed by the nasty clunking noise from the drives indicating sudden parking of the drive heads when the USB power was unexpectedly removed. Following this incident I've had to recover some several GBs of files from each drive.

Obviously this wasn't a very pleasant experience, so I'd like to know what steps I can take to make Debian act more responsibly in future.

IM(H)O part of the problem was that the first thing to get torn down during the shutdown was the GUI, which meant that there was no way for a user to intervene if there was a problem with ejecting the drives cleanly. Windows and macOS will prompt the user using the GUI if there's a problem that means a drive can't be automatically ejected cleanly during a shutdown, giving users an opportunity to abort. Can I modify the Debian shutdown sequence to keep the GUI available until all drives are safely ejected?

I'd welcome any other suggestions to make Debian less likely to cause data loss on external drives during shutdown.

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 5/1/26 00:30, coffeeforblood.pardon117@slmail.me wrote:

I have some USB-attached HDDs connected to a laptop running Debian 12. Recently I had a problem ejecting them using the file manager and the Disks app, something on the drives was still "in use" even when I had closed every open application.

Since then I've learned of the existence of 'lsof', but at the time my experience of Windows and macOS suggested that, under these kinds of circumstances, performing a shutdown will clear the holds on the drives and cleanly eject them during the process. So as I didn't know what else to do I shut down Debian using the menu.

The last thing I saw before the laptop powered off was a series of messages reporting that both external drives had failed to unmount cleanly, and this was confirmed by the nasty clunking noise from the drives indicating sudden parking of the drive heads when the USB power was unexpectedly removed. Following this incident I've had to recover some several GBs of files from each drive.

Obviously this wasn't a very pleasant experience, so I'd like to know what steps I can take to make Debian act more responsibly in future.

IM(H)O part of the problem was that the first thing to get torn down during the shutdown was the GUI, which meant that there was no way for a user to intervene if there was a problem with ejecting the drives cleanly. Windows and macOS will prompt the user using the GUI if there's a problem that means a drive can't be automatically ejected cleanly during a shutdown, giving users an opportunity to abort. Can I modify the Debian shutdown sequence to keep the GUI available until all drives are safely ejected?

I'd welcome any other suggestions to make Debian less likely to cause data loss on external drives during shutdown.

It is a good habit to issue "sync" command, before disconnecting any USB storage devices.
Some storage devices have very slow write speeds, so you have to wait
for the "sync" command to finish syncing cached writes.
When it finishes you can run it again, just to be sure it worked and it
should finish in an instant.
Now you can safely unmount and then physically disconnect USB storage
devices.
--
With kindest regards, Alexander.
Debian - The universal operating system
https://www.debian.org


--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

"Alexander V. Makartsev" <avbetev@gmail.com> wrote:

On 5/1/26 00:30, coffeeforblood.pardon117@slmail.me wrote:

I have some USB-attached HDDs connected to a laptop running Debian
12. Recently I had a problem ejecting them using the file manager
and the Disks app, something on the drives was still "in use" even
when I had closed every open application.

Since then I've learned of the existence of 'lsof', but at the time
my experience of Windows and macOS suggested that, under these
kinds of circumstances, performing a shutdown will clear the holds
on the drives and cleanly eject them during the process. So as I
didn't know what else to do I shut down Debian using the menu.

The last thing I saw before the laptop powered off was a series of
messages reporting that both external drives had failed to unmount
cleanly, and this was confirmed by the nasty clunking noise from
the drives indicating sudden parking of the drive heads when the
USB power was unexpectedly removed. Following this incident I've
had to recover some several GBs of files from each drive.

Obviously this wasn't a very pleasant experience, so I'd like to
know what steps I can take to make Debian act more responsibly in
future.

IM(H)O part of the problem was that the first thing to get torn
down during the shutdown was the GUI, which meant that there was no
way for a user to intervene if there was a problem with ejecting
the drives cleanly. Windows and macOS will prompt the user using
the GUI if there's a problem that means a drive can't be
automatically ejected cleanly during a shutdown, giving users an opportunity to abort. Can I modify the Debian shutdown sequence to
keep the GUI available until all drives are safely ejected?

I'd welcome any other suggestions to make Debian less likely to
cause data loss on external drives during shutdown.

It is a good habit to issue "sync" command, before disconnecting any
USB storage devices.
Some storage devices have very slow write speeds, so you have to wait
for the "sync" command to finish syncing cached writes.
When it finishes you can run it again, just to be sure it worked and
it should finish in an instant.
Now you can safely unmount and then physically disconnect USB storage devices.

Why doesn't the OS run synce twice on every storage device when it's
shutting down?

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 5/1/26 01:34, debian-user@howorth.org.uk wrote:

"Alexander V. Makartsev"<avbetev@gmail.com> wrote:

On 5/1/26 00:30,coffeeforblood.pardon117@slmail.me wrote:

I have some USB-attached HDDs connected to a laptop running Debian
12. Recently I had a problem ejecting them using the file manager
and the Disks app, something on the drives was still "in use" even
when I had closed every open application.

Since then I've learned of the existence of 'lsof', but at the time
my experience of Windows and macOS suggested that, under these
kinds of circumstances, performing a shutdown will clear the holds
on the drives and cleanly eject them during the process. So as I
didn't know what else to do I shut down Debian using the menu.

The last thing I saw before the laptop powered off was a series of
messages reporting that both external drives had failed to unmount
cleanly, and this was confirmed by the nasty clunking noise from
the drives indicating sudden parking of the drive heads when the
USB power was unexpectedly removed. Following this incident I've
had to recover some several GBs of files from each drive.

Obviously this wasn't a very pleasant experience, so I'd like to
know what steps I can take to make Debian act more responsibly in
future.

IM(H)O part of the problem was that the first thing to get torn
down during the shutdown was the GUI, which meant that there was no
way for a user to intervene if there was a problem with ejecting
the drives cleanly. Windows and macOS will prompt the user using
the GUI if there's a problem that means a drive can't be
automatically ejected cleanly during a shutdown, giving users an
opportunity to abort. Can I modify the Debian shutdown sequence to
keep the GUI available until all drives are safely ejected?

I'd welcome any other suggestions to make Debian less likely to
cause data loss on external drives during shutdown.

It is a good habit to issue "sync" command, before disconnecting any
USB storage devices.
Some storage devices have very slow write speeds, so you have to wait
for the "sync" command to finish syncing cached writes.
When it finishes you can run it again, just to be sure it worked and
it should finish in an instant.
Now you can safely unmount and then physically disconnect USB storage
devices.

Why doesn't the OS run synce twice on every storage device when it's
shutting down?

I'm guessing "umount" command is just as good to safely unmount
filesystems during shutdown, but the actual process (systemd units?)
that does it could be getting interrupted by timeout.
IIRC 1 minute 30 seconds is the default timeout for systemd units.
If a slow USB storage device has a few gigabytes of cached writes it
won't make it in time.
SATA\M.2 connected storage devices are not affected because they are
many times faster and the connection is more robust.
I've never actually tested this and never tried to shutdown a PC with a
few terabytes of pending writes to the root filesystem.
Like I said, I have a good habit to type "sync" whenever I need to flush
all cached writes to all storage devices and it never failed me.
As an additional thought, there could be something wrong with the OP's
HDD drive, like bad\remapped sectors, or any other issue, making its
write speed even slower.
--
With kindest regards, Alexander.
Debian - The universal operating system
https://www.debian.org


--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Fri, 1 May 2026 02:38:48 +0500
"Alexander V. Makartsev" <avbetev@gmail.com> wrote:

As an additional thought, there could be something wrong with the
OP's HDD drive, like bad\remapped sectors, or any other issue, making
its write speed even slower.

If the OP hears the heads home, I wonder how old that drive is, and
therefor, how reliable.

--
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

I have some USB-attached HDDs connected to a laptop running Debian
12. Recently I had a problem ejecting them using the file manager and the Disks app, something on the drives was still "in use" even when I had closed every open application.

I assume here that the "in use"ness was very limited: the drives were
basically idle.

Since then I've learned of the existence of 'lsof', but at the time my

[ FWIW, while I used to like `lsof` and `fuser`, they haven't been very
helpful over the last decade or so, for me: all too often telling me
that nothing using the mount point even though `mount` tells me it's
still busy. ]

The last thing I saw before the laptop powered off was a series of
messages reporting that both external drives had failed to unmount
cleanly,

Presumably for the same reason you couldn't "eject" them.

and this was confirmed by the nasty clunking noise from the drives
indicating sudden parking of the drive heads when the USB power was unexpectedly removed.

AFAIK, this has nothing to do with the unmounting of the partitions.
IOW, you'd have heard the exact same noise even if the OS had been able
to successfully unmount the partitions (what you call "eject")
before rebooting.

Following this incident I've had to recover some several GBs of
files from each drive.

What filesystem are you using on those drives?
Ext4? FAT? Something else?

For most filesystems nowadays, a forced disconnection should not cause
any significant data loss if the drive was idle when the
disconnection occurred.


=== Stefan

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Thursday, April 30th, 2026 at 8:48 PM, Stefan Monnier <monnier@iro.umont real.ca> wrote:

I have some USB-attached HDDs connected to a laptop running Debian
12. Recently I had a problem ejecting them using the file manager and t

he

Disks app, something on the drives was still "in use" even when I had c

losed

every open application.

I assume here that the "in use"ness was very limited: the drives were basically idle.

I've found that "in use" can also mean that you're looking at the disk. Tr
y just "cd" to get off it and get back home.

--
Glenn English

-----BEGIN PGP SIGNATURE-----
Version: ProtonMail

wsC5BAEBCgBtBYJp9B5/CRCf14YxgqyMMkUUAAAAAAAcACBzYWx0QG5vdGF0 aW9ucy5vcGVucGdwanMub3JnP7HLZ/r8Sp/ZCry98OEVtpjM4/Ewcg0kuBMf w/PVXbUWIQQsonMPQlJwJWNADZef14YxgqyMMgAAw68IAJ3eHhCvDxiLNQiY JVqAZsWMvXfGI/O+0gG3tZ3QU/H15QgNyDhj7BCeGoHWp7Rurj0XzrV67DFs nn19nE3lRVPI62X3AC3MhvxRrc7nIz4vsdcnlrQHJrou8mPGFSz5tYZp1rSP 67I7pcE8NJ22h+4+bu8Tz1Bb127gra6B7HNcE7QWOr6mG0pK+iG05nUs+TUk xHFdYd93lcE20Xle2CZBBCMlcd/kYnr8yLG+ADO41jlj64djFn1/mcXfzh7C WkQCD9ByDD0wmclAlUXOurfKVDXJBzRWCTCNIeY3A8cD/AilZuz17jtVs/UM X+cMtOp0IgqVUMX1qqxz8QV1Nh4=
=AGK3
-----END PGP SIGNATURE-----

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Fri, 01 May 2026 03:31:28 +0000
ghe2001 <ghe2001@protonmail.com> wrote:

I've found that "in use" can also mean that you're looking at the
disk. Try just "cd" to get off it and get back home.

Right. lsof will find that.

lsof | grep <path to top of hdd>

--
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Fri, May 01, 2026 at 01:24:09AM +0500, Alexander V. Makartsev wrote:

On 5/1/26 00:30, coffeeforblood.pardon117@slmail.me wrote:

I have some USB-attached HDDs connected to a laptop running Debian 12. Recently I had a problem ejecting them using the file manager and the Disks app, something on the drives was still "in use" even when I had closed every open application.

[...]

I'd welcome any other suggestions to make Debian less likely to cause data loss on external drives during shutdown.

It is a good habit to issue "sync" command, before disconnecting any USB storage devices.
Some storage devices have very slow write speeds, so you have to wait for
the "sync" command to finish syncing cached writes.
When it finishes you can run it again, just to be sure it worked and it should finish in an instant.
Now you can safely unmount and then physically disconnect USB storage devices.

I think this is the most plausible explanation. Some application "sitting
on" a disk should be long gone when trying to unmount: we are in shutdown, aren't we?
To get more data, you could just try (while in normal operation) to issue
a "sync" and see how long it takes (for some USB sticks, for me it takes minutes: as Alexander says, USB is slow). If the shutdown process loses patience, the scenario you describe could very well happen.
Cheers
--
t


--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Alexander V. Makartsev wrote:

I'm guessing "umount" command is just as good to safely unmount filesystems during shutdown, but the actual process (systemd units?) that does it could be getting interrupted by timeout.
IIRC 1 minute 30 seconds is the default timeout for systemd units.
If a slow USB storage device has a few gigabytes of cached writes it won't make it in time.
SATA\M.2 connected storage devices are not affected because they are many times faster and the connection is more robust.
I've never actually tested this and never tried to shutdown a PC with a few terabytes of pending writes to the root filesystem.

You would need to have terabytes of RAM in order to do that...
which is possible, but very expensive.

Also, the kernel tries to flush the write buffers whenever enough time has
gone by:

/proc/sys/vm/dirty_writeback_centisecs = 500
(every 5 seconds)

/proc/sys/vm/dirty_ratio = 20
(or when 20% of memory is writable buffers)

If you set these to lower values, the disks will be written to
more often; larger values will space writes further apart.

Unfortunately, these are system-wide values. Whatever is optimal
for primary storage is usually not quite right for relatively slow USB-connected storage.

-dsr-

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Fri, 2026-05-01 at 10:23 -0400, Jeffrey Walton wrote:

If the drive is making noise, it is time to retire it.

Hard drives will always make some audible noise, even when new & in
perfect order, although some more than others. Only sudden unusual
noises are a bad sign.


--
Jan Claeys

(please don't CC me when replying to the list)

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)