752

There is a folder at the root of Linux and Unix operating systems called /lost+found/

What is it for? Under what circumstances would I interact with it? How would I interact with it?

Gilles 'SO- stop being evil'
  • 766,554
  • 187
  • 1,586
  • 2,083
Wesley
  • 13,563
  • 12
  • 34
  • 49
  • 2
    Note that only ext2 (and ext3 and ext4) use `lost+found`. If you want to hide it, either use a different filesystem or mount it elsewhere, keep everything in a subdirectory, and symlink the subdirectory to the "real" place you use the data from. – Adam Katz Feb 26 '15 at 19:17
  • 4
    @Gilles someone was kind enough to add it: https://en.wikipedia.org/wiki/Fsck#Use – Big McLargeHuge Feb 12 '16 at 18:17
  • 1
    Note that `lost+found` is specific to the Linux extended file system (ext2–4). Unices, e.g. FreeBSD typically don't have this directory on their file systems (UFS, ZFS). – FUZxxl Jan 20 '17 at 12:01
  • 10
    Sorry, but `lost+found` has been around practically forever on BSD systems. In fact, I just checked and it was definitely there on 4.3BSD, and I seem to recall it a lot earlier. And it is certainly on FreeBSD today. – Bob Eager Jul 11 '17 at 23:34

3 Answers3

663

If you run fsck, the filesystem check and repair command, it might find data fragments that are not referenced anywhere in the filesystem. In particular, fsck might find data that looks like a complete file but doesn't have a name on the system — an inode with no corresponding file name. This data is still using up space, but it isn't accessible by any normal means.

If you tell fsck to repair the filesystem, it will turn these almost-deleted files back into files. The thing is, the file had a name and location once, but that information is no longer available. So fsck deposits the file in a specific directory, called lost+found (after lost and found property).

