When you create some Linux filesystems like ext3 a 'lost+found' directory is created. According to this files will be placed there if files were damaged from some kind of system crash.

What happens if this directory is removed, and the system crashes. If the folder is removed can I just create a new directory with mkdir lost+found or are there attributes that can only be set when the filesystem is being created.

7 Answers 7


fsck will recreate the lost+found directory if it is missing.

On startup most distributions run fsck if the filesystem is detected as not being unmounted cleanly. As fsck creates the lost+found directory if it is missing, it will create it then and place anything that it finds into that directory.


If you can't or don't want to run fsck, you can recreate the lost+found directories with mklost+found:

mklost+found pre-allocates disk blocks to the lost+found directory so that when e2fsck(8) is being run to recover a filesystem, it does not need to allocate blocks in the filesystem to store a large number of unlinked files. This ensures that e2fsck will not have to allocate data blocks in the filesystem during recovery.

  • 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 <root-dir-of-the-mount> && mklost+found did it. Commented Nov 18, 2014 at 19:11
  • A side effect of keeping lost+found is that if you see lost+found, you know that your drive is mounted at least. Because sometimes you can have an empty mount point, if you delete lost+found, you can't quickly tell if the mount point is not mounted at all or if it's mounted but just empty.
    – Wadih M.
    Commented May 4, 2023 at 20:54

A pre-existing lost+found directory with a large enough size to contain a large number of unlinked files puts less of a burden on e2fsck to create the directory and grow it to the appropriate size.

It will still attempt to do so, but in the face of a corrupt filesystem, it can be more risky.

Very old fsck's for other filesystems on other platforms were not able to create /lost+found, nor were they able to grow it. This is the history for the rationale of /lost+found. But the current rationale is simply to make e2fsck's job easier.

  • 4
    It isn't that they couldn't create the lost+found -- it is that it is a bad idea to create files / directories on a filesystem that's already screwed up. Instead, you just prebuild a directory that's already big enough to store the directory entries of whatever munched inodes you find in a screwed-up filesystem when you're trying to clean it up.
    – chris
    Commented Jul 23, 2013 at 2:56

If you have no lost+found, e2fsck (I have not inspected the code to other fsck implementations) will offer to create it for you. But, you can recreate it yourself if you want, too; there's nothing particularly special about that directory (at least not from inspecting the code).

  • 2
    fsck should recreate lost+found if needed, no? Commented May 10, 2009 at 7:07
  • 2
    Thanks, I've checked the code for e2fsck and indeed it does offer to recreate it for you. (This is not guaranteed to succeed though---which is why a pre-created lost+found is useful too.) Neat! Commented May 10, 2009 at 14:54
  • 7
    @ChrisJester-Young - Your answer is incorrect. lost+found is a special directory. It has pre-allocated disk blocks so that recovery tools don't need to allocate blocks during recovery. Tools like mklost+found exist specifically because mkdir won't create it properly. See linux.die.net/man/8/mklost+found Commented Oct 3, 2013 at 7:25

e2fsck will recreate lost+found, and will also destroy any file that might be in the way with the same name to make sure it can create it as a directory.

Note that many older Unix filesystems demanded that lost+found be attached to inode number 2 specifically, hence a need to recreate the filesystem in most cases if the directory got lost. e2fsck simply does a search for any free inode, apparently not specifically needing inode 2, which makes recovery much simpler than the old days.


You can create that directory just using mkdir. It should be owned by root, with a group of either root or wheel. Other than that there isn't anything especially special about it. In the event of a power failure or improper shutdown when the system boots it should automatically launch fsck. fsck will go through the system and try to recover any corrupt files that it finds. Any files that it comes across that are potentially corrupted will get moved there.

The other case for files to be moved there is if fsck finds a file whose's parent inode is missing. This is usually the case if a block gets corrupted on the disk in the specific location where a folder's inode is being stored. It will reassign their parent inode to be the lost+found folder.

Edit: I am unsure if the latter case will recreate the directory. I would leave it alone to be on the safe side. I can't think of any reason to delete it. Nothing bad will happen without it though.

  • 1
    Are you sure it is ok just to create with mkdir?
    – user83664
    Commented Feb 5, 2013 at 0:50
  • Yes it is, the space allocation is not tied to the directories inode or even the path. The reserved space allocation is more a less a flag on some memory that requires root/kernel privileges and special calls to access which fsck is aware of, it just makes use of that space by copying potentially corrupt or broken files into that memory and creating a file with an inode pointing at the new memory. File operations will behave normally on those files but any changes such as moving or saving will pull the data out of the reserved memory. Commented Apr 12, 2013 at 15:05

In addition, on Debian 6 and Ubuntu 12 LTS, the cron package shipped /etc/cron.daily/standard which notices missing lost+found directories on local filesystems and sends daily reminders about it via e-mail, recommending the use of mklost+found.

However, this was removed by the time of Debian 7 and Ubuntu 14 LTS, respectively, because it had become obsolete.

You must log in to answer this question.

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