Is `chown user:user lost+found` harmful?

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












8















Recently I created an encrypted filesystem (crypto_LUKS) that serves as $HOME for just one particular user (i.e. I mount it as /home/pduck). I also added an appropriate entry in /etc/security/pam_mount.conf.xml so that the partition gets automatically decrypted and mounted when the user logs in (and unmounted when he logs off). Works great.



Because the $HOME is a filesystem on its own, the user has a lost+found directory owned by root:root in it. I know that deleting the directory is a bad idea but many commands (e.g. find) complain about having no access. That annoys me.



Out of curiosity I removed the directory and recreated it with mklost+found (without sudo). Now the directory is owned by pduck:pduck. Is that ok or is it crucial that the directory is owned by root:root?










share|improve this question






















  • Not all file systems have a lost+found directory. Ext4 does, XFS doesn’t, for example.

    – jornane
    Jan 27 at 20:24











  • Not an answer, but you could just create a script or alias for find (preferably with a different name) that starts with a 2>/dev/null which silences those error messages. If you put it at the beginning, then it won't interfere with whatever arguments you want to pass to find in each invocation.

    – Joe
    Jan 31 at 12:55















8















Recently I created an encrypted filesystem (crypto_LUKS) that serves as $HOME for just one particular user (i.e. I mount it as /home/pduck). I also added an appropriate entry in /etc/security/pam_mount.conf.xml so that the partition gets automatically decrypted and mounted when the user logs in (and unmounted when he logs off). Works great.



Because the $HOME is a filesystem on its own, the user has a lost+found directory owned by root:root in it. I know that deleting the directory is a bad idea but many commands (e.g. find) complain about having no access. That annoys me.



Out of curiosity I removed the directory and recreated it with mklost+found (without sudo). Now the directory is owned by pduck:pduck. Is that ok or is it crucial that the directory is owned by root:root?










share|improve this question






















  • Not all file systems have a lost+found directory. Ext4 does, XFS doesn’t, for example.

    – jornane
    Jan 27 at 20:24











  • Not an answer, but you could just create a script or alias for find (preferably with a different name) that starts with a 2>/dev/null which silences those error messages. If you put it at the beginning, then it won't interfere with whatever arguments you want to pass to find in each invocation.

    – Joe
    Jan 31 at 12:55













8












8








8








Recently I created an encrypted filesystem (crypto_LUKS) that serves as $HOME for just one particular user (i.e. I mount it as /home/pduck). I also added an appropriate entry in /etc/security/pam_mount.conf.xml so that the partition gets automatically decrypted and mounted when the user logs in (and unmounted when he logs off). Works great.



Because the $HOME is a filesystem on its own, the user has a lost+found directory owned by root:root in it. I know that deleting the directory is a bad idea but many commands (e.g. find) complain about having no access. That annoys me.



Out of curiosity I removed the directory and recreated it with mklost+found (without sudo). Now the directory is owned by pduck:pduck. Is that ok or is it crucial that the directory is owned by root:root?










share|improve this question














Recently I created an encrypted filesystem (crypto_LUKS) that serves as $HOME for just one particular user (i.e. I mount it as /home/pduck). I also added an appropriate entry in /etc/security/pam_mount.conf.xml so that the partition gets automatically decrypted and mounted when the user logs in (and unmounted when he logs off). Works great.



Because the $HOME is a filesystem on its own, the user has a lost+found directory owned by root:root in it. I know that deleting the directory is a bad idea but many commands (e.g. find) complain about having no access. That annoys me.



Out of curiosity I removed the directory and recreated it with mklost+found (without sudo). Now the directory is owned by pduck:pduck. Is that ok or is it crucial that the directory is owned by root:root?







partitioning permissions mount chown






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Jan 27 at 13:58









PerlDuckPerlDuck

6,69211535




