I'm running the following in a Konsole on an ext3 formatted crypt file:

linux:/ # umount -d -l /loopback/crypto
linux:/ # e2fsck /loopback/crypto
e2fsck 1.38 (30-Jun-2005)
Couldn't find ext2 superblock, trying backup blocks...
e2fsck: Bad magic number in super-block while trying to open /loopback/crypto

The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>

linux:/ # e2fsck -b 8193 /loopback/crypto
e2fsck 1.38 (30-Jun-2005)
e2fsck: Attempt to read block from filesystem resulted in short read while trying to open /loopback/crypto
Could this be a zero-length partition?
linux:/ # e2fsck -b 32768 /loopback/crypto
e2fsck 1.38 (30-Jun-2005)
e2fsck: Attempt to read block from filesystem resulted in short read while trying to open /loopback/crypto
Could this be a zero-length partition?
linux:/ #

I don't know how to tweak the command so it checks the crypt file. Using the man pages is like an ingredients cabinet without a recipe book. The back pages of my Suse 10.0 manual says that e2fsck can check ext3. There must be a simple answer, but I'm in the bozone.

I'm probably not going to be of much help but the post seems old enough I won't be infringing on your 0 reply status...

Did you try running badblocks?

I'd been having troubles like yours since the summer. All was well if I didn't re-boot.

Up and running since September but I knew one power failure would get me!

This may help you:
http://www.linuxdocs.org/HOWTOs/LILO...e-HOWTO-1.html

I broke down and bought a new hard-drive yesterday...
<sigh>

Good luck!

The man pages for badblocks warn me not to use it directly, but instead use e2fsck with the -c option, which I did try. I still got nowhere with it.
There is also a section in the man pages for e2fsck stating that I must "apply the journal" to an ext3 file system, before running e2fsck. I'm even more in the bozone about how to apply the journal. There's a -j option for giving e2fsck a path to an external journal, but I don't suppose doing that is barking up the right tree, either.

This just isn't user friendly stuff! O.K., I admit that I now understand that e2fsck applies the journal to the ext3 system (misinterpreted reading on my part). The use of e2fsck still fails, with the same errors as in my first post (the alternate block sizes I try make no difference), when being used on an ext3 formatted crypt file.
I got fed up and removed the crypt file with partitioner. I made a new crypt file formatted with reiserfs. Now, I am having a similar problem with reiserfsck. When I try to reiserfsck the crypt file, the operation aborts. There's some fundamental thing about checking crypt file systems that remains beyond me.

I would assume that, if every part of the filesystem is encrypted including the inodes and so-forth, the check program simply can't make heads-nor-tails of it. Can't decrypt it, you know. (Which, with encryption, is of course exactly what you want!)

I guess I'm just supposed to be happy with being able to run reiserfsck on the regular reiserfs partition on my disk (which I can, no problem). Not being able to check a formatted file system, even though it is contained in a cryptographic file, leaves me with a sense of insecurity. It doesn't make sense to me that there is no way to check the file system in a crypt file. It's probably true though, so I'm stuck (someone argue, please!). As discontented as I am about crypt files, I shudder more about users with their systems on crypt partitions (do those people still have no method available to check for filesystem corruption?).