Comment 4 for bug 911507

The reason I would still suggest mounting read-only on any error is to prevent silent data loss (e.g. some problems in eCryptfs were found because people put their git repositories on eCryptfs and git detected error in the fs/storage. I'd hate to have silent data loss by design only because end user may end up failing to login with corrupted file system). I'd be somewhat okay with non-default mount option that fixes the issue by e.g. removing any files that are not encrypted or just empty ones.

Note that ecryptfs always has a bug when there's an invalid file in the lower filesystem (or the user has manually messed with the lower filesystem and it that case he should expect mounting to fail). If the eCryptfs is still too unstable to default to mounting read-only on any error, then it really should not used as user home mount. If the only issue is caused by previous (buggy) versions of ecryptfs leaving random corrupted files in the lower filesystem, then system (Ubuntu) should run one-time script to fix those issues (namely, removing empty files in lower filesystem) before trying to mount the user's home with eCryptfs.