What happens when you 'mount over' an existing folder with contents?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
69
down vote

favorite
20












Right now /tmp has some temporary files in it. When I mount my hard drive (/dev/sdc1) on top of /tmp, I can see the files on the hard drive. What happens to the actual content of /tmp when my hard drive is mounted? Is it possible to perform r/w operations on the actual content of /tmp while the hard drive is mounted?



python@lanix / $ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 286G 43G 229G 16% /
none 4.0K 0 4.0K 0% /sys/fs/cgroup
udev 3.8G 4.0K 3.8G 1% /dev
tmpfs 766M 1.4M 765M 1% /run
none 5.0M 0 5.0M 0% /run/lock
none 3.8G 38M 3.8G 1% /run/shm
none 100M 24K 100M 1% /run/user
/dev/sdb1 7.5G 2.7G 4.9G 35% /mnt
/dev/sdc1 932G 242G 691G 26% /tmp









share|improve this question



























    up vote
    69
    down vote

    favorite
    20












    Right now /tmp has some temporary files in it. When I mount my hard drive (/dev/sdc1) on top of /tmp, I can see the files on the hard drive. What happens to the actual content of /tmp when my hard drive is mounted? Is it possible to perform r/w operations on the actual content of /tmp while the hard drive is mounted?



    python@lanix / $ df -h
    Filesystem Size Used Avail Use% Mounted on
    /dev/sda1 286G 43G 229G 16% /
    none 4.0K 0 4.0K 0% /sys/fs/cgroup
    udev 3.8G 4.0K 3.8G 1% /dev
    tmpfs 766M 1.4M 765M 1% /run
    none 5.0M 0 5.0M 0% /run/lock
    none 3.8G 38M 3.8G 1% /run/shm
    none 100M 24K 100M 1% /run/user
    /dev/sdb1 7.5G 2.7G 4.9G 35% /mnt
    /dev/sdc1 932G 242G 691G 26% /tmp









    share|improve this question

























      up vote
      69
      down vote

      favorite
      20









      up vote
      69
      down vote

      favorite
      20






      20





      Right now /tmp has some temporary files in it. When I mount my hard drive (/dev/sdc1) on top of /tmp, I can see the files on the hard drive. What happens to the actual content of /tmp when my hard drive is mounted? Is it possible to perform r/w operations on the actual content of /tmp while the hard drive is mounted?



      python@lanix / $ df -h
      Filesystem Size Used Avail Use% Mounted on
      /dev/sda1 286G 43G 229G 16% /
      none 4.0K 0 4.0K 0% /sys/fs/cgroup
      udev 3.8G 4.0K 3.8G 1% /dev
      tmpfs 766M 1.4M 765M 1% /run
      none 5.0M 0 5.0M 0% /run/lock
      none 3.8G 38M 3.8G 1% /run/shm
      none 100M 24K 100M 1% /run/user
      /dev/sdb1 7.5G 2.7G 4.9G 35% /mnt
      /dev/sdc1 932G 242G 691G 26% /tmp









      share|improve this question















      Right now /tmp has some temporary files in it. When I mount my hard drive (/dev/sdc1) on top of /tmp, I can see the files on the hard drive. What happens to the actual content of /tmp when my hard drive is mounted? Is it possible to perform r/w operations on the actual content of /tmp while the hard drive is mounted?



      python@lanix / $ df -h
      Filesystem Size Used Avail Use% Mounted on
      /dev/sda1 286G 43G 229G 16% /
      none 4.0K 0 4.0K 0% /sys/fs/cgroup
      udev 3.8G 4.0K 3.8G 1% /dev
      tmpfs 766M 1.4M 765M 1% /run
      none 5.0M 0 5.0M 0% /run/lock
      none 3.8G 38M 3.8G 1% /run/shm
      none 100M 24K 100M 1% /run/user
      /dev/sdb1 7.5G 2.7G 4.9G 35% /mnt
      /dev/sdc1 932G 242G 691G 26% /tmp






      mount tmp






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Apr 25 '15 at 17:21









      Braiam

      22.6k1971132




      22.6k1971132










      asked Apr 25 '15 at 9:15









      user

      5691715




      5691715




















          1 Answer
          1






          active

          oldest

          votes

















          up vote
          102
          down vote



          accepted











          What happens to the actual content of /tmp when my hard drive is mounted?




          Pretty much nothing. They're just hidden from view, not reachable via normal filesystem traversal.




          Is it possible to perform r/w operations on the actual content of /tmp while the hard drive is mounted?




          Yes. Processes that had open file handles inside your "original" /tmp will continue to be able to use them. You can also make the "reappear" somewhere else by bind-mounting / elsewhere.



          # mount -o bind / /somewhere/else
          # ls /somewhere/else/tmp



          Here's a little experiment you can run to get a better (I hope) feel for what is happening.



          Note: This is not an attempt at being perfectly correct or an exhaustive description of what is really happening. Should be just accurate enough to give you the big picture though.



          I created a user called me on my machine, and a random directory in his home, with a file in it:



          me@home $ pwd
          /home/me/tmp
          me@home $ echo hello > some_file
          me@home $ ls
          some_file
          me@home $ cat some_file
          hello


          At this point, nothing unusual - it's just a plain directory with a plain file. I leave that session open right as it is, with its cwd inside that test directory.



          As root, I create a small filesystem and mount it over /home/me/tmp.



          root@home # dd if=/dev/zero of=./fs bs=1M count=10
          10+0 records in
          10+0 records out
          10485760 bytes (10 MB) copied, 0.00467318 s, 2.2 GB/s

          root@home # mkfs -t ext2 ./fs
          mke2fs 1.42.12 (29-Aug-2014)
          [... snip ...]
          Writing superblocks and filesystem accounting information: done

          root@home # mount ./fs /home/me/tmp


          I then open a new terminal as me, and look around:



          me@home #2 $ cd tmp
          me@home #2 $ ls
          lost+found
          me@home #2 $ cat some_file
          cat: some_file: No such file or directory
          me@home #2 $ echo bye bye > some_file
          -su: some_file: Permission denied


          So, that file we created is clearly not there. The lost+found directory is indicative of the root of an ext filesystem. And I lost write permission, so it's clearly not the original directory.



          Back to the first me session, let's look at how it sees the world:



          me@home $ echo something else > other_file


          No problem writing.



          me@home $ cat some_file other_file 
          hello
          something else


          Original file is still there, new file created without issue.



          Huh? What's going on?



          The first session entered the directory before it was overlayed by root mounting another filesystem on it. That mount action doesn't affect the original filesystem at all. The shell process has a perfectly valid handle to the directory in the original filesystem, and can continue interacting with it. It's sort of running around beneath the carpet mount point.



          The second session entered the directory after the mount was laid down. So it sees the new, empty filesystem. And the sysadmin borked the permissions, so it can't use the requested space... lets fix that.



          root@home # chown me:users /home/me/tmp




          me@home #2 $ echo bye bye > some_file
          me@home #2 $ ls
          lost+found some_file
          me@home #2 $ cat some_file
          bye bye


          Can session 1 escape from under the rug? (It's getting musty.)



          Sure! If session 1 moves back up the filesystem tree out of the mount, it will lose that handle to the inside and will follow the mount like everyone else.



          me@home $ cd
          me@home $ pwd
          /home/me
          me@home $ cd tmp
          me@home $ cat some_file other_file
          bye bye
          cat: other_file: No such file or directory


          Same view as session #2, we're back to normal.



          But how do you know the files didn't disappear? No one's looking anymore!



          That's one of the moments where bind mounts become handy. They let you mount an already mounted filesystem somewhere else.



          me@home $ mkdir ~/bind




          root@home # mount -o bind /home/me /home/me/bind


          (Yes, you can bind-mount a filesystem "inside itself". Cool trick, eh?)





          me@home $ ls bind/tmp
          other_file some_file
          me@home $ cat bind/tmp/*
          something else
          hello


          So they are indeed there, ready for action. It's simply that they're not visible/reachable at their original location, the mount hides them from normal directory traversals.




          I encourage you to play around with this, it is really not complicated once you've understood the "trick" that is being played. And once you've Got Itâ„¢, look into union filesystems for even more carpet pulling :-)



          One note though: mounting over /tmp or /var (or any of the core OS directories) really isn't a good idea once the boot process is finished. A lot of applications leave state in those directories, and might get seriously confused if you play mount games around them.






          share|improve this answer


















          • 4




            This is a great answer - you have gone above and beyond what I asked of you. The idea of bind-mount is pretty cool too! Thanks for the detailed answer. Cheers.
            – user
            Apr 25 '15 at 15:35






          • 10




            This is a very common way to mysteriously lose disk space. If a mount fails for whatever reason in a startup script, data can be written to the directory on the root filesystem. If a restart is then attempted, the mount can succeed and maybe nobody will notice (for example, if the filesystem contains tmp files or logs), except it will eat space, maybe a lot.
            – Dan Sheppard
            Apr 25 '15 at 19:40






          • 2




            @DanSheppard That's one reason I like my mount points set chmod 000. Also why systemd fails the boot if critical mounts fail.
            – Zan Lynx
            Dec 26 '15 at 13:41










          • Could you also -bind mount /home/me on /home/me instead of the "bind" folder? I.e. put another carpet on top of the carpet. Or would you have to unmount fs first?
            – jiggunjer
            Jan 29 '17 at 17:23










          • @jiggunjer It seems union option can help.
            – hliu
            Jun 29 '17 at 6:02










          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',
          convertImagesToLinks: false,
          noModals: false,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: null,
          bindNavPrevention: true,
          postfix: "",
          onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          );



          );













           

          draft saved


          draft discarded


















          StackExchange.ready(
          function ()
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f198542%2fwhat-happens-when-you-mount-over-an-existing-folder-with-contents%23new-answer', 'question_page');

          );

          Post as a guest






























          1 Answer
          1






          active

          oldest

          votes








          1 Answer
          1






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes








          up vote
          102
          down vote



          accepted











          What happens to the actual content of /tmp when my hard drive is mounted?




          Pretty much nothing. They're just hidden from view, not reachable via normal filesystem traversal.




          Is it possible to perform r/w operations on the actual content of /tmp while the hard drive is mounted?




          Yes. Processes that had open file handles inside your "original" /tmp will continue to be able to use them. You can also make the "reappear" somewhere else by bind-mounting / elsewhere.



          # mount -o bind / /somewhere/else
          # ls /somewhere/else/tmp



          Here's a little experiment you can run to get a better (I hope) feel for what is happening.



          Note: This is not an attempt at being perfectly correct or an exhaustive description of what is really happening. Should be just accurate enough to give you the big picture though.



          I created a user called me on my machine, and a random directory in his home, with a file in it:



          me@home $ pwd
          /home/me/tmp
          me@home $ echo hello > some_file
          me@home $ ls
          some_file
          me@home $ cat some_file
          hello


          At this point, nothing unusual - it's just a plain directory with a plain file. I leave that session open right as it is, with its cwd inside that test directory.



          As root, I create a small filesystem and mount it over /home/me/tmp.



          root@home # dd if=/dev/zero of=./fs bs=1M count=10
          10+0 records in
          10+0 records out
          10485760 bytes (10 MB) copied, 0.00467318 s, 2.2 GB/s

          root@home # mkfs -t ext2 ./fs
          mke2fs 1.42.12 (29-Aug-2014)
          [... snip ...]
          Writing superblocks and filesystem accounting information: done

          root@home # mount ./fs /home/me/tmp


          I then open a new terminal as me, and look around:



          me@home #2 $ cd tmp
          me@home #2 $ ls
          lost+found
          me@home #2 $ cat some_file
          cat: some_file: No such file or directory
          me@home #2 $ echo bye bye > some_file
          -su: some_file: Permission denied


          So, that file we created is clearly not there. The lost+found directory is indicative of the root of an ext filesystem. And I lost write permission, so it's clearly not the original directory.



          Back to the first me session, let's look at how it sees the world:



          me@home $ echo something else > other_file


          No problem writing.



          me@home $ cat some_file other_file 
          hello
          something else


          Original file is still there, new file created without issue.



          Huh? What's going on?



          The first session entered the directory before it was overlayed by root mounting another filesystem on it. That mount action doesn't affect the original filesystem at all. The shell process has a perfectly valid handle to the directory in the original filesystem, and can continue interacting with it. It's sort of running around beneath the carpet mount point.



          The second session entered the directory after the mount was laid down. So it sees the new, empty filesystem. And the sysadmin borked the permissions, so it can't use the requested space... lets fix that.



          root@home # chown me:users /home/me/tmp




          me@home #2 $ echo bye bye > some_file
          me@home #2 $ ls
          lost+found some_file
          me@home #2 $ cat some_file
          bye bye


          Can session 1 escape from under the rug? (It's getting musty.)



          Sure! If session 1 moves back up the filesystem tree out of the mount, it will lose that handle to the inside and will follow the mount like everyone else.



          me@home $ cd
          me@home $ pwd
          /home/me
          me@home $ cd tmp
          me@home $ cat some_file other_file
          bye bye
          cat: other_file: No such file or directory


          Same view as session #2, we're back to normal.



          But how do you know the files didn't disappear? No one's looking anymore!



          That's one of the moments where bind mounts become handy. They let you mount an already mounted filesystem somewhere else.



          me@home $ mkdir ~/bind




          root@home # mount -o bind /home/me /home/me/bind


          (Yes, you can bind-mount a filesystem "inside itself". Cool trick, eh?)





          me@home $ ls bind/tmp
          other_file some_file
          me@home $ cat bind/tmp/*
          something else
          hello


          So they are indeed there, ready for action. It's simply that they're not visible/reachable at their original location, the mount hides them from normal directory traversals.




          I encourage you to play around with this, it is really not complicated once you've understood the "trick" that is being played. And once you've Got Itâ„¢, look into union filesystems for even more carpet pulling :-)



          One note though: mounting over /tmp or /var (or any of the core OS directories) really isn't a good idea once the boot process is finished. A lot of applications leave state in those directories, and might get seriously confused if you play mount games around them.






          share|improve this answer


















          • 4




            This is a great answer - you have gone above and beyond what I asked of you. The idea of bind-mount is pretty cool too! Thanks for the detailed answer. Cheers.
            – user
            Apr 25 '15 at 15:35






          • 10




            This is a very common way to mysteriously lose disk space. If a mount fails for whatever reason in a startup script, data can be written to the directory on the root filesystem. If a restart is then attempted, the mount can succeed and maybe nobody will notice (for example, if the filesystem contains tmp files or logs), except it will eat space, maybe a lot.
            – Dan Sheppard
            Apr 25 '15 at 19:40






          • 2




            @DanSheppard That's one reason I like my mount points set chmod 000. Also why systemd fails the boot if critical mounts fail.
            – Zan Lynx
            Dec 26 '15 at 13:41










          • Could you also -bind mount /home/me on /home/me instead of the "bind" folder? I.e. put another carpet on top of the carpet. Or would you have to unmount fs first?
            – jiggunjer
            Jan 29 '17 at 17:23










          • @jiggunjer It seems union option can help.
            – hliu
            Jun 29 '17 at 6:02














          up vote
          102
          down vote



          accepted











          What happens to the actual content of /tmp when my hard drive is mounted?




          Pretty much nothing. They're just hidden from view, not reachable via normal filesystem traversal.




          Is it possible to perform r/w operations on the actual content of /tmp while the hard drive is mounted?




          Yes. Processes that had open file handles inside your "original" /tmp will continue to be able to use them. You can also make the "reappear" somewhere else by bind-mounting / elsewhere.



          # mount -o bind / /somewhere/else
          # ls /somewhere/else/tmp



          Here's a little experiment you can run to get a better (I hope) feel for what is happening.



          Note: This is not an attempt at being perfectly correct or an exhaustive description of what is really happening. Should be just accurate enough to give you the big picture though.



          I created a user called me on my machine, and a random directory in his home, with a file in it:



          me@home $ pwd
          /home/me/tmp
          me@home $ echo hello > some_file
          me@home $ ls
          some_file
          me@home $ cat some_file
          hello


          At this point, nothing unusual - it's just a plain directory with a plain file. I leave that session open right as it is, with its cwd inside that test directory.



          As root, I create a small filesystem and mount it over /home/me/tmp.



          root@home # dd if=/dev/zero of=./fs bs=1M count=10
          10+0 records in
          10+0 records out
          10485760 bytes (10 MB) copied, 0.00467318 s, 2.2 GB/s

          root@home # mkfs -t ext2 ./fs
          mke2fs 1.42.12 (29-Aug-2014)
          [... snip ...]
          Writing superblocks and filesystem accounting information: done

          root@home # mount ./fs /home/me/tmp


          I then open a new terminal as me, and look around:



          me@home #2 $ cd tmp
          me@home #2 $ ls
          lost+found
          me@home #2 $ cat some_file
          cat: some_file: No such file or directory
          me@home #2 $ echo bye bye > some_file
          -su: some_file: Permission denied


          So, that file we created is clearly not there. The lost+found directory is indicative of the root of an ext filesystem. And I lost write permission, so it's clearly not the original directory.



          Back to the first me session, let's look at how it sees the world:



          me@home $ echo something else > other_file


          No problem writing.



          me@home $ cat some_file other_file 
          hello
          something else


          Original file is still there, new file created without issue.



          Huh? What's going on?



          The first session entered the directory before it was overlayed by root mounting another filesystem on it. That mount action doesn't affect the original filesystem at all. The shell process has a perfectly valid handle to the directory in the original filesystem, and can continue interacting with it. It's sort of running around beneath the carpet mount point.



          The second session entered the directory after the mount was laid down. So it sees the new, empty filesystem. And the sysadmin borked the permissions, so it can't use the requested space... lets fix that.



          root@home # chown me:users /home/me/tmp




          me@home #2 $ echo bye bye > some_file
          me@home #2 $ ls
          lost+found some_file
          me@home #2 $ cat some_file
          bye bye


          Can session 1 escape from under the rug? (It's getting musty.)



          Sure! If session 1 moves back up the filesystem tree out of the mount, it will lose that handle to the inside and will follow the mount like everyone else.



          me@home $ cd
          me@home $ pwd
          /home/me
          me@home $ cd tmp
          me@home $ cat some_file other_file
          bye bye
          cat: other_file: No such file or directory


          Same view as session #2, we're back to normal.



          But how do you know the files didn't disappear? No one's looking anymore!



          That's one of the moments where bind mounts become handy. They let you mount an already mounted filesystem somewhere else.



          me@home $ mkdir ~/bind




          root@home # mount -o bind /home/me /home/me/bind


          (Yes, you can bind-mount a filesystem "inside itself". Cool trick, eh?)





          me@home $ ls bind/tmp
          other_file some_file
          me@home $ cat bind/tmp/*
          something else
          hello


          So they are indeed there, ready for action. It's simply that they're not visible/reachable at their original location, the mount hides them from normal directory traversals.




          I encourage you to play around with this, it is really not complicated once you've understood the "trick" that is being played. And once you've Got Itâ„¢, look into union filesystems for even more carpet pulling :-)



          One note though: mounting over /tmp or /var (or any of the core OS directories) really isn't a good idea once the boot process is finished. A lot of applications leave state in those directories, and might get seriously confused if you play mount games around them.






          share|improve this answer


















          • 4




            This is a great answer - you have gone above and beyond what I asked of you. The idea of bind-mount is pretty cool too! Thanks for the detailed answer. Cheers.
            – user
            Apr 25 '15 at 15:35






          • 10




            This is a very common way to mysteriously lose disk space. If a mount fails for whatever reason in a startup script, data can be written to the directory on the root filesystem. If a restart is then attempted, the mount can succeed and maybe nobody will notice (for example, if the filesystem contains tmp files or logs), except it will eat space, maybe a lot.
            – Dan Sheppard
            Apr 25 '15 at 19:40






          • 2




            @DanSheppard That's one reason I like my mount points set chmod 000. Also why systemd fails the boot if critical mounts fail.
            – Zan Lynx
            Dec 26 '15 at 13:41










          • Could you also -bind mount /home/me on /home/me instead of the "bind" folder? I.e. put another carpet on top of the carpet. Or would you have to unmount fs first?
            – jiggunjer
            Jan 29 '17 at 17:23










          • @jiggunjer It seems union option can help.
            – hliu
            Jun 29 '17 at 6:02












          up vote
          102
          down vote



          accepted







          up vote
          102
          down vote



          accepted







          What happens to the actual content of /tmp when my hard drive is mounted?




          Pretty much nothing. They're just hidden from view, not reachable via normal filesystem traversal.




          Is it possible to perform r/w operations on the actual content of /tmp while the hard drive is mounted?




          Yes. Processes that had open file handles inside your "original" /tmp will continue to be able to use them. You can also make the "reappear" somewhere else by bind-mounting / elsewhere.



          # mount -o bind / /somewhere/else
          # ls /somewhere/else/tmp



          Here's a little experiment you can run to get a better (I hope) feel for what is happening.



          Note: This is not an attempt at being perfectly correct or an exhaustive description of what is really happening. Should be just accurate enough to give you the big picture though.



          I created a user called me on my machine, and a random directory in his home, with a file in it:



          me@home $ pwd
          /home/me/tmp
          me@home $ echo hello > some_file
          me@home $ ls
          some_file
          me@home $ cat some_file
          hello


          At this point, nothing unusual - it's just a plain directory with a plain file. I leave that session open right as it is, with its cwd inside that test directory.



          As root, I create a small filesystem and mount it over /home/me/tmp.



          root@home # dd if=/dev/zero of=./fs bs=1M count=10
          10+0 records in
          10+0 records out
          10485760 bytes (10 MB) copied, 0.00467318 s, 2.2 GB/s

          root@home # mkfs -t ext2 ./fs
          mke2fs 1.42.12 (29-Aug-2014)
          [... snip ...]
          Writing superblocks and filesystem accounting information: done

          root@home # mount ./fs /home/me/tmp


          I then open a new terminal as me, and look around:



          me@home #2 $ cd tmp
          me@home #2 $ ls
          lost+found
          me@home #2 $ cat some_file
          cat: some_file: No such file or directory
          me@home #2 $ echo bye bye > some_file
          -su: some_file: Permission denied


          So, that file we created is clearly not there. The lost+found directory is indicative of the root of an ext filesystem. And I lost write permission, so it's clearly not the original directory.



          Back to the first me session, let's look at how it sees the world:



          me@home $ echo something else > other_file


          No problem writing.



          me@home $ cat some_file other_file 
          hello
          something else


          Original file is still there, new file created without issue.



          Huh? What's going on?



          The first session entered the directory before it was overlayed by root mounting another filesystem on it. That mount action doesn't affect the original filesystem at all. The shell process has a perfectly valid handle to the directory in the original filesystem, and can continue interacting with it. It's sort of running around beneath the carpet mount point.



          The second session entered the directory after the mount was laid down. So it sees the new, empty filesystem. And the sysadmin borked the permissions, so it can't use the requested space... lets fix that.



          root@home # chown me:users /home/me/tmp




          me@home #2 $ echo bye bye > some_file
          me@home #2 $ ls
          lost+found some_file
          me@home #2 $ cat some_file
          bye bye


          Can session 1 escape from under the rug? (It's getting musty.)



          Sure! If session 1 moves back up the filesystem tree out of the mount, it will lose that handle to the inside and will follow the mount like everyone else.



          me@home $ cd
          me@home $ pwd
          /home/me
          me@home $ cd tmp
          me@home $ cat some_file other_file
          bye bye
          cat: other_file: No such file or directory


          Same view as session #2, we're back to normal.



          But how do you know the files didn't disappear? No one's looking anymore!



          That's one of the moments where bind mounts become handy. They let you mount an already mounted filesystem somewhere else.



          me@home $ mkdir ~/bind




          root@home # mount -o bind /home/me /home/me/bind


          (Yes, you can bind-mount a filesystem "inside itself". Cool trick, eh?)





          me@home $ ls bind/tmp
          other_file some_file
          me@home $ cat bind/tmp/*
          something else
          hello


          So they are indeed there, ready for action. It's simply that they're not visible/reachable at their original location, the mount hides them from normal directory traversals.




          I encourage you to play around with this, it is really not complicated once you've understood the "trick" that is being played. And once you've Got Itâ„¢, look into union filesystems for even more carpet pulling :-)



          One note though: mounting over /tmp or /var (or any of the core OS directories) really isn't a good idea once the boot process is finished. A lot of applications leave state in those directories, and might get seriously confused if you play mount games around them.






          share|improve this answer















          What happens to the actual content of /tmp when my hard drive is mounted?




          Pretty much nothing. They're just hidden from view, not reachable via normal filesystem traversal.




          Is it possible to perform r/w operations on the actual content of /tmp while the hard drive is mounted?




          Yes. Processes that had open file handles inside your "original" /tmp will continue to be able to use them. You can also make the "reappear" somewhere else by bind-mounting / elsewhere.



          # mount -o bind / /somewhere/else
          # ls /somewhere/else/tmp



          Here's a little experiment you can run to get a better (I hope) feel for what is happening.



          Note: This is not an attempt at being perfectly correct or an exhaustive description of what is really happening. Should be just accurate enough to give you the big picture though.



          I created a user called me on my machine, and a random directory in his home, with a file in it:



          me@home $ pwd
          /home/me/tmp
          me@home $ echo hello > some_file
          me@home $ ls
          some_file
          me@home $ cat some_file
          hello


          At this point, nothing unusual - it's just a plain directory with a plain file. I leave that session open right as it is, with its cwd inside that test directory.



          As root, I create a small filesystem and mount it over /home/me/tmp.



          root@home # dd if=/dev/zero of=./fs bs=1M count=10
          10+0 records in
          10+0 records out
          10485760 bytes (10 MB) copied, 0.00467318 s, 2.2 GB/s

          root@home # mkfs -t ext2 ./fs
          mke2fs 1.42.12 (29-Aug-2014)
          [... snip ...]
          Writing superblocks and filesystem accounting information: done

          root@home # mount ./fs /home/me/tmp


          I then open a new terminal as me, and look around:



          me@home #2 $ cd tmp
          me@home #2 $ ls
          lost+found
          me@home #2 $ cat some_file
          cat: some_file: No such file or directory
          me@home #2 $ echo bye bye > some_file
          -su: some_file: Permission denied


          So, that file we created is clearly not there. The lost+found directory is indicative of the root of an ext filesystem. And I lost write permission, so it's clearly not the original directory.



          Back to the first me session, let's look at how it sees the world:



          me@home $ echo something else > other_file


          No problem writing.



          me@home $ cat some_file other_file 
          hello
          something else


          Original file is still there, new file created without issue.



          Huh? What's going on?



          The first session entered the directory before it was overlayed by root mounting another filesystem on it. That mount action doesn't affect the original filesystem at all. The shell process has a perfectly valid handle to the directory in the original filesystem, and can continue interacting with it. It's sort of running around beneath the carpet mount point.



          The second session entered the directory after the mount was laid down. So it sees the new, empty filesystem. And the sysadmin borked the permissions, so it can't use the requested space... lets fix that.



          root@home # chown me:users /home/me/tmp




          me@home #2 $ echo bye bye > some_file
          me@home #2 $ ls
          lost+found some_file
          me@home #2 $ cat some_file
          bye bye


          Can session 1 escape from under the rug? (It's getting musty.)



          Sure! If session 1 moves back up the filesystem tree out of the mount, it will lose that handle to the inside and will follow the mount like everyone else.



          me@home $ cd
          me@home $ pwd
          /home/me
          me@home $ cd tmp
          me@home $ cat some_file other_file
          bye bye
          cat: other_file: No such file or directory


          Same view as session #2, we're back to normal.



          But how do you know the files didn't disappear? No one's looking anymore!



          That's one of the moments where bind mounts become handy. They let you mount an already mounted filesystem somewhere else.



          me@home $ mkdir ~/bind




          root@home # mount -o bind /home/me /home/me/bind


          (Yes, you can bind-mount a filesystem "inside itself". Cool trick, eh?)





          me@home $ ls bind/tmp
          other_file some_file
          me@home $ cat bind/tmp/*
          something else
          hello


          So they are indeed there, ready for action. It's simply that they're not visible/reachable at their original location, the mount hides them from normal directory traversals.




          I encourage you to play around with this, it is really not complicated once you've understood the "trick" that is being played. And once you've Got Itâ„¢, look into union filesystems for even more carpet pulling :-)



          One note though: mounting over /tmp or /var (or any of the core OS directories) really isn't a good idea once the boot process is finished. A lot of applications leave state in those directories, and might get seriously confused if you play mount games around them.







          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited Apr 25 '15 at 14:55

























          answered Apr 25 '15 at 9:23









          Mat

          37.9k7114123




          37.9k7114123







          • 4




            This is a great answer - you have gone above and beyond what I asked of you. The idea of bind-mount is pretty cool too! Thanks for the detailed answer. Cheers.
            – user
            Apr 25 '15 at 15:35






          • 10




            This is a very common way to mysteriously lose disk space. If a mount fails for whatever reason in a startup script, data can be written to the directory on the root filesystem. If a restart is then attempted, the mount can succeed and maybe nobody will notice (for example, if the filesystem contains tmp files or logs), except it will eat space, maybe a lot.
            – Dan Sheppard
            Apr 25 '15 at 19:40






          • 2




            @DanSheppard That's one reason I like my mount points set chmod 000. Also why systemd fails the boot if critical mounts fail.
            – Zan Lynx
            Dec 26 '15 at 13:41










          • Could you also -bind mount /home/me on /home/me instead of the "bind" folder? I.e. put another carpet on top of the carpet. Or would you have to unmount fs first?
            – jiggunjer
            Jan 29 '17 at 17:23










          • @jiggunjer It seems union option can help.
            – hliu
            Jun 29 '17 at 6:02












          • 4




            This is a great answer - you have gone above and beyond what I asked of you. The idea of bind-mount is pretty cool too! Thanks for the detailed answer. Cheers.
            – user
            Apr 25 '15 at 15:35






          • 10




            This is a very common way to mysteriously lose disk space. If a mount fails for whatever reason in a startup script, data can be written to the directory on the root filesystem. If a restart is then attempted, the mount can succeed and maybe nobody will notice (for example, if the filesystem contains tmp files or logs), except it will eat space, maybe a lot.
            – Dan Sheppard
            Apr 25 '15 at 19:40






          • 2




            @DanSheppard That's one reason I like my mount points set chmod 000. Also why systemd fails the boot if critical mounts fail.
            – Zan Lynx
            Dec 26 '15 at 13:41










          • Could you also -bind mount /home/me on /home/me instead of the "bind" folder? I.e. put another carpet on top of the carpet. Or would you have to unmount fs first?
            – jiggunjer
            Jan 29 '17 at 17:23










          • @jiggunjer It seems union option can help.
            – hliu
            Jun 29 '17 at 6:02







          4




          4




          This is a great answer - you have gone above and beyond what I asked of you. The idea of bind-mount is pretty cool too! Thanks for the detailed answer. Cheers.
          – user
          Apr 25 '15 at 15:35




          This is a great answer - you have gone above and beyond what I asked of you. The idea of bind-mount is pretty cool too! Thanks for the detailed answer. Cheers.
          – user
          Apr 25 '15 at 15:35




          10




          10




          This is a very common way to mysteriously lose disk space. If a mount fails for whatever reason in a startup script, data can be written to the directory on the root filesystem. If a restart is then attempted, the mount can succeed and maybe nobody will notice (for example, if the filesystem contains tmp files or logs), except it will eat space, maybe a lot.
          – Dan Sheppard
          Apr 25 '15 at 19:40




          This is a very common way to mysteriously lose disk space. If a mount fails for whatever reason in a startup script, data can be written to the directory on the root filesystem. If a restart is then attempted, the mount can succeed and maybe nobody will notice (for example, if the filesystem contains tmp files or logs), except it will eat space, maybe a lot.
          – Dan Sheppard
          Apr 25 '15 at 19:40




          2




          2




          @DanSheppard That's one reason I like my mount points set chmod 000. Also why systemd fails the boot if critical mounts fail.
          – Zan Lynx
          Dec 26 '15 at 13:41




          @DanSheppard That's one reason I like my mount points set chmod 000. Also why systemd fails the boot if critical mounts fail.
          – Zan Lynx
          Dec 26 '15 at 13:41












          Could you also -bind mount /home/me on /home/me instead of the "bind" folder? I.e. put another carpet on top of the carpet. Or would you have to unmount fs first?
          – jiggunjer
          Jan 29 '17 at 17:23




          Could you also -bind mount /home/me on /home/me instead of the "bind" folder? I.e. put another carpet on top of the carpet. Or would you have to unmount fs first?
          – jiggunjer
          Jan 29 '17 at 17:23












          @jiggunjer It seems union option can help.
          – hliu
          Jun 29 '17 at 6:02




          @jiggunjer It seems union option can help.
          – hliu
          Jun 29 '17 at 6:02

















           

          draft saved


          draft discarded















































           


          draft saved


          draft discarded














          StackExchange.ready(
          function ()
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f198542%2fwhat-happens-when-you-mount-over-an-existing-folder-with-contents%23new-answer', 'question_page');

          );

          Post as a guest













































































          Popular posts from this blog

          How to check contact read email or not when send email to Individual?

          Displaying single band from multi-band raster using QGIS

          How many registers does an x86_64 CPU actually have?