Community Packages

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#27651 - [ecryptfs] gives "Error mounting eCryptfs" since filesystem upgrade

Attached to Project: Community Packages
Opened by Derek Sivers (sivers) - Wednesday, 21 December 2011, 04:32 GMT
Last edited by Timothy Redaelli (tredaelli) - Tuesday, 29 May 2012, 11:00 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Timothy Redaelli (tredaelli)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 5
Private No


Since filesystem-2011.12 update, all ecryptfs mounting says:
"Error mounting eCryptfs: [-5] Input/output error"

The entry in /var/log/everything.log says:
mount.ecryptfs: Failed to write to the mount table

Though /etc/mtab aka /proc/self/mounts shows the mounted entry correctly:
/home/me/.Private /home/me/Private ecryptfs rw,relatime,ecryptfs_fnek_sig=blah,ecryptfs_sig=blah,ecryptfs_cipher=blowfish,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs 0 0

... and it seems to be working correctly. But still the Input/output error is alarming and should be addressed.

Additional info:
* filesystem-2011.12
* community/ecryptfs-utils 95-1

Steps to reproduce:
To make sure it wasn't just some quirk I had done in the past, I uninstalled everything and followed the Wiki entry exactly:

At the end of the mount -t ecryptfs process, it gave the same "Error mounting eCryptfs: [-5] Input/output error".
This task depends upon

Closed by  Timothy Redaelli (tredaelli)
Tuesday, 29 May 2012, 11:00 GMT
Reason for closing:  Fixed
Comment by Timothy Redaelli (tredaelli) - Wednesday, 21 December 2011, 11:07 GMT
thanks for you report.

Did you load the module before try to mount? (modprobe ecryptfs)
Can you try to use ecryptfs-mount-private (from user)?
Comment by Derek Sivers (sivers) - Wednesday, 21 December 2011, 15:28 GMT
Thanks for the reply.

I tried `modprobe ecryptfs` before the mount command and it made no difference: the mount command still had the same error.

I tried ecryptfs-mount-private now, and it still gave the same error.

I've been using ecryptfs without error for a year now (on Arch Linux). Nothing else changed. The day the new filesystem-2011.12 pacman port upgraded is the day this error started.

The ecryptfs-utils port moved from AUR to Community the next day, but I upgraded them separately, and it was the filesystem upgrade that made the error start. Upgrading the ecryptfs-utils port to the new Community/95-1 version didn't help.
Comment by Timothy Redaelli (tredaelli) - Thursday, 22 December 2011, 12:26 GMT
To be sure that the problem is the new symlink you should try to do:

# rm /etc/mtab
# cat /proc/self/mounts > /etc/mtab
# modprobe ecryptfs

Then from user try to mount the private directory and check the error, then you need to reinstall filesystem (important):

# pacman -Sf filesystem
Comment by Jingcheng Liu (liuexp) - Thursday, 22 December 2011, 14:25 GMT
I just encountered exactly the same problem the first time I run sudo mount -t ecryptfs.
it says
Successfully appended new sig to user sig cache file
Error mounting eCryptfs: [-5] Input/output error

and the everything.log:
Dec 22 21:58:36 localhost mount.ecryptfs: Failed to write to the mount table

but when I run exactly the same command again, it says
Error mounting eCryptfs: [-22] Invalid argument

And this time in my everything.log there're these lines:
Dec 22 22:04:41 localhost kernel: [32443.935208] Mount on filesystem of type eCryptfs explicitly disallowed due to known incompatibilities
Dec 22 22:04:41 localhost mount.ecryptfs: Failed to perform eCryptfs mount: [Invalid argument]
Dec 22 22:04:41 localhost kernel: [32443.954245] Reading sb failed; rc = [-22]

So it seems that there's some problem with the kernel?
Comment by Adrian C. (anrxc) - Friday, 23 December 2011, 00:22 GMT
I have two laptops with whole home directory encrypted. I don't know
what I'm doing different but I can't reproduce this with new
'filesystem' package.

I load ecryptfs early, in rc.conf. I have my mount defined in /etc/fstab, and
I call mount at login time.

