Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I tried to mount a formerly readonly mounted filesystem read-writeable:

mount -o remount,rw /mountpoint

Unfortunately it did not work:

mount: /mountpoint not mounted already, or bad option

dmesg reports:

[2570543.520449] EXT4-fs (dm-0): Couldn't remount RDWR because of unprocessed orphan inode list.  Please umount/remount instead

A umount does not work, too:

umount /mountpoint
umount: /mountpoint: device is busy.
    (In some cases useful info about processes that use
     the device is found by lsof(8) or fuser(1))

Unfortunately neither lsof of fuser don't show any process accessing something located under the mount point.

So - how can I clean up this unprocessed orphan list to be able to mount the filesystem again without rebooting the computer?

share|improve this question
Have you tried fuser -km /mountpoint yet? Beware though, the -k flag will kill all processes accessing that directory. – Richard Keller May 31 '12 at 0:32
Can you provide a little bit more insight to what dm-0 consists of? – thinice May 31 '12 at 1:28
I have feeling I know whats up, but can you tell me, was the filesystem originally rw, remounted (due to ata error or whatever) ro, and now you are trying to rw again? – Matthew Ife Jul 1 '12 at 22:47
@Mlfe: The filesystem was formerly remountend ro by purpose. It's a filesystem on an LVM holding a daily backup snapshot that will be set to rw during backup operation and ro after finishing the backup. – bmk Jul 9 '12 at 7:39
up vote 4 down vote accepted

You clean up the unprocessed orphan inode list by unmounting and remounting the filesystem.

An extended discussion from the linux-ext4 mailing list has more information about what this message is and why it may appear. In short, one of two things has happened: Either you've run into a kernel bug, or much more likely, some filesystem corruption happened one of the previous times you remounted the filesystem readonly. Which is probably why the system thinks something is still using the filesystem when there isn't.

If it's been a year and you still haven't rebooted the machine, just give up and schedule a maintenance window.

share|improve this answer
Meanwhile I scheduled a maintenance window and rebooted the machine. That solved the problem (I didn't expect anything else...). I will accept your answer. Probably you are right that there was some filesystem corruption - although I cannot prove that. – bmk Aug 28 '12 at 16:38

If you're using ext2 / ext3 / ext4 you should be able to use e2fsck to clean up orphaned inodes:

e2fsck -f

For reiserfs, you can use reiserfsck which will also clean up orphaned inodes.

share|improve this answer
Not sure why this was downvoted, perhaps provide a reason for the downvote? Running e2fsck does clean up orphaned inodes, which you'll see in the console output as clearing orphaned inode XXXX where XXXX is an inode number. You can easily run e2fsck without rebooting the system. After running e2fsck you should be able to remount the partition. – Richard Keller Jul 30 '12 at 22:49
Thanks thanks a lot.. I spend hours figuring out the error. Doing 'e2fsck -f /dev/sda1' fixed the orphaned nodes for me along with some other fixes. I just said yes to all and works fine now :) – whitehat Jul 11 at 15:26

You should probably try a lazy unmount, i.e:

umount -l
share|improve this answer

I would recommend to first unmount the partition forcefully, i.e. using the -f option, and the running a file system check using fsck.

share|improve this answer
Unfortunately umount -f didn't succeed, too. The error message is the same as with a plain umount. – bmk Jun 8 '11 at 11:55

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.