fsck: Couldn’t fix parent of inode : Couldn’t find parent directory entry

By: | Post date: June 2, 2009 | Comments: 281 Comments

Posted in categories: Computer Tips, Work related

In linux file system, when file system error happens, the first choice is to do an fsck of the unmounted file system.

Usually,

fsck -y /dev/sdxx

at boot time should be able to fix everything, if the FS has not been severely damaged.

Occasionally, as reported as

Debian bug list #478546 at

http://groups.google.com/group/linux.debian.bugs.dist/browse_thread/thread/dc48335d2ca42b66

fsck returns error like:

fsck 1.40.8 (13-Mar-2008)
e2fsck 1.40.8 (13-Mar-2008)
Backup contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
'..' in /lost+found/#122068977 (122068977) is <The NULL inode> (0),
should be /lost+found (11).
Fix? yes

Couldn't fix parent of inode 122068977: Couldn't find parent directory entry

Pass 4: Checking reference counts
Pass 5: Checking group summary information

Backup: ********** WARNING: Filesystem still has errors **********

Backup: 14398872/122077184 files (1.4% non-contiguous),
188901088/244137600 blocks

And, what ever you repeat fsck, or use e2fsprogs won’t help about this.

Here I explain the cause of this and prresent a solution as following:

[REASON]

In the messed up FS, an orphaned inode with ZERO data length was labelled as a directory, and was restored into lost+found/ on the alleged file system.

However, for a valid directory entry, it cannot be ZERO length.  It has to have at least two entries namely ‘.’ linking to itself and ‘..’ linking to its parent directory.  However, since this directory entry has zero length, fsck failed creating ‘..’ thus resulted the error

“Couldn't fix parent of inode 122068977: Couldn't find parent directory entry"

and resulted a fail of the fsck.

[SOLUTION]

When fsck is done, mount the FS.  Then cd the lost+found/ directory:

mount #<your mount point>
cd #<your mount point>
cd lost+found

If you do ‘ls -al’, you will see a directory with zero length named #<the affected inode>, like here #122068977.

It usually has a weird owner and group number.

You then do the following:

chown root:root #<the affected inode>
chmod 755 #<the affected inode>

This will make it look normal.

Then

cd #<the affected inode>
touch test
rm test
cd #<your mount point>

Note you cannot do

cd ..

still here since ‘..’ does not exist yet.

Then if you do
ls -al

again, the length of the directory #<the affected inode> is no longer 0, but the default minimum length of your file system, say 4096, 8192, or 16384, etc.

At this point, you can cd off the mounted filesystem, and umount it:

cd ~
umount #<your mount point>

and fsck it:
fsck -y /dev/<your device>

It then will result:

fsck 1.40.2 (12-Jul-2007)
e2fsck 1.40.2 (12-Jul-2007)
<your FS> was not cleanly unmounted, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Missing '.' in directory inode <bad inode number>.
Fix? yes

Setting filetype for entry '.' in ... (<bad inode number>) to 2.
Missing '..' in directory inode <bad inode number>.
Fix? yes

Setting filetype for entry '..' in ... (<bad inode number>) to 2.
Pass 3: Checking directory connectivity
'..' in /lost+found/<bad inode number> (<bad inode number>) is
(0), should be /lost+found (11).
Fix? yes

Pass 4: Checking reference counts
Inode 2 ref count is 6, should be 7. Fix? yes

Inode 11 ref count is 4, should be 3. Fix? yes

Inode <bad inode number> ref count is 1, should be 2. Fix? yes

Pass 5: Checking group summary information

<your FS>: ***** FILE SYSTEM WAS MODIFIED *****
<your FS>: 1882918/91193344 files (0.3% non-contiguous), 111803861/182339584 blocks

This will save you from the risk of running a FS with errors or fully copy the file system elsewhere to recreate it.

281 Comments

Leave a Reply