I have a server, from which I host a few directories on an external hdd. I'd like to just yank out the disk any time I want (it's why it is external) without any prior preparation.

- on dismount: force unmount and remove the mount point, whatever process uses it
- on mount: mount it again

Is dismount like this possible without crashing my server?
I tried to write udev usb mount rules plus shell scripts (on add and remove), but:
- for remove/dismount, a umount -l does not work and the syslog just log disk errors whenever I try to to access the drive
- for add, mounting doesn't seem to work from the shell script. Yet after typing the command manually the mount occurs properly.

Is there a better strategy for this?

It it were me, I'd put it in /etc/fstab with the noauto argument.

You will have to unmount it and mount it, but it's easy to do from the command line. Otherwise, you risk data corruption on unmount.

Even USB sticks need to be ejected in Windows.
Unmounting a drive before disconnecting it is just part of how things work...

Wouldn't this be solved by mounting with "sync" option? That flushes all changes to the disk immediately. I believe this should prevent disk errors...
I would still prefer (um)mounting from the commandline. In this case (external disk) you can use pmount and pumount. That handles the creation and deletion from the mountpoints under /media/<user>/

Let me know if this helps...

Greetz,
Remco

I never ejected a single usb stick ever, and never had issues with it.
But the analogue is sadly not correct, since this storage is constantly used / mounted to server applications so one can never know how it's being used.

Thanks all. As others on other platforms also said, This should definitely not happen regularly, because there is always a chance for data corruption.

So I'm leaning more to the use case of when this happens on accident, the usb is yanked out, the external case borks a bit, etc - so that all the

I've read about this option, but it would have adverse effect. This would be good for eg. security footage, but for my use case (media files) rather have an operation error out with no effect than have half-copied files everywhere.

IF, and only if, the device you are referring to is read only it can usually be abruptly removed without harm to the device or data it contains, although it certainly will cause errors in whatever app is using that data.
IF the device is read/write and something is currently writing to the device when it is abruptly removed it likely will cause data corruption.

In Windows the eject command is similar to the command sequence "sync" followed by "umount" in linux in that it forces the system to complete any write operations on the device specified then tells it to make it available for removal. In linux however, the device cannot be cleanly unmounted if it is still busy -- ie. if something has a file open, someone has done a "cd" to that file system, etc. Physically disconnecting a device in use and breaking its mount can cause a lot of unexpected problems both with data and with the system itself.

Sync does not write files -- It only forces the system to complete writes that may have been cached and are waiting to be written. It synchronizes the data in the system with the disk. Read the man page for sync before you accuse it of copying files.

Which would you prefer... having files completely written and the system/data clean by running sync?, or having a situation where a cached write was not completed and the system becomes corrupted as a result because you did not run sync?.
Sync is the tool to make sure the second does not happen

I know of no strategy that would allow you to arbitrarily remove a drive without risk to the data it contains if files on that device are in use. If you can make certain that no data is in use then your strategy would possibly work.

You can tell if it is currently in use with the "lsof /dev/drive" command and if it is in use then a forcible dismount could cause data corruption.

Thanks for the clarification on sync. The idea is to clean up in the rare case the drive happens to disconnect, and remount it, if it reconnects. This should be an edge case - maintaining the service is more important, I would run this as a test for some time to see data corruption chances.

I want to write a (possibly udev rule) that unmounts the previously mounted folder once the drive disconnects. This way all subsequent access is properly denied instead of giving an i/o error.
And on add, it should mount the drive to the folder again.

- With dismounting in udev, I have a problem of the mount being marked as busy - is there a way to "unlock" the folder so that it could be unmounted.
- With mounting in udev, I just read that mount commands won't work sadly..

Nowadays systemd handles identifying and mounting removable devices. It uses the device label or uuid and (at least on fedora) mounts them on /run/media/user/device. If there is a hanging device in the mount table from a forcible disconnect then it could cause a problem in remounting. A forced and unclean dismount/disconnect should also trigger a file system check (fsck) before remounting so errors can be identified and repaired as early as possible.

I hope you are not planning to use a live, in use, device to test the results of a forced disconnect. That would definitely put things at risk on a server.

As I understand it, if the device has had a label written when it was partitioned then that label will be used as the final part of the automatic mount path. If no label then the uuid is used.
With that information it should be fairly simple to have a script check if the device is there or missing and unmount it if disconnected. The possibility that the mount table gets messed up by a forcible disconnect could also be checked and fixed as well.
Your device could be (if not already) put into the fstab file by label so that when it is reattached the command "mount -a" in your script would automatically mount it at the proper location.

In summary,
The script should check if the device is mounted and available and if not then clear out the mount table.
When the device is again available then run an fsck to make certain there is no file system damage.
Finally remount it so it is again usable.
your script could be run periodically by crontab or something similar.

I have not worked at the depth of udev or systemd but the process would be the same although the details would vary.

It sounds to me like your concern is because you may have someone who just arbitrarily disconnects devices. If so then that is the core problem you really need to get fixed quick before an error trashes your data.