this post was submitted on 26 Jun 2026
6 points (100.0% liked)
linux4noobs
4242 readers
5 users here now
linux4noobs
Noob Friendly, Expert Enabling
Whether you're a seasoned pro or the noobiest of noobs, you've found the right place for Linux support and information. With a dedication to supporting free and open source software, this community aims to ensure Linux fits your needs and works for you. From troubleshooting to tutorials, practical tips, news and more, all aspects of Linux are warmly welcomed. Join a community of like-minded enthusiasts and professionals driving Linux's ongoing evolution.
Seeking Support?
- Mention your Linux distro and relevant system details.
- Describe what you've tried so far.
- Share your solution even if you found it yourself.
- Do not delete your post. This allows other people to see possible solutions if they have a similar problem.
- Properly format any scripts, code, logs, or error messages.
- Be mindful to omit any sensitive information such as usernames, passwords, IP addresses, etc.
Community Rules
- Keep discussions respectful and amiable. This community is a space where individuals may freely inquire, exchange thoughts, express viewpoints, and extend help without encountering belittlement. We were all a noob at one point. Differing opinions and ideas is a normal part of discourse, but it must remain civil. Offenders will be warned and/or removed.
- Posts must be Linux oriented
- Spam or affiliate links will not be tolerated.
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Setting aside bind mounts, there is no reliable, safe way to just unplug a USB drive. You always need to, in software, on any OS, manually signal to the OS in some way that you're not using it to ensure that any data is flushed to the drive and the OS isn't using it. Zip drives had a locking mechanism and a button that requested an unmount and eject of the media, but USB drives where you expect to just unplug the thing don't. You might get away with it, and newer filesystems won't have the whole filesystem become corrupt if you just yank it, but you still should unmount it. There are systems to automatically mount. There are systems to automatically unmount filesystems that will go unused for a while, and at that point it is safe to unplug. But USB just doesn't physically support blocking someone unplugging something until all the data is written out; if you just yank the thing out, you always run the risk of losing data, even if it mostly works. True for Windows, Linux, any OS. That's why, for example, Windows has that "eject flash drive" thing in its system tray. And note that most flash drives come formatted with some version of FAT, an older DOS/Windows filesystem, which does have the risk of becoming corrupt (i.e. you could lose everything on the filesystem) if it isn't cleanly unmounted. The risk may be small, but it's there. If you reformat the drive with something like ext3, ext4, btrfs (Linux-native filesystems) or NTFS (a Windows-native filesystem), then that corruption risk goes away, and your risk is just "some data that you recently saved might not have made it to the drive".
Okay, that being said, normally a bind mount is a mount that is a "virtual copy" of what exists elsewhere on the filesystem. That is, if you have a bind mount of something, it appears to userspace software to be mounted at two different locations. I'm not sure if that's actually what you mean, or if you just want a single mount that is automatically done by software when you plug the drive in. If you do mean "bind mount", I don't know of a way to do that off the top of my head, though there might be a way to achieve it with udev. I'd guess that there's probably a way to set it up to run arbitrary commands when a device is connected, so there's probably a way to run a bind mount command as well as a regular mount command.
If I were doing this myself and wanted the mount to be at a second location merely for convenience (like, I wanted "shortcuts" that pointed at some drive, when it was plugged in, elsewhere), I would most likely not use a bind mount, but rather just make a symlink aimed at the regular mount point, and access the symlink. Bind mounts are a fairly-exotic thing that one normally uses if one wants to give access to a process to a mount without letting it have access to the directory structure leading up to it, like a containerized system.
If what you want is not a bind mount, but just a regular mount (you don't want the mount to "exist" at two different places in your filesystem tree), then there are various systems that will automatically mount something when you plug it in. @onlinepersona@programming.dev is, I believe, correct that most desktop environments on Linux have some system for this; I'm not familiar with them, as I don't use a desktop environment, so I'm probably not the best person to advise there. I have used autofs, which is an older, more-general and somewhat-more-complicated-to-set-up system that will try to automatically mount a mount when you try accessing a mountpoint, then unmounts it if it is unused for a while. This tends to be more useful for things like network mounts.
Followup: OP, based on your post update, you do indeed mean bind mounts. Okay.
As I said above, what I would probably do myself for most cases is to just use a symlink, not a bind mount. That's easy, doesn't require futzing around with the system, and in most cases probably does what you want, whereas a bind mount may not (e.g. if you have a filesystem indexer or backup system, they're not going to back the stuff up or index it twice).
That'd be something like:
That does mean that /home/user/folder will still be visible when you don't have the media inserted, though it'll just be a dangling symlink.
If you definitely do want to do it with bind mounts...hmm. It looks like there are some additional hurdles.
https://unix.stackexchange.com/questions/799166/linux-auto-mounting-usb-with-udev
According to a comment there, it looks like systemd-udev shouldn't run a
mountcommand directly, as it runs commands in a private namespace; it should usesystemd-mount --no-block, which will ask systemd to set this up. You could probably write a bash script that runs a series of commands, including thesystemd-mountcommand. It may be a bit involved for a linux4noobs solution, and I can't give an off-the-cuff answer from personal experience, but I'd guess that it may very well be technically possible, and that's probably what I'd be looking into if I were determined to specifically to use bind mounts.Thanks, I am OK with issuing a command before physically unplugging the device. I was just finding too many uses of the word "mount" because it's a verb, a command and a noun in this situation lol. I added my fstab to the top so you can see that I am actually using a bind mount.
I investigated symlinks as an alternative and for some reason decided against them. One thing I like about bind mounts is that there is always a backup directory in the location, so if the USB isn't plugged in, accidentally saved files don't just fall into the void. But I don't remember if that was the reason.
I could write some kind of script but I thought it would make more sense to see if something had already been developed because usually in Linux, it has been.
So, if you have a symlink, what will happen is that trying to save to a path that passes through the symlink will fail, because the program trying to save will fail to access the original path (assuming your above directory structure; /mount/external will exist, but /mount/external/realfolder will not, as realfolder is on your USB drive and won't exist when the media isn't mounted). With most programs, they'll warn you that they couldn't write the file (and in fact, that the directory isn't there). From their standpoint, the path is invalid. You won't typically just save a file and have it vanish.
I guess you could theoretically have something like a script that writes a file data and fails silently if the path doesn't exist. I do think that it might get confusing, to have some files written to the bind mount point in the user directory
I mean, the OS isn't going to merge them when you do the bind mount or anything. You're going to have one directory structure on your removable media that contains some files, and when it's inserted and the bind mount is in place, that's what you'll see, and a second directory structure inside the bind mount that will have different data. Like, if whatever is writing this is something that you control, I think I might set it up to explicitly write somewhere else. Or just create a /mount/external/realfolder directory on the /mount filesystem and give the user write permission to /mount/external/realfolder which will have the same effect, with some data going to a the removable media and some to the directory structure where the mountpoint lives if the media isn't present (just that the files will be written to wherever /mount lives, which may not be the same filesystem as /home/user/; I don't know if that matters for your use case).
But if you do feel that you want to set up a bind mount, then yeah, I'd look at the other comment I have in response to your comment here, the one talking about systemd-udev.