Why is lazy MNT_DETACH or `umount -l` unsafe / dangerous?
Clash Royale CLAN TAG#URR8PPP
I've read in a few places that umount -l
is unsafe:
In an answer by @cas:
don't use
umount
's--lazy
option if you care about when the external drive can be safely unplugged
A comment by @frostschutz:
umount --lazy
is not safe and can not be made safe. [...]
This util-linux
comment by Ruediger Meier:
You should avoid using
umount -l
at all. Just kill all processes which
are using/tmp/mountpoint
and then umount without option-l
.
Why is umount -l
unsafe / dangerous?
Is there a way to make it safe?
linux filesystems unmounting util-linux
add a comment |
I've read in a few places that umount -l
is unsafe:
In an answer by @cas:
don't use
umount
's--lazy
option if you care about when the external drive can be safely unplugged
A comment by @frostschutz:
umount --lazy
is not safe and can not be made safe. [...]
This util-linux
comment by Ruediger Meier:
You should avoid using
umount -l
at all. Just kill all processes which
are using/tmp/mountpoint
and then umount without option-l
.
Why is umount -l
unsafe / dangerous?
Is there a way to make it safe?
linux filesystems unmounting util-linux
add a comment |
I've read in a few places that umount -l
is unsafe:
In an answer by @cas:
don't use
umount
's--lazy
option if you care about when the external drive can be safely unplugged
A comment by @frostschutz:
umount --lazy
is not safe and can not be made safe. [...]
This util-linux
comment by Ruediger Meier:
You should avoid using
umount -l
at all. Just kill all processes which
are using/tmp/mountpoint
and then umount without option-l
.
Why is umount -l
unsafe / dangerous?
Is there a way to make it safe?
linux filesystems unmounting util-linux
I've read in a few places that umount -l
is unsafe:
In an answer by @cas:
don't use
umount
's--lazy
option if you care about when the external drive can be safely unplugged
A comment by @frostschutz:
umount --lazy
is not safe and can not be made safe. [...]
This util-linux
comment by Ruediger Meier:
You should avoid using
umount -l
at all. Just kill all processes which
are using/tmp/mountpoint
and then umount without option-l
.
Why is umount -l
unsafe / dangerous?
Is there a way to make it safe?
linux filesystems unmounting util-linux
linux filesystems unmounting util-linux
edited Sep 7 '17 at 11:19
Tom Hale
asked Sep 3 '17 at 7:39
Tom HaleTom Hale
7,355342101
7,355342101
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
A lazy unmount creates a Schrödinger's cat mount
- You cannot know if the the device is actually unmounted or not
- The "unmounted" filesystem remains accessible in some circumstances
- The "unmounted" filesystem is not accessible in some circumstances
There is a false sense of security: it appears that the filesystem has been unmounted, but in reality it has only been hidden from the file namespace / heirarchy.
- Processes can still write via open file descriptors
- New or existing files can be opened for writing by processes with a working directory inside the mountpoint via relative pathnames
This means that if you umount -l /media/hdd
you will no longer be able to access /media/hdd/dir/file
(absolute pathname) but if you have a process with working directory /media/hdd
it will still be able to create new processes which can read/write ./dir/file
(relative pathname).
If you try to unmount the device, you will a confusing message:
# umount --force --all-targets /dev/sdb2
umount: /dev/sdb2: not mounted
This makes it look like the device has unounted, but there still can be processes writing to the disk.
Since there are various non-obvious situations that can cause umount to block, the filesystem may still not be unmounted even though lsof +f -- /dev/device
shows nothing.
You'll never know if the filesystem actually unmounts. There's no way to find out.
Removable devices
If you do umount -l
a removable disk, you're in limbo-land: you can't be sure that all pending data has been written to disk.
The best you can do after a umount -l
is to ensure all writing completes and prevent future writing, but you still can't guarantee that it has been unmounted.
With removable devices, if the device isn't properly unmounted, strange behaviour can result the next time it is plugged in:
The device will get an incremented device name, ie
/dev/sdb
becomes/dev/sdc
. The kernel log messages may still refer to/dev/sdb
even though that device no longer exists as a file under/dev
. (The only way I know to resolve this is to reboot.)btrfs corruption can result. btrfs expects that only one filesystem with a given UUID is present at one time. The kernel still sees the same UUID available on the phantom device and the new device. (I had to rebuild my btrfs backup HDD).
systemd
gotchas
It seems that a lazy unmount or
MNT_DETACH
is caused by using eitherx-systemd.mount-timeout=
in/etc/fstab
or usingTimeoutIdleSec=
in an Automount file.Avoid the above
systemd
options especially is usingbtrfs
. I learned from bitter experience (see btrfs reference above).
"New or existing files can be opened for writing by processes with a working directory inside the mountpoint via relative pathnames" This is the information I was looking for. Do you have any additional links or references?
– Jonathon Reinhart
Jan 8 at 12:16
@Jonathon check man umount. I'd need to google otherwise. Please post your findings if you do this.
– Tom Hale
Jan 9 at 23:04
I've readumount(2)
several times recently. It says only "Perform a lazy unmount: make the mount point unavailable for new accesses, immediately disconnect the filesystem and all filesystems mounted below it from each other and from the mount table, and actually perform the unmount when the mount point ceases to be busy." But unfortunately this is less detail even than what you have provided.
– Jonathon Reinhart
Jan 10 at 2:18
umount(8)
says that a file system is busy "for example, when there are open files on it, or when some process has its working directory there, or when a swap file on it is in use." That doesn't sound like a definitive list, but is probably as good as I'll be able to find.
– Jonathon Reinhart
Jan 10 at 2:23
I elaborated a bit on what you said, and added some other examples in this answer. Thanks for the information!
– Jonathon Reinhart
Jan 10 at 4:11
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f390056%2fwhy-is-lazy-mnt-detach-or-umount-l-unsafe-dangerous%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
A lazy unmount creates a Schrödinger's cat mount
- You cannot know if the the device is actually unmounted or not
- The "unmounted" filesystem remains accessible in some circumstances
- The "unmounted" filesystem is not accessible in some circumstances
There is a false sense of security: it appears that the filesystem has been unmounted, but in reality it has only been hidden from the file namespace / heirarchy.
- Processes can still write via open file descriptors
- New or existing files can be opened for writing by processes with a working directory inside the mountpoint via relative pathnames
This means that if you umount -l /media/hdd
you will no longer be able to access /media/hdd/dir/file
(absolute pathname) but if you have a process with working directory /media/hdd
it will still be able to create new processes which can read/write ./dir/file
(relative pathname).
If you try to unmount the device, you will a confusing message:
# umount --force --all-targets /dev/sdb2
umount: /dev/sdb2: not mounted
This makes it look like the device has unounted, but there still can be processes writing to the disk.
Since there are various non-obvious situations that can cause umount to block, the filesystem may still not be unmounted even though lsof +f -- /dev/device
shows nothing.
You'll never know if the filesystem actually unmounts. There's no way to find out.
Removable devices
If you do umount -l
a removable disk, you're in limbo-land: you can't be sure that all pending data has been written to disk.
The best you can do after a umount -l
is to ensure all writing completes and prevent future writing, but you still can't guarantee that it has been unmounted.
With removable devices, if the device isn't properly unmounted, strange behaviour can result the next time it is plugged in:
The device will get an incremented device name, ie
/dev/sdb
becomes/dev/sdc
. The kernel log messages may still refer to/dev/sdb
even though that device no longer exists as a file under/dev
. (The only way I know to resolve this is to reboot.)btrfs corruption can result. btrfs expects that only one filesystem with a given UUID is present at one time. The kernel still sees the same UUID available on the phantom device and the new device. (I had to rebuild my btrfs backup HDD).
systemd
gotchas
It seems that a lazy unmount or
MNT_DETACH
is caused by using eitherx-systemd.mount-timeout=
in/etc/fstab
or usingTimeoutIdleSec=
in an Automount file.Avoid the above
systemd
options especially is usingbtrfs
. I learned from bitter experience (see btrfs reference above).
"New or existing files can be opened for writing by processes with a working directory inside the mountpoint via relative pathnames" This is the information I was looking for. Do you have any additional links or references?
– Jonathon Reinhart
Jan 8 at 12:16
@Jonathon check man umount. I'd need to google otherwise. Please post your findings if you do this.
– Tom Hale
Jan 9 at 23:04
I've readumount(2)
several times recently. It says only "Perform a lazy unmount: make the mount point unavailable for new accesses, immediately disconnect the filesystem and all filesystems mounted below it from each other and from the mount table, and actually perform the unmount when the mount point ceases to be busy." But unfortunately this is less detail even than what you have provided.
– Jonathon Reinhart
Jan 10 at 2:18
umount(8)
says that a file system is busy "for example, when there are open files on it, or when some process has its working directory there, or when a swap file on it is in use." That doesn't sound like a definitive list, but is probably as good as I'll be able to find.
– Jonathon Reinhart
Jan 10 at 2:23
I elaborated a bit on what you said, and added some other examples in this answer. Thanks for the information!
– Jonathon Reinhart
Jan 10 at 4:11
add a comment |
A lazy unmount creates a Schrödinger's cat mount
- You cannot know if the the device is actually unmounted or not
- The "unmounted" filesystem remains accessible in some circumstances
- The "unmounted" filesystem is not accessible in some circumstances
There is a false sense of security: it appears that the filesystem has been unmounted, but in reality it has only been hidden from the file namespace / heirarchy.
- Processes can still write via open file descriptors
- New or existing files can be opened for writing by processes with a working directory inside the mountpoint via relative pathnames
This means that if you umount -l /media/hdd
you will no longer be able to access /media/hdd/dir/file
(absolute pathname) but if you have a process with working directory /media/hdd
it will still be able to create new processes which can read/write ./dir/file
(relative pathname).
If you try to unmount the device, you will a confusing message:
# umount --force --all-targets /dev/sdb2
umount: /dev/sdb2: not mounted
This makes it look like the device has unounted, but there still can be processes writing to the disk.
Since there are various non-obvious situations that can cause umount to block, the filesystem may still not be unmounted even though lsof +f -- /dev/device
shows nothing.
You'll never know if the filesystem actually unmounts. There's no way to find out.
Removable devices
If you do umount -l
a removable disk, you're in limbo-land: you can't be sure that all pending data has been written to disk.
The best you can do after a umount -l
is to ensure all writing completes and prevent future writing, but you still can't guarantee that it has been unmounted.
With removable devices, if the device isn't properly unmounted, strange behaviour can result the next time it is plugged in:
The device will get an incremented device name, ie
/dev/sdb
becomes/dev/sdc
. The kernel log messages may still refer to/dev/sdb
even though that device no longer exists as a file under/dev
. (The only way I know to resolve this is to reboot.)btrfs corruption can result. btrfs expects that only one filesystem with a given UUID is present at one time. The kernel still sees the same UUID available on the phantom device and the new device. (I had to rebuild my btrfs backup HDD).
systemd
gotchas
It seems that a lazy unmount or
MNT_DETACH
is caused by using eitherx-systemd.mount-timeout=
in/etc/fstab
or usingTimeoutIdleSec=
in an Automount file.Avoid the above
systemd
options especially is usingbtrfs
. I learned from bitter experience (see btrfs reference above).
"New or existing files can be opened for writing by processes with a working directory inside the mountpoint via relative pathnames" This is the information I was looking for. Do you have any additional links or references?
– Jonathon Reinhart
Jan 8 at 12:16
@Jonathon check man umount. I'd need to google otherwise. Please post your findings if you do this.
– Tom Hale
Jan 9 at 23:04
I've readumount(2)
several times recently. It says only "Perform a lazy unmount: make the mount point unavailable for new accesses, immediately disconnect the filesystem and all filesystems mounted below it from each other and from the mount table, and actually perform the unmount when the mount point ceases to be busy." But unfortunately this is less detail even than what you have provided.
– Jonathon Reinhart
Jan 10 at 2:18
umount(8)
says that a file system is busy "for example, when there are open files on it, or when some process has its working directory there, or when a swap file on it is in use." That doesn't sound like a definitive list, but is probably as good as I'll be able to find.
– Jonathon Reinhart
Jan 10 at 2:23
I elaborated a bit on what you said, and added some other examples in this answer. Thanks for the information!
– Jonathon Reinhart
Jan 10 at 4:11
add a comment |
A lazy unmount creates a Schrödinger's cat mount
- You cannot know if the the device is actually unmounted or not
- The "unmounted" filesystem remains accessible in some circumstances
- The "unmounted" filesystem is not accessible in some circumstances
There is a false sense of security: it appears that the filesystem has been unmounted, but in reality it has only been hidden from the file namespace / heirarchy.
- Processes can still write via open file descriptors
- New or existing files can be opened for writing by processes with a working directory inside the mountpoint via relative pathnames
This means that if you umount -l /media/hdd
you will no longer be able to access /media/hdd/dir/file
(absolute pathname) but if you have a process with working directory /media/hdd
it will still be able to create new processes which can read/write ./dir/file
(relative pathname).
If you try to unmount the device, you will a confusing message:
# umount --force --all-targets /dev/sdb2
umount: /dev/sdb2: not mounted
This makes it look like the device has unounted, but there still can be processes writing to the disk.
Since there are various non-obvious situations that can cause umount to block, the filesystem may still not be unmounted even though lsof +f -- /dev/device
shows nothing.
You'll never know if the filesystem actually unmounts. There's no way to find out.
Removable devices
If you do umount -l
a removable disk, you're in limbo-land: you can't be sure that all pending data has been written to disk.
The best you can do after a umount -l
is to ensure all writing completes and prevent future writing, but you still can't guarantee that it has been unmounted.
With removable devices, if the device isn't properly unmounted, strange behaviour can result the next time it is plugged in:
The device will get an incremented device name, ie
/dev/sdb
becomes/dev/sdc
. The kernel log messages may still refer to/dev/sdb
even though that device no longer exists as a file under/dev
. (The only way I know to resolve this is to reboot.)btrfs corruption can result. btrfs expects that only one filesystem with a given UUID is present at one time. The kernel still sees the same UUID available on the phantom device and the new device. (I had to rebuild my btrfs backup HDD).
systemd
gotchas
It seems that a lazy unmount or
MNT_DETACH
is caused by using eitherx-systemd.mount-timeout=
in/etc/fstab
or usingTimeoutIdleSec=
in an Automount file.Avoid the above
systemd
options especially is usingbtrfs
. I learned from bitter experience (see btrfs reference above).
A lazy unmount creates a Schrödinger's cat mount
- You cannot know if the the device is actually unmounted or not
- The "unmounted" filesystem remains accessible in some circumstances
- The "unmounted" filesystem is not accessible in some circumstances
There is a false sense of security: it appears that the filesystem has been unmounted, but in reality it has only been hidden from the file namespace / heirarchy.
- Processes can still write via open file descriptors
- New or existing files can be opened for writing by processes with a working directory inside the mountpoint via relative pathnames
This means that if you umount -l /media/hdd
you will no longer be able to access /media/hdd/dir/file
(absolute pathname) but if you have a process with working directory /media/hdd
it will still be able to create new processes which can read/write ./dir/file
(relative pathname).
If you try to unmount the device, you will a confusing message:
# umount --force --all-targets /dev/sdb2
umount: /dev/sdb2: not mounted
This makes it look like the device has unounted, but there still can be processes writing to the disk.
Since there are various non-obvious situations that can cause umount to block, the filesystem may still not be unmounted even though lsof +f -- /dev/device
shows nothing.
You'll never know if the filesystem actually unmounts. There's no way to find out.
Removable devices
If you do umount -l
a removable disk, you're in limbo-land: you can't be sure that all pending data has been written to disk.
The best you can do after a umount -l
is to ensure all writing completes and prevent future writing, but you still can't guarantee that it has been unmounted.
With removable devices, if the device isn't properly unmounted, strange behaviour can result the next time it is plugged in:
The device will get an incremented device name, ie
/dev/sdb
becomes/dev/sdc
. The kernel log messages may still refer to/dev/sdb
even though that device no longer exists as a file under/dev
. (The only way I know to resolve this is to reboot.)btrfs corruption can result. btrfs expects that only one filesystem with a given UUID is present at one time. The kernel still sees the same UUID available on the phantom device and the new device. (I had to rebuild my btrfs backup HDD).
systemd
gotchas
It seems that a lazy unmount or
MNT_DETACH
is caused by using eitherx-systemd.mount-timeout=
in/etc/fstab
or usingTimeoutIdleSec=
in an Automount file.Avoid the above
systemd
options especially is usingbtrfs
. I learned from bitter experience (see btrfs reference above).
edited Feb 23 at 11:51
answered Sep 3 '17 at 7:39
Tom HaleTom Hale
7,355342101
7,355342101
"New or existing files can be opened for writing by processes with a working directory inside the mountpoint via relative pathnames" This is the information I was looking for. Do you have any additional links or references?
– Jonathon Reinhart
Jan 8 at 12:16
@Jonathon check man umount. I'd need to google otherwise. Please post your findings if you do this.
– Tom Hale
Jan 9 at 23:04
I've readumount(2)
several times recently. It says only "Perform a lazy unmount: make the mount point unavailable for new accesses, immediately disconnect the filesystem and all filesystems mounted below it from each other and from the mount table, and actually perform the unmount when the mount point ceases to be busy." But unfortunately this is less detail even than what you have provided.
– Jonathon Reinhart
Jan 10 at 2:18
umount(8)
says that a file system is busy "for example, when there are open files on it, or when some process has its working directory there, or when a swap file on it is in use." That doesn't sound like a definitive list, but is probably as good as I'll be able to find.
– Jonathon Reinhart
Jan 10 at 2:23
I elaborated a bit on what you said, and added some other examples in this answer. Thanks for the information!
– Jonathon Reinhart
Jan 10 at 4:11
add a comment |
"New or existing files can be opened for writing by processes with a working directory inside the mountpoint via relative pathnames" This is the information I was looking for. Do you have any additional links or references?
– Jonathon Reinhart
Jan 8 at 12:16
@Jonathon check man umount. I'd need to google otherwise. Please post your findings if you do this.
– Tom Hale
Jan 9 at 23:04
I've readumount(2)
several times recently. It says only "Perform a lazy unmount: make the mount point unavailable for new accesses, immediately disconnect the filesystem and all filesystems mounted below it from each other and from the mount table, and actually perform the unmount when the mount point ceases to be busy." But unfortunately this is less detail even than what you have provided.
– Jonathon Reinhart
Jan 10 at 2:18
umount(8)
says that a file system is busy "for example, when there are open files on it, or when some process has its working directory there, or when a swap file on it is in use." That doesn't sound like a definitive list, but is probably as good as I'll be able to find.
– Jonathon Reinhart
Jan 10 at 2:23
I elaborated a bit on what you said, and added some other examples in this answer. Thanks for the information!
– Jonathon Reinhart
Jan 10 at 4:11
"New or existing files can be opened for writing by processes with a working directory inside the mountpoint via relative pathnames" This is the information I was looking for. Do you have any additional links or references?
– Jonathon Reinhart
Jan 8 at 12:16
"New or existing files can be opened for writing by processes with a working directory inside the mountpoint via relative pathnames" This is the information I was looking for. Do you have any additional links or references?
– Jonathon Reinhart
Jan 8 at 12:16
@Jonathon check man umount. I'd need to google otherwise. Please post your findings if you do this.
– Tom Hale
Jan 9 at 23:04
@Jonathon check man umount. I'd need to google otherwise. Please post your findings if you do this.
– Tom Hale
Jan 9 at 23:04
I've read
umount(2)
several times recently. It says only "Perform a lazy unmount: make the mount point unavailable for new accesses, immediately disconnect the filesystem and all filesystems mounted below it from each other and from the mount table, and actually perform the unmount when the mount point ceases to be busy." But unfortunately this is less detail even than what you have provided.– Jonathon Reinhart
Jan 10 at 2:18
I've read
umount(2)
several times recently. It says only "Perform a lazy unmount: make the mount point unavailable for new accesses, immediately disconnect the filesystem and all filesystems mounted below it from each other and from the mount table, and actually perform the unmount when the mount point ceases to be busy." But unfortunately this is less detail even than what you have provided.– Jonathon Reinhart
Jan 10 at 2:18
umount(8)
says that a file system is busy "for example, when there are open files on it, or when some process has its working directory there, or when a swap file on it is in use." That doesn't sound like a definitive list, but is probably as good as I'll be able to find.– Jonathon Reinhart
Jan 10 at 2:23
umount(8)
says that a file system is busy "for example, when there are open files on it, or when some process has its working directory there, or when a swap file on it is in use." That doesn't sound like a definitive list, but is probably as good as I'll be able to find.– Jonathon Reinhart
Jan 10 at 2:23
I elaborated a bit on what you said, and added some other examples in this answer. Thanks for the information!
– Jonathon Reinhart
Jan 10 at 4:11
I elaborated a bit on what you said, and added some other examples in this answer. Thanks for the information!
– Jonathon Reinhart
Jan 10 at 4:11
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f390056%2fwhy-is-lazy-mnt-detach-or-umount-l-unsafe-dangerous%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown