Ask Ubuntu is a question and answer site for Ubuntu users and developers. 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

Recently, when I've been starting my computer I'm informed that it is recovering the journal for one of my ext3 partitions.

One might expect this behaviour if the computer shutdown improperly, but, as far as I can tell this is occurring after normal shutdowns.

Additionally, the number of inodes which are found to be orphaned and cleared is only one or two in these cases.

I have performed an fsck, but the situation continues.

Which logs files can I check to try to find out why this is happening? What are some reasons it may have happened? How can I resolve it?


fstab is as follows:

# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sda5 during installation
UUID=ead12a48-4a3b-4e3a-b611-d3fc62e8716a /               ext4    errors=remount-ro,noatime,nodiratime 0       1
# /home was on /dev/sda6 during installation
UUID=217f1c44-5d04-4c75-9d4a-2a70b1726434 /home           ext3    defaults,noatime,nodiratime        0       2


cat /var/log/fsck/{checkfs,checkroot} returns (Nothing has been logged yet.) twice.

share|improve this question
@Rinzwind, filesystem state: clean. – Richard Jan 28 '13 at 11:17
I am out of suggestions @richard :) Here have a bounty on your question >:) – Rinzwind Jan 28 '13 at 11:23
@Rinzwind, let me check the filesystem state another time or two just to be sure that the shutdown was symptomatic. – Richard Jan 28 '13 at 11:27
Do the files /var/log/fsck/{checkfs,checkroot} something? What is your system date and what time shows your BIOS? – qbi Jan 28 '13 at 20:16
@qbi, those files both show (Nothing has been logged yet.) I'll check the BIOS time shortly. – Richard Jan 28 '13 at 20:37

Your only ext3 partition happens to be /home. One possible reason for your problem is that /home isn't being unmounted because it is in use at the time your system is being shut down. Since /home shouldn't be in use when no normal user is logged in, identifying if it is in use when nobody is logged in is one way of identifying if this particular possible issue is the cause of your specific problem.

  1. Temporarily enable root login on your system (we'll disable it again later). This will allow you to log in without accessing /home, so that you can check whether anything else is using it and whether it unmounts correctly.

  2. Log out.

  3. Press Ctrl+Alt+F1 to switch to a text virtual terminal.

  4. Log in as root. This will start a shell in root's home directory (/root) which is outside of /home.

  5. Try to unmount /home by typing umount /home (no sudo is required since you're already root).

  6. If this succeeds, then this isn't your problem. If it fails, then this is your problem. If the reason is that the filesystem is in use, then the command fuser -m /home will list processes using /home which you can investigate.

  7. Mount /home again by typing mount /home.

  8. Log out with the command exit.

  9. Switch back to the graphical login screen by pressing Alt+F7.

  10. Log back in as yourself.

  11. Disable root login to return your system to its original configuration.

This may or may not identify the cause of your specific problem, but should work to identify processes that are preventing /home from being cleanly unmounted on system shutdown in the general case.

share|improve this answer
I gave this a try and, indeed, it would not unmount. Using fuser -vm /home showed that there was single process with PID kernel accessing the file-system. I'm not sure where to go from here. Is it possible to see what file is being accessed? I have an inkling that it may be related to the home directory being encrypted (ecryptfs). – Richard Jan 28 '13 at 23:02
Could you paste the output of fuser into your question? – qbi Jan 29 '13 at 18:57

As you mentioned in your comment eCryptfs is a possible cause for your problem. To check this out do the following steps:

  1. Log out and log in as a different user
  2. Try to open your files in /home/richard (or however your user is called).
  3. If you can access and read the files, your home was not correct unmounted.

Another thing you can do as user is to enter ecryptfs-umount-private. This scripts quits on success with the message:

Your private directory has been unmounted.

On error you might get the message:

fopen: No such file or directory
Cannot chdir into mountpoint.

In the latter case the problem are often missing symlinks. So do the following steps:

  1. Login as your normal user
  2. Make sure your home directory is not encrypted (You can read all files).
  3. Open a terminal (If you are working in a terminal, just type cd to get into your $HOME).
  4. Type ln -s /home/.ecryptfs/YOUR_USERNAME/.ecryptfs and ln -s /home/.ecryptfs/YOUR_USERNAME/.Private.

The main point are the symbolic links in the last step. In some cases they are missing. This leads to not encrypting and umounting your data in the home.

However if the problem persists then there might also the file $HOME/.ecryptfs/auto-umount missing. If this is the case your home directory will not be automatically unmounted. Just enter touch $HOME/.ecryptfs/auto-umount to change it.

share|improve this answer
I tried this and could not access the files, so I guess the logout went correctly. Is there any log file for checking to see if this happens consistently? – Richard Jan 29 '13 at 11:16

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.