I run the following packages:
ecryptfs-utils 95
keyutils 1.5.5
linux 3.1.5

Edit: actually I am doing one thing different. It's a long shot, but due dilligence.
I build my own ecryptfs-utils with a different PKGBUILD.

It handles python2 different (but I don't expect python to cause this)
and explicitly defines what to enable and what to disable, thus this is
what I use:

./configure --prefix=/usr --disable-gui --enable-pam --enable-nss \
--enable-openssl --disable-gpg --disable-pkcs11-helper --disable-tspi
Comment by Derek Sivers (sivers) - Friday, 23 December 2011, 05:45 GMT
To tredaelli (2 comments up): Thanks for the suggestion. I tried that, and got the same error.
# rm /etc/mtab
# cat /proc/self/mounts > /etc/mtab
# modprobe ecryptfs
# pacman -Sf filesystem

mount -t ecryptfs /home/me/.Private /Private -o ecryptfs_cipher=blowfish,ecryptfs_key_bytes=16,ecryptfs_fnek_sig=b46def43e7caab0e,key=passphrase

Works, but ends with:
Error mounting eCryptfs: [-5] Input/output error

/var/log/everything.log entry:
Dec 23 13:40:36 localhost mount.ecryptfs: Failed to write to the mount table

To Adrian C: (anrxc):
I also tried loading ecryptfs early in /etc/rc.conf - but no change.

Thanks for any/all/more suggestions.
Comment by KoS (KoS.oOo) - Thursday, 05 January 2012, 16:41 GMT
I have the same problem but creating the /etc/mtab as a file (as suggested by tredaelli) helps for me.
Thus I assume that sivers is absolutely right that the new filesystem package is ruining ecryptfs.

I just realized why it did not work for you... You need to issue the 'pacman -Sf filesystem' command only after you tested whether tredaelli's suggestion is working. It is only for restoring the previous state of the mtab file (to become a link again).
Comment by Techlive Zheng (techlive) - Tuesday, 17 January 2012, 11:54 GMT
I can confirm that this error message will occur while the /etc/mtab is symlink, but ecryptfs is accturally mounted and /etc/mtab has the correct item, everything is fine except the error message.

If do the following

# rm /etc/mtab
# cat /proc/self/mounts > /etc/mtab

everything is okay, no more error message.
Comment by Tom Gundersen (tomegun) - Tuesday, 17 January 2012, 13:32 GMT
Just adding my two cents, it looks like this (or a very similar) issue should have been fixed upstream in version 0.89. Might be worth looking into why that does not seem to be the case for us:
Comment by KoS (KoS.oOo) - Thursday, 19 January 2012, 19:33 GMT
Thanks techlive for highlighting that the partition is actually mounted despite the error message. I did not realize this till now and I was struggling with the mtab file all the time :)
Comment by Jeff Cook (cookiecaper) - Tuesday, 20 March 2012, 03:33 GMT
541 addressed a real issue, but it wasn't the one that was emitting the complaint about the mount table. I've written a patch [1] to address that warning and submitted it to Launchpad [2]. This resolves all ecryptfs-related chatter in my logs, and mount returns "Mounted eCryptfs" instead of i/o error.

Comment by whoop (whoop) - Tuesday, 03 April 2012, 17:03 GMT
# rm /etc/mtab
# cat /proc/self/mounts > /etc/mtab

Is it wise to do this or will there be a fix?
Comment by Xyne (Xyne) - Monday, 28 May 2012, 22:31 GMT
I wrote my own patch for this before I saw the one above. My version uses the same check that upstream uses in a separate file.

You can find the patch, a pacman source tarball and a quick explanation of the change here:

Upstream seems to be moving very slowly on this. Please release a patched version in the meantime. Even if the directory is mounted with the current release, the return code may propagate errors elsewhere.

You can just bump the release of the source tarball that I posted.
Comment by Timothy Redaelli (tredaelli) - Tuesday, 29 May 2012, 10:59 GMT
I agree, upstream is too lazy :)

Uploaded as 96-3

Thanks for your help.