11

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?

2
  • Not all file systems have a lost+found directory. Ext4 does, XFS doesn’t, for example.
    – jornane
    Commented Jan 27, 2019 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
    Commented Jan 31, 2019 at 12:55

3 Answers 3

Reset to default
14

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.

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}.

6
  • 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
    Commented Jan 27, 2019 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
    Commented Jan 27, 2019 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
    Commented Jan 27, 2019 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
    Commented Jan 27, 2019 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
    Commented Jan 27, 2019 at 14:37
4

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.

1
  • 1
    Historically, fsck could not create it. Something about being unable to allocate blocks that early because the free list hasn't been checked yet.
    – Joshua
    Commented Oct 26, 2020 at 16:51

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .