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?

Community Rules

founded 2 years ago
MODERATORS
 

I have bind mounts configured in my /etc/fstab. The source (i.e. where the files physically exist) is on a removable USB drive.

Right now it works but I have to mount/unmount everything individually when I plug/unplug the drive. I would like to be able to have the bind mounts follow the state of of the USB drive automatically.

Is there a way?

Edit here is relevant section of fstab:

/dev/mapper/external-crypt	/mount/external		auto	nosuid,nodev,nofail,x-systemd.device-timeout=5	0 0
/mount/external/realfolder	/home/user/folder	none	bind,nofail	0 0

So when I run sudo mount "/mount/external" I want sudo mount /home/user/folder to be implied; likewise for umount.

you are viewing a single comment's thread
view the rest of the comments
[–] tal@lemmy.today 2 points 1 day ago* (last edited 1 day ago) (2 children)

mount/unmount everything individually when I plug/unplug the drive.

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.

[–] tal@lemmy.today 1 points 1 day ago* (last edited 1 day ago)

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:

$ ln -s /mount/external/realfolder /home/user/folder

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 mount command directly, as it runs commands in a private namespace; it should use systemd-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 the systemd-mount command. 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.

[–] linuxPIPEpower@discuss.tchncs.de 1 points 1 day ago (1 children)

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.

[–] tal@lemmy.today 1 points 1 day ago

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.

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.