6,69211535












  • Not all file systems have a lost+found directory. Ext4 does, XFS doesn’t, for example.

    – jornane
    Jan 27 at 20:24











  • Not an answer, but you could just create a script or alias for find (preferably with a different name) that starts with a 2>/dev/null which silences those error messages. If you put it at the beginning, then it won't interfere with whatever arguments you want to pass to find in each invocation.

    – Joe
    Jan 31 at 12:55

















  • Not all file systems have a lost+found directory. Ext4 does, XFS doesn’t, for example.

    – jornane
    Jan 27 at 20:24











  • Not an answer, but you could just create a script or alias for find (preferably with a different name) that starts with a 2>/dev/null which silences those error messages. If you put it at the beginning, then it won't interfere with whatever arguments you want to pass to find in each invocation.

    – Joe
    Jan 31 at 12:55
















Not all file systems have a lost+found directory. Ext4 does, XFS doesn’t, for example.

– jornane
Jan 27 at 20:24





Not all file systems have a lost+found directory. Ext4 does, XFS doesn’t, for example.

– jornane
Jan 27 at 20:24













Not an answer, but you could just create a script or alias for find (preferably with a different name) that starts with a 2>/dev/null which silences those error messages. If you put it at the beginning, then it won't interfere with whatever arguments you want to pass to find in each invocation.

– Joe
Jan 31 at 12:55





Not an answer, but you could just create a script or alias for find (preferably with a different name) that starts with a 2>/dev/null which silences those error messages. If you put it at the beginning, then it won't interfere with whatever arguments you want to pass to find in each invocation.

– Joe
Jan 31 at 12:55










3 Answers
3






active

oldest

votes


















10














Good advice comes with a rationale so that you can tell when it becomes bad advice.



The purpose of lost+found being owned by root is so that no matter whose file it was that was lost it's not suddenly exposed to everybody. However, in this case, there shouldn't be a single file in the entire filesystem* not owned by pduck; therefore there is no downside to lost+found not being owned by pduck.



*barring exotic situations like pduck suing to root and running an X application. But if pduck can use sudo or su than we're talking about nothing because pduck can break system security outright.






