Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Yes it also says that the changes reflect "magically" on both sides. If one side is a directory on the disk and the next side is the mount, and if both sides see the change magically then how can it be a property of the live system? Since even the source is getting change.
-B, --bind mount a subtree somewhere else (same as -o bind)
-R, --rbind mount a subtree and all submounts somewhere else
Quote:
Originally Posted by man mount
Bind mounts
Since Linux 2.4.0 it is possible to remount part of the file hierarchy somewhere else. The call is:
mount --bind olddir newdir
or by using this fstab entry:
/olddir /newdir none bind
After this call the same contents are accessible in two places. One can also remount a single file (on a single file). It's also possible to use the bind
mount to create a mountpoint from a regular directory, for example:
mount --bind foo foo
The bind mount call attaches only (part of) a single filesystem, not possible submounts. The entire file hierarchy including submounts is attached a second
place by using:
mount --rbind olddir newdir
Note that the filesystem mount options will remain the same as those on the original mount point.
mount(8) since v2.27 allows to change the mount options by passing the relevant options along with --bind. For example:
mount --bind,ro foo foo
This feature is not supported by the Linux kernel; it is implemented in userspace by an additional mount(2) remounting syscall. This solution is not
atomic.
The alternative (classic) way to create a read-only bind mount is to use the remount operation, for example:
mount --bind olddir newdir
mount -o remount,ro,bind olddir newdir
Note that a read-only bind will create a read-only mountpoint (VFS entry), but the original filesystem superblock will still be writable, meaning that the
olddir will be writable, but the newdir will be read-only.
It's impossible to change mount options recursively (for example with -o rbind,ro).
Unlike a hard link or symbolic link, a bind mount doesn't affect what is stored on the filesystem.
This is confusing. It just means that the mount itself doesn't write to the filesystem that got mounted over, while a link adds an entry in a directory. Once you unmount a bind mount, the underlying filesystem is unchanged. The mounted filesystem can be read and written and will reflect all of the changes that are made.
When I change a file in the directory that is bind mounted does that change it in the filesystem also?
Why would you do a bind mount?
Yes, it is the same file, so it WILL be changed.
And why using a bind mount: often in preparation of a chroot (change root), when you want i.e. the /dev of the "original" fs visible into the chroot'ed tree, because, of course, after a chroot you won't be able to access any files/directories that were higher in the hierarchy from the new root dir.
The bind mount is only useful when you want to mount part of the filesystem and the normal mounts are useful for mounting block devices. Am I correct?
When I change a file in the directory that is bind mounted does that change it in the filesystem also?
Why would you do a bind mount?
Yes and Yes.
Let's say you want to mount already mounted /usr/share under /mnt/tmp, how would you go about that? This is different than mounting a filesystem block device, say /dev/sda7 under /mnt/tmp.
The folder you want to mount is under an already mounted block device and already mounted. If you try mount /usr/share /mnt/tmp you get an error. If you use mount --bind /usr/share /mnt/tmp you do not.
After you use mount --bind /usr/share /mnt/tmp, whatever is under /usr/share is ALSO visible under /mnt/tmp. This means you basically mount a non-blockdevice under another mountpoint, "duplication", which is otherwise not possible. So the same place is mounted two different places.
Why to use this? I can't answer that.. It can be useful in many cases I would guess. I know one case that I have done myself, during installation of Gentoo where you create a virtual system and set this up using "chroot". One of the steps you do when you chroot into Gentoo before the system is ready for use is the "mount --rbind" both /proc and /sys from your running distro into the chroot Gentoo environment. Why exactly this is necessary I do not know, you'd have to ask Gentoo, but my guess is that you trick Gentoo into thinking it is an actual running environment instead of a chroot, and thus can set the system up as if it was a running system and not a chroot environment.
Let's say you want to mount already mounted /usr/share under /mnt/tmp, how would you go about that? This is different than mounting a filesystem block device, say /dev/sda7 under /mnt/tmp.
The folder you want to mount is under an already mounted block device and already mounted. If you try mount /usr/share /mnt/tmp you get an error. If you use mount --bind /usr/share /mnt/tmp you do not.
After you use mount --bind /usr/share /mnt/tmp, whatever is under /usr/share is ALSO visible under /mnt/tmp. This means you basically mount a non-blockdevice under another mountpoint, "duplication", which is otherwise not possible. So the same place is mounted two different places.
Why to use this? I can't answer that.. It can be useful in many cases I would guess. I know one case that I have done myself, during installation of Gentoo where you create a virtual system and set this up using "chroot". One of the steps you do when you chroot into Gentoo before the system is ready for use is the "mount --rbind" both /proc and /sys from your running distro into the chroot Gentoo environment. Why exactly this is necessary I do not know, you'd have to ask Gentoo, but my guess is that you trick Gentoo into thinking it is an actual running environment instead of a chroot, and thus can set the system up as if it was a running system and not a chroot environment.
Wow. Thanks so much, your explanation really helped. Especially for the mount point duplication part. Let me see if I have any doubts and I will get back to you if necessary.
Why exactly this is necessary I do not know, you'd have to ask Gentoo, but my guess is that you trick Gentoo into thinking it is an actual running environment instead of a chroot, and thus can set the system up as if it was a running system and not a chroot environment.
Pretty much the same as in an installation of Arch, you need the nodes accessible to the environment running inside the chroot. These are special files, and in some cases links don't work the same way.
There are also concerns about levels of links - you can only have so many, and many device nodes are already links to others. For example, on my box,
so you see we're already two levels deep. Bind mounting dev to the new environment's filesystem avoids this.
I've had instances in the past where I needed files in a specific hierarchy, and a link (sym or hard) was unusable - for a variety or reasons - a bind mount was the only way to avoid this.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