Files that appear in lost+found are typically files that were already unlinked (i.e. their name had been erased) but still opened by some process (so the data wasn't erased yet) when the system halted suddenly (kernel panic or power failure). If that's all that happened, these files were slated for deletion anyway, you don't need to care about them.

Files can also appear in lost+found because the filesystem was in an inconsistent state due to a software or hardware bug. If that's the case, it's a way for you to find files that were lost but that the system repair managed to salvage. The files may or may not contain useful data, and even if they do they may be incomplete or out of date; it all depends how bad the filesystem damage was.

On many filesystems, the lost+found directory is a bit special because it preallocates a bit of space for fsck to deposit files there. (The space isn't for the file data, which fsck leaves in place; it's for the directory entries which fsck has to make up.) If you accidentally delete lost+found, don't re-create it with mkdir, use mklost+found if available.

Cristian Ciupitu
  • 2,375
  • 1
  • 20
  • 26
Gilles 'SO- stop being evil'
  • 766,554
  • 187
  • 1,586
  • 2,083
  • 21
    Also, if accidentally deleted fsck may re-create it the next time it finds the filesystem clean (which will probably be the next boot). – derobert Aug 06 '11 at 05:05
  • 37
    Is this folder something that should be checked and cleaned from time to time? – TheLQ Aug 07 '11 at 08:24
  • 13
    @TheLQ Only if your filesystem has suffered extensive corruption, `fsck` was required, and it mentioned finding files and linking them in `lost+found`. In 20 years with various filesystems, I've only seen this once. And that was before journalling was the norm. – Alexios Jan 12 '12 at 08:06
  • 7
    I think it also appears if you format your HDD (I switched from NTFS to ext4 and it appeared) – puk Nov 20 '13 at 08:43
  • 9
    @puk The `lost+found` directory is created whenever you create an ext4 filesystem (as with many other filesystems), whether it's done as part of the system installation or not. “Format your HDD” is just one case of that. What `fsck` does is to possibly add files there. – Gilles 'SO- stop being evil' Nov 20 '13 at 10:17
  • 1
    `fdisk (util-linux 2.20.1)` does this when creating an `ext2` system too – erch Feb 05 '14 at 20:56
  • 1
    At RHEL 6.4 nor `fsck` neither `e2fsck` where re-creating this for me, no matter if the directory was mounted or not. `cd && mklost+found` did it. – Luis Antolín Cano Nov 18 '14 at 19:10
  • If you run `fsck` when there is no `lost+found` directory, it'll ask your permission to create it. – budhajeewa Aug 28 '15 at 15:04
  • I am wondering how does `fsck` writes in `lost+found` directory since `fsck` is ran when the filesystem is on Read Only Mode. – Balman Rawat Jan 27 '17 at 02:48
  • 2
    @BalmanRawat fsck does not go through the filesystem driver at all. It accesses the disk directly. The filesystem does not need to be mounted. If it's mounted, it's mounted read-only with most filesystem types because it would be very hard to make fsck work if the filesystem got modified by the driver at the same time. In fact, it would be easier to make a filesystem driver that doesn't work at the same time as fsck, but many filesystem tools support read-only mounting so that fsck can act on the partition where the fsck binary itself is located – Gilles 'SO- stop being evil' Jan 27 '17 at 09:34
  • 1
    I've now come across several empty files in this directory. How could they be gathered by fsck? There should have been any unreferenced occupied blocks if the restored files are empty. – Ruslan Jan 26 '20 at 08:31
  • Great answer, but related question: is `lost+found` always created at the root of a file system? – Daniel Griscom Sep 16 '22 at 15:03
  • @DanielGriscom At least in the case of ext2/ext3/ext4, `lost+found` has to be called by that name and to be at the root of the filesystem. I don't know if that's the case for all filesystems. – Gilles 'SO- stop being evil' Sep 16 '22 at 15:36
72

The lost+found directory (not Lost+Found) is a construct used by fsck when there is damage to the filesystem (not to the hardware device, but to the fs). Files that would normally be lost because of directory corruption would be linked in that filesystem's lost+found directory by inode number. Some of these might be lost directories or lost files or even lost devices. Each filesystem should have its own lost+found directory, but you might be looking at a system with only one filesystem. In general, you should hope that the directory is empty; but if there is corruption, be thankful that in many conditions files can be recovered after fsck places them here.

erch
  • 4,640
  • 15
  • 46
  • 79
Arcege
  • 21,779
  • 5
  • 55
  • 63
  • 6
    Valid point, however: these CAN become quite a nuisance anyway. For example, when trying to to a `find` operation on one or many `ext[2|3|4]` partition(s) from a non-admin user's account, you will always get these entirely unnecessary _"permission denied"_ errors. Certainly, there are ways to circumvent those kinds of errors - but it's a bit awkward because the standard `find . -name '*whatever*'` won't do the trick. – syntaxerror Sep 29 '12 at 19:54
  • 2
    @syntaxerror: Good to hear you say that about the annoyances of _find: `./lost+found': Permission denied_. It bugs me from time to time too... – Johan E Jun 22 '14 at 00:24
  • 2
    @syntaxerror the reason I arrived at this question was precisely because I was doing a find operation and find kept generating a `Permission denied` warning. Given this question's answer, I know that `lost+found` is part of the filesystem and so I can safely ignore the generated warning (but I do wish it didn't produce the warning). – Trevor Boyd Smith Dec 16 '15 at 18:58
  • 2
    @JohanE You're telling me. However, the actual reason why *I* posted my comment was because this answer was trying to suggest us to *"be thankful"* for `lost+found`. This felt way too hilarious to be true (I sat here with a broad grin), for the ridiculously few times *when* we're thankful for it can't compete with those when we'd rather be able to cast a *"Begone!"* spell to this nuisant lo+fo thing. – syntaxerror Dec 16 '15 at 19:49
41

From "Linux Filesystem Hierarchy", section /lost+found":

As was explained earlier during the overview of the FSSTND, Linux should always go through a proper shutdown. Sometimes your system might crash or a power failure might take the machine down. Either way, at the next boot, a lengthy filesystem check using fsck will be done. Fsck will go through the system and try to recover any corrupt files that it finds. The result of this recovery operation will be placed in this directory. The files recovered are not likely to be complete or make much sense but there always is a chance that something worthwhile is recovered. Each partition has its own lost+found directory. If you find files in there, try to move them back to their original location. If you find something like a broken symbolic link to 'file', you have to reinstall the file/s from the corresponding RPM, since your file system got damaged so badly that the files were mutilated beyond recognition. Below is an example of a /lost+found directory. As you can see, the vast majority of files contained here are in actual fact sockets. As for the rest of the other files they were found to be damaged system files and personal files. These files were not able to be recovered.

Cristian Ciupitu
  • 2,375
  • 1
  • 20
  • 26
bhupal
  • 411
  • 4
  • 2