share|improve this answer
































    6














    lost+found is a system directory, and I avoid tampering with the ownership and permissions of system directories and files.



    There are other directories (and files), that make find complain, unless I elevate the permissions of the command line, so I suggest that you use



    sudo find ...


    and leave lost+found as it is/should be.






    share|improve this answer


















    • 2





      Yes, so thought I, but OTOH there is that mklost+found command to create it and it creates it with my ownership. Maybe it's just a horribly written command that doesn't check for $UID!=0 ;-) Also, I don't like the idea of being forced (more or less) to use sudo in my very own $HOME.

      – PerlDuck
      Jan 27 at 14:08












    • lost+found is very old, I think from early UNIX days, and I don't really know when it is used nowadays. But I think it is a good general policy to avoid tampering with the ownership and permissions of system directories and files (unless you really know what can happen behind the scene).

      – sudodus
      Jan 27 at 14:12






    • 5





      Doesn't fsck put files in there when it encounters "lost" files? The idea is that fsck already has a place to put the files into (instead of first creating one). Note that lost+found occupies more space (16384 bytes) than an ordinary empty directory (4096 bytes).

      – PerlDuck
      Jan 27 at 14:16











    • Yes, at least that was the original purpose (similar to what chkdsk did with lost files in MSDOS), but I have seldom if ever seen any data there in linux. Maybe journaling can restore the files to where they were before, so they need not go to lost+found. -- By the way, I have a lost+found directory in /home, but not in my home directory /home/sudodus, so it does not bother me there.

      – sudodus
      Jan 27 at 14:26







    • 1





      I agree. And in /home I have another l+f (doesn't bother me either) because /home and /home/pduck are separate partitions on my machine. The latter is encrypted, the former is not. However, when it annoys me too much, I can mount my $HOME somewhere else and bind-mount it to my actual $HOME (like I outlined here, for example) to completely get rid of l+f in my $HOME. /// I'll delete my comments in a couple of minutes/hours to avoid that "extended discussion … move to chat" alert.

      – PerlDuck
      Jan 27 at 14:37


















    3














    There is nothing really magical about the lost+found directory. It's just a plain directory just like any other and is only used to hold lost files/directories found during a fsck after a system crash or filesystem corruption. It's created during mkfs when the file system is created and is normally empty. The only reason for the default permissions is to avoid sensitive files from becoming visible to regular users if they are found and recovered during an fsck. In the modern era it's rare to see files get lost and put into that folder. If it's removed, I believe fsck will recreate it as needed if there happens to be any files that need to be put into there. Since this is a file system for one user and his data alone with no need to keep the data hidden from prying eyes, I see no reason that the permissions couldn't be changed to, say, 755 to prevent find from complaining or changing it's ownership. It's possible that fsck might reset it's permissions during a recovery process, but that's a rare event on a modern file system unless there's serious hardware failure. As for just removing it, I believe all of the paranoia around that is based on the fact it's best to have fsck do at little as possible to recover data, but I don't think it really matters much in practice.






    share|improve this answer






















      Your Answer








      StackExchange.ready(function()
      var channelOptions =
      tags: "".split(" "),
      id: "89"
      ;
      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',
      autoActivateHeartbeat: false,
      convertImagesToLinks: true,
      noModals: true,
      showLowRepImageUploadWarning: true,
      reputationToPostImages: 10,
      bindNavPrevention: true,
      postfix: "",
      imageUploader:
      brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
      contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
      allowUrls: true
      ,
      onDemand: true,
      discardSelector: ".discard-answer"
      ,immediatelyShowMarkdownHelp:true
      );



      );













      draft saved

      draft discarded


















      StackExchange.ready(
      function ()
      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1113282%2fis-chown-useruser-lostfound-harmful%23new-answer', 'question_page');

      );

      Post as a guest















      Required, but never shown

























      3 Answers
      3






      active

      oldest

      votes








      3 Answers
      3






      active

      oldest

      votes









      active

      oldest

      votes






      active

      oldest

      votes









      10














      Good advice comes with a rationale so that you can tell when it becomes bad advice.



      The purpose of lost+found being owned by root is so that no matter whose file it was that was lost it's not suddenly exposed to everybody. However, in this case, there shouldn't be a single file in the entire filesystem* not owned by pduck; therefore there is no downside to lost+found not being owned by pduck.



      *barring exotic situations like pduck suing to root and running an X application. But if pduck can use sudo or su than we're talking about nothing because pduck can break system security outright.






      share|improve this answer





























        10














        Good advice comes with a rationale so that you can tell when it becomes bad advice.



        The purpose of lost+found being owned by root is so that no matter whose file it was that was lost it's not suddenly exposed to everybody. However, in this case, there shouldn't be a single file in the entire filesystem* not owned by pduck; therefore there is no downside to lost+found not being owned by pduck.



        *barring exotic situations like pduck suing to root and running an X application. But if pduck can use sudo or su than we're talking about nothing because pduck can break system security outright.






        share|improve this answer



























          10












          10








          10







          Good advice comes with a rationale so that you can tell when it becomes bad advice.



          The purpose of lost+found being owned by root is so that no matter whose file it was that was lost it's not suddenly exposed to everybody. However, in this case, there shouldn't be a single file in the entire filesystem* not owned by pduck; therefore there is no downside to lost+found not being owned by pduck.



          *barring exotic situations like pduck suing to root and running an X application. But if pduck can use sudo or su than we're talking about nothing because pduck can break system security outright.






          share|improve this answer















          Good advice comes with a rationale so that you can tell when it becomes bad advice.



          The purpose of lost+found being owned by root is so that no matter whose file it was that was lost it's not suddenly exposed to everybody. However, in this case, there shouldn't be a single file in the entire filesystem* not owned by pduck; therefore there is no downside to lost+found not being owned by pduck.



          *barring exotic situations like pduck suing to root and running an X application. But if pduck can use sudo or su than we're talking about nothing because pduck can break system security outright.







          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited Jan 28 at 1:40

























          answered Jan 27 at 19:54









          JoshuaJoshua

          49927




          49927























              6














              lost+found is a system directory, and I avoid tampering with the ownership and permissions of system directories and files.



              There are other directories (and files), that make find complain, unless I elevate the permissions of the command line, so I suggest that you use



              sudo find ...


              and leave lost+found as it is/should be.






              share|improve this answer


















              • 2





                Yes, so thought I, but OTOH there is that mklost+found command to create it and it creates it with my ownership. Maybe it's just a horribly written command that doesn't check for $UID!=0 ;-) Also, I don't like the idea of being forced (more or less) to use sudo in my very own $HOME.

                – PerlDuck
                Jan 27 at 14:08












              • lost+found is very old, I think from early UNIX days, and I don't really know when it is used nowadays. But I think it is a good general policy to avoid tampering with the ownership and permissions of system directories and files (unless you really know what can happen behind the scene).

                – sudodus
                Jan 27 at 14:12






              • 5





                Doesn't fsck put files in there when it encounters "lost" files? The idea is that fsck already has a place to put the files into (instead of first creating one). Note that lost+found occupies more space (16384 bytes) than an ordinary empty directory (4096 bytes).

                – PerlDuck
                Jan 27 at 14:16











              • Yes, at least that was the original purpose (similar to what chkdsk did with lost files in MSDOS), but I have seldom if ever seen any data there in linux. Maybe journaling can restore the files to where they were before, so they need not go to lost+found. -- By the way, I have a lost+found directory in /home, but not in my home directory /home/sudodus, so it does not bother me there.

                – sudodus
                Jan 27 at 14:26







              • 1





                I agree. And in /home I have another l+f (doesn't bother me either) because /home and /home/pduck are separate partitions on my machine. The latter is encrypted, the former is not. However, when it annoys me too much, I can mount my $HOME somewhere else and bind-mount it to my actual $HOME (like I outlined here, for example) to completely get rid of l+f in my $HOME. /// I'll delete my comments in a couple of minutes/hours to avoid that "extended discussion … move to chat" alert.

                – PerlDuck
                Jan 27 at 14:37















              6














              lost+found is a system directory, and I avoid tampering with the ownership and permissions of system directories and files.



              There are other directories (and files), that make find complain, unless I elevate the permissions of the command line, so I suggest that you use



              sudo find ...


              and leave lost+found as it is/should be.






              share|improve this answer


















              • 2





                Yes, so thought I, but OTOH there is that mklost+found command to create it and it creates it with my ownership. Maybe it's just a horribly written command that doesn't check for $UID!=0 ;-) Also, I don't like the idea of being forced (more or less) to use sudo in my very own $HOME.

                – PerlDuck
                Jan 27 at 14:08












              • lost+found is very old, I think from early UNIX days, and I don't really know when it is used nowadays. But I think it is a good general policy to avoid tampering with the ownership and permissions of system directories and files (unless you really know what can happen behind the scene).

                – sudodus
                Jan 27 at 14:12






              • 5





                Doesn't fsck put files in there when it encounters "lost" files? The idea is that fsck already has a place to put the files into (instead of first creating one). Note that lost+found occupies more space (16384 bytes) than an ordinary empty directory (4096 bytes).

                – PerlDuck
                Jan 27 at 14:16











              • Yes, at least that was the original purpose (similar to what chkdsk did with lost files in MSDOS), but I have seldom if ever seen any data there in linux. Maybe journaling can restore the files to where they were before, so they need not go to lost+found. -- By the way, I have a lost+found directory in /home, but not in my home directory /home/sudodus, so it does not bother me there.

                – sudodus
                Jan 27 at 14:26







              • 1





                I agree. And in /home I have another l+f (doesn't bother me either) because /home and /home/pduck are separate partitions on my machine. The latter is encrypted, the former is not. However, when it annoys me too much, I can mount my $HOME somewhere else and bind-mount it to my actual $HOME (like I outlined here, for example) to completely get rid of l+f in my $HOME. /// I'll delete my comments in a couple of minutes/hours to avoid that "extended discussion … move to chat" alert.

                – PerlDuck
                Jan 27 at 14:37













              6












              6








              6







              lost+found is a system directory, and I avoid tampering with the ownership and permissions of system directories and files.



              There are other directories (and files), that make find complain, unless I elevate the permissions of the command line, so I suggest that you use



              sudo find ...


              and leave lost+found as it is/should be.






              share|improve this answer













              lost+found is a system directory, and I avoid tampering with the ownership and permissions of system directories and files.



              There are other directories (and files), that make find complain, unless I elevate the permissions of the command line, so I suggest that you use



              sudo find ...


              and leave lost+found as it is/should be.







              share|improve this answer












              share|improve this answer



              share|improve this answer










              answered Jan 27 at 14:05









              sudodussudodus

              24.2k32875




              24.2k32875







              • 2





                Yes, so thought I, but OTOH there is that mklost+found command to create it and it creates it with my ownership. Maybe it's just a horribly written command that doesn't check for $UID!=0 ;-) Also, I don't like the idea of being forced (more or less) to use sudo in my very own $HOME.

                – PerlDuck
                Jan 27 at 14:08












              • lost+found is very old, I think from early UNIX days, and I don't really know when it is used nowadays. But I think it is a good general policy to avoid tampering with the ownership and permissions of system directories and files (unless you really know what can happen behind the scene).

                – sudodus
                Jan 27 at 14:12






              • 5





                Doesn't fsck put files in there when it encounters "lost" files? The idea is that fsck already has a place to put the files into (instead of first creating one). Note that lost+found occupies more space (16384 bytes) than an ordinary empty directory (4096 bytes).

                – PerlDuck
                Jan 27 at 14:16











              • Yes, at least that was the original purpose (similar to what chkdsk did with lost files in MSDOS), but I have seldom if ever seen any data there in linux. Maybe journaling can restore the files to where they were before, so they need not go to lost+found. -- By the way, I have a lost+found directory in /home, but not in my home directory /home/sudodus, so it does not bother me there.

                – sudodus
                Jan 27 at 14:26







              • 1





                I agree. And in /home I have another l+f (doesn't bother me either) because /home and /home/pduck are separate partitions on my machine. The latter is encrypted, the former is not. However, when it annoys me too much, I can mount my $HOME somewhere else and bind-mount it to my actual $HOME (like I outlined here, for example) to completely get rid of l+f in my $HOME. /// I'll delete my comments in a couple of minutes/hours to avoid that "extended discussion … move to chat" alert.

                – PerlDuck
                Jan 27 at 14:37












              • 2





                Yes, so thought I, but OTOH there is that mklost+found command to create it and it creates it with my ownership. Maybe it's just a horribly written command that doesn't check for $UID!=0 ;-) Also, I don't like the idea of being forced (more or less) to use sudo in my very own $HOME.

                – PerlDuck
                Jan 27 at 14:08












              • lost+found is very old, I think from early UNIX days, and I don't really know when it is used nowadays. But I think it is a good general policy to avoid tampering with the ownership and permissions of system directories and files (unless you really know what can happen behind the scene).

                – sudodus
                Jan 27 at 14:12






              • 5





                Doesn't fsck put files in there when it encounters "lost" files? The idea is that fsck already has a place to put the files into (instead of first creating one). Note that lost+found occupies more space (16384 bytes) than an ordinary empty directory (4096 bytes).

                – PerlDuck
                Jan 27 at 14:16











              • Yes, at least that was the original purpose (similar to what chkdsk did with lost files in MSDOS), but I have seldom if ever seen any data there in linux. Maybe journaling can restore the files to where they were before, so they need not go to lost+found. -- By the way, I have a lost+found directory in /home, but not in my home directory /home/sudodus, so it does not bother me there.

                – sudodus
                Jan 27 at 14:26







              • 1





                I agree. And in /home I have another l+f (doesn't bother me either) because /home and /home/pduck are separate partitions on my machine. The latter is encrypted, the former is not. However, when it annoys me too much, I can mount my $HOME somewhere else and bind-mount it to my actual $HOME (like I outlined here, for example) to completely get rid of l+f in my $HOME. /// I'll delete my comments in a couple of minutes/hours to avoid that "extended discussion … move to chat" alert.

                – PerlDuck
                Jan 27 at 14:37







              2




              2





              Yes, so thought I, but OTOH there is that mklost+found command to create it and it creates it with my ownership. Maybe it's just a horribly written command that doesn't check for $UID!=0 ;-) Also, I don't like the idea of being forced (more or less) to use sudo in my very own $HOME.

              – PerlDuck
              Jan 27 at 14:08






              Yes, so thought I, but OTOH there is that mklost+found command to create it and it creates it with my ownership. Maybe it's just a horribly written command that doesn't check for $UID!=0 ;-) Also, I don't like the idea of being forced (more or less) to use sudo in my very own $HOME.

              – PerlDuck
              Jan 27 at 14:08














              lost+found is very old, I think from early UNIX days, and I don't really know when it is used nowadays. But I think it is a good general policy to avoid tampering with the ownership and permissions of system directories and files (unless you really know what can happen behind the scene).

              – sudodus
              Jan 27 at 14:12





              lost+found is very old, I think from early UNIX days, and I don't really know when it is used nowadays. But I think it is a good general policy to avoid tampering with the ownership and permissions of system directories and files (unless you really know what can happen behind the scene).

              – sudodus
              Jan 27 at 14:12




              5




              5





              Doesn't fsck put files in there when it encounters "lost" files? The idea is that fsck already has a place to put the files into (instead of first creating one). Note that lost+found occupies more space (16384 bytes) than an ordinary empty directory (4096 bytes).

              – PerlDuck
              Jan 27 at 14:16





              Doesn't fsck put files in there when it encounters "lost" files? The idea is that fsck already has a place to put the files into (instead of first creating one). Note that lost+found occupies more space (16384 bytes) than an ordinary empty directory (4096 bytes).

              – PerlDuck
              Jan 27 at 14:16













              Yes, at least that was the original purpose (similar to what chkdsk did with lost files in MSDOS), but I have seldom if ever seen any data there in linux. Maybe journaling can restore the files to where they were before, so they need not go to lost+found. -- By the way, I have a lost+found directory in /home, but not in my home directory /home/sudodus, so it does not bother me there.

              – sudodus
              Jan 27 at 14:26






              Yes, at least that was the original purpose (similar to what chkdsk did with lost files in MSDOS), but I have seldom if ever seen any data there in linux. Maybe journaling can restore the files to where they were before, so they need not go to lost+found. -- By the way, I have a lost+found directory in /home, but not in my home directory /home/sudodus, so it does not bother me there.

              – sudodus
              Jan 27 at 14:26





              1




              1





              I agree. And in /home I have another l+f (doesn't bother me either) because /home and /home/pduck are separate partitions on my machine. The latter is encrypted, the former is not. However, when it annoys me too much, I can mount my $HOME somewhere else and bind-mount it to my actual $HOME (like I outlined here, for example) to completely get rid of l+f in my $HOME. /// I'll delete my comments in a couple of minutes/hours to avoid that "extended discussion … move to chat" alert.

              – PerlDuck
              Jan 27 at 14:37





              I agree. And in /home I have another l+f (doesn't bother me either) because /home and /home/pduck are separate partitions on my machine. The latter is encrypted, the former is not. However, when it annoys me too much, I can mount my $HOME somewhere else and bind-mount it to my actual $HOME (like I outlined here, for example) to completely get rid of l+f in my $HOME. /// I'll delete my comments in a couple of minutes/hours to avoid that "extended discussion … move to chat" alert.

              – PerlDuck
              Jan 27 at 14:37











              3














              There is nothing really magical about the lost+found directory. It's just a plain directory just like any other and is only used to hold lost files/directories found during a fsck after a system crash or filesystem corruption. It's created during mkfs when the file system is created and is normally empty. The only reason for the default permissions is to avoid sensitive files from becoming visible to regular users if they are found and recovered during an fsck. In the modern era it's rare to see files get lost and put into that folder. If it's removed, I believe fsck will recreate it as needed if there happens to be any files that need to be put into there. Since this is a file system for one user and his data alone with no need to keep the data hidden from prying eyes, I see no reason that the permissions couldn't be changed to, say, 755 to prevent find from complaining or changing it's ownership. It's possible that fsck might reset it's permissions during a recovery process, but that's a rare event on a modern file system unless there's serious hardware failure. As for just removing it, I believe all of the paranoia around that is based on the fact it's best to have fsck do at little as possible to recover data, but I don't think it really matters much in practice.






              share|improve this answer



























                3














                There is nothing really magical about the lost+found directory. It's just a plain directory just like any other and is only used to hold lost files/directories found during a fsck after a system crash or filesystem corruption. It's created during mkfs when the file system is created and is normally empty. The only reason for the default permissions is to avoid sensitive files from becoming visible to regular users if they are found and recovered during an fsck. In the modern era it's rare to see files get lost and put into that folder. If it's removed, I believe fsck will recreate it as needed if there happens to be any files that need to be put into there. Since this is a file system for one user and his data alone with no need to keep the data hidden from prying eyes, I see no reason that the permissions couldn't be changed to, say, 755 to prevent find from complaining or changing it's ownership. It's possible that fsck might reset it's permissions during a recovery process, but that's a rare event on a modern file system unless there's serious hardware failure. As for just removing it, I believe all of the paranoia around that is based on the fact it's best to have fsck do at little as possible to recover data, but I don't think it really matters much in practice.






                share|improve this answer

























                  3












                  3








                  3







                  There is nothing really magical about the lost+found directory. It's just a plain directory just like any other and is only used to hold lost files/directories found during a fsck after a system crash or filesystem corruption. It's created during mkfs when the file system is created and is normally empty. The only reason for the default permissions is to avoid sensitive files from becoming visible to regular users if they are found and recovered during an fsck. In the modern era it's rare to see files get lost and put into that folder. If it's removed, I believe fsck will recreate it as needed if there happens to be any files that need to be put into there. Since this is a file system for one user and his data alone with no need to keep the data hidden from prying eyes, I see no reason that the permissions couldn't be changed to, say, 755 to prevent find from complaining or changing it's ownership. It's possible that fsck might reset it's permissions during a recovery process, but that's a rare event on a modern file system unless there's serious hardware failure. As for just removing it, I believe all of the paranoia around that is based on the fact it's best to have fsck do at little as possible to recover data, but I don't think it really matters much in practice.






                  share|improve this answer













                  There is nothing really magical about the lost+found directory. It's just a plain directory just like any other and is only used to hold lost files/directories found during a fsck after a system crash or filesystem corruption. It's created during mkfs when the file system is created and is normally empty. The only reason for the default permissions is to avoid sensitive files from becoming visible to regular users if they are found and recovered during an fsck. In the modern era it's rare to see files get lost and put into that folder. If it's removed, I believe fsck will recreate it as needed if there happens to be any files that need to be put into there. Since this is a file system for one user and his data alone with no need to keep the data hidden from prying eyes, I see no reason that the permissions couldn't be changed to, say, 755 to prevent find from complaining or changing it's ownership. It's possible that fsck might reset it's permissions during a recovery process, but that's a rare event on a modern file system unless there's serious hardware failure. As for just removing it, I believe all of the paranoia around that is based on the fact it's best to have fsck do at little as possible to recover data, but I don't think it really matters much in practice.







                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered Jan 28 at 7:54









                  penguin359penguin359

                  34624




                  34624



























                      draft saved

                      draft discarded
















































                      Thanks for contributing an answer to Ask Ubuntu!


                      • Please be sure to answer the question. Provide details and share your research!

                      But avoid


                      • Asking for help, clarification, or responding to other answers.

                      • Making statements based on opinion; back them up with references or personal experience.

                      To learn more, see our tips on writing great answers.




                      draft saved


                      draft discarded














                      StackExchange.ready(
                      function ()
                      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1113282%2fis-chown-useruser-lostfound-harmful%23new-answer', 'question_page');

                      );

                      Post as a guest















                      Required, but never shown





















































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown

































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown






                      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?