Package Details: ecryptfs-simple 2017-2

Git Clone URL: (read-only)
Package Base: ecryptfs-simple
Description: A very simple utility for working with eCryptfs.
Upstream URL:
Keywords: encryption
Licenses: GPL
Submitter: Xyne
Maintainer: Xyne
Last Packager: Xyne
Votes: 17
Popularity: 0.434685
First Submitted: 2012-05-29 20:03
Last Updated: 2017-07-04 11:02

Latest Comments

mwohah commented on 2017-07-06 17:37

In case anyone's still wondering: it seems to be solved with systemd 233.75-2.

Xyne commented on 2017-07-05 11:56

If it's a systemd/ecryptfs-utils issue then we'll just have to wait until that's solved. If the problem persists after that then I will try to fix it.

hschletz commented on 2017-07-04 18:00

Looks like systemd 233 broke some ecryptfs tools:

I can still mount manually ("sudo mount -t ecryptfs ...") using the options from the config file ("ecryptfs-simple --print-config-path /home/foo/.Private").

mwohah commented on 2017-07-04 17:31

Since installing the latest updates on 2017-07-03 (lvm2 2.02.172-1, systemd 233-6, device-mapper 2.02.172-1, ...), ecryptfs-simple completely seems to have broken for me.

The CLI lists the following output after entering the (correct) passphrase:

> error: mount failed
> No such file or directory

The journal lists the following issues:

> Error parsing options; rc = [-2]
> One or more global auth toks could not properly register; rc = [-2]
> Could not find valid key in user session keyring for sig specified in mount
> process_request_key_err: No key
> Could not find key with description: [XXXXXXXXXXXXXXXX]

This happens with both ecryptfs-simple 2017-2 as well as the one from 2016.12-1 (I hadn't updated my AUR packages yet when I updated Arch, but I have now).

I'm experiencing no problems with ecryptfs via GDM and my encrypted home partition, however, which is strange.

To verify that I wasn't just typing the wrong password over and over and was somehow confused, I tried creating a completely new ecryptfs folder, which gives me the same error. I don't seem to be able to do anything with the utility anymore.

May be related to recent Arch package updates, seeing as I've been using it without problems every day before doing the Arch updates on 3 July.

Not sure if this is a bug or something else is going on and wasn't sure where to report this. Apologies if it's in the wrong place.

Xyne commented on 2017-07-04 11:29

fixed with 2017-2

hschletz commented on 2017-07-03 18:26

The source URL gives a 404 for the latest version.

Xyne commented on 2017-07-03 09:22

I'll try to fix this as soon as I have some time (hopefully later today).

edit: It should be fixed with ecryptfs-simple-2017

esilva commented on 2017-06-28 14:47

Scanning dependencies of target ecryptfs-simple
[ 50%] Building C object CMakeFiles/ecryptfs-simple.dir/src/ecryptfs-simple.c.o
[100%] Linking C executable ecryptfs-simple
CMakeFiles/ecryptfs-simple.dir/src/ecryptfs-simple.c.o: In function `main':
ecryptfs-simple.c:(.text.startup+0x21c): undefined reference to `copy_string_n'
collect2: error: ld returned 1 exit status
make[2]: *** [CMakeFiles/ecryptfs-simple.dir/build.make:97: ecryptfs-simple] Error 1
make[1]: *** [CMakeFiles/Makefile2:100: CMakeFiles/ecryptfs-simple.dir/all] Error 2
make: *** [Makefile:130: all] Error 2
==> ERROR: A failure occurred in build().

derdigge commented on 2017-06-27 09:31

Can confirm building fails on:

[code]CMakeFiles/ecryptfs-simple.dir/src/ecryptfs-simple.c.o: In function `join_paths':
ecryptfs-simple.c:(.text+0x858): undefined reference to `copy_string_n'
ecryptfs-simple.c:(.text+0x8ad): undefined reference to `copy_string_n'
ecryptfs-simple.c:(.text+0x8cb): undefined reference to `copy_string_n'
CMakeFiles/ecryptfs-simple.dir/src/ecryptfs-simple.c.o: In function `get_config_dir':
ecryptfs-simple.c:(.text+0xa06): undefined reference to `copy_string_n'
ecryptfs-simple.c:(.text+0xa2e): undefined reference to `copy_string_n'
CMakeFiles/ecryptfs-simple.dir/src/ecryptfs-simple.c.o:ecryptfs-simple.c:(.text+0xae5): more undefined references to `copy_string_n' follow
collect2: Fehler: ld gab 1 als Ende-Status zurück
make[2]: *** [CMakeFiles/ecryptfs-simple.dir/build.make:97: ecryptfs-simple] Fehler 1
make[1]: *** [CMakeFiles/Makefile2:100: CMakeFiles/ecryptfs-simple.dir/all] Fehler 2
make: *** [Makefile:130: all] Fehler 2[/code]

Confirmed fix as @Xyne said allready. Just change line 298 of src/encryptfs-simple.c fom "inline size_t" to "size_t"

nicolasgeniteau commented on 2017-06-01 14:42


Since the last update of gcc, ecryptfs-simple doesn't build anymore :
ecryptfs-simple.c:(.text+0x858): undefined reference to `copy_string_n'

Removing the inlining of the function seem to fix the error.

Xyne commented on 2017-02-27 23:15

I am able to create two empty directories, mount one on the other with ecryptfs-simple, create a file in the mounted directory, and inspect and manipulate both (plaintext & encrypted) via standard tools (ls, cat, rm).

I suspect that there is something else wrong with your system if the file permissions were changed on the entire partition. Check your system logs (syslog, journalctl, dmesg, etc.) for errors and maybe run a test on the disk with smartctl.

Sandi commented on 2017-02-24 15:15

I'm experiencing some weird behavior. I made two directories dir1 and dir2 for testing purposes, with a text file in dir1. Then I ran:

$ sudo modprobe ecryptfs
$ ecryptfs-simple dir1 dir2

After setting the passphrase and all other required settings, dir2 now contains the same text file, which is visible with ls. But, cat complains about input/output something or other when I try to read it, sublime displays an empty file, rm says the file doesn't exists, and sudo rm won't remove it because it's busy.

I ran ps aux | grep ecryptfs to see what's keeping it busy, finding a program called ecryptfs-kthrea (sic). It cannot be killed with -15, -1 or -2, not even by root. Restarting is the only way I've found to get rid of it.

Another weird thing is that both dir1 and dir2 are owned by root even though I created them. In fact, all the files on my data partition have ownership root root all of a sudden. I'm not sure if this was the case before, but I have read/write permission for them and I have created them all.

I should say I'm on Manjaro (but the package is from AUR installed via yaourt), running KDE.

Xyne commented on 2016-12-23 14:03

Thanks for posting an explanation. Sorry to everyone who was affected by the silent truncation bug.

mobad commented on 2016-12-22 17:44

For the people who are having problems decrypting with the latest version, it's likely due to the older versions of ecryptfs-simple silently truncating your password to 15 characters.

I tried everything to get it to mount but the fix in the end was to just use the first 15 characters of my password.

I really recommend people that were using ecryptfs-simple to create a new ecryptfs mount and copy everything to it.

Xyne commented on 2016-11-16 05:03

It should work again.

For anyone curious about the recent activity after years of no updates, it has been prompted by a discussion on the forum:

marcarch commented on 2016-11-15 08:39


I've got an issue with the version 2016.11.15.1.
When entering the passphrase as prompted, the decryption failes.

> ecryptfs-simple -o key=passphrase -a <dir1> <dir2>
> Mounting <dir1> on <dir2>
> Passphrase: error: option prompt failed

The downgrade to ecryptfs-simple 2016.11 solved the problem.

Distag commented on 2016-11-14 10:50

Hello, there is a problem with this new update. I cannot decrypt my files.

I take back the ecryptfs-simple-2016.11.13.tar.xz and I can read back my files with it.

Xyne commented on 2015-01-15 05:31

I have updated the upstream signature.

hschletz commented on 2015-01-14 17:31

PKGBUILD forces new signing key (8F173680), but package is still signed with the old key (C2E5C0D2). Had to edit PKGBUILD to use the old key to proceed.

Xyne commented on 2013-09-24 20:05

I have encounted problems with eCryptFS (independent of ecryptfs-simple) that have led to data loss. I can no longer recommend the use of eCryptFS. I will continue to maintain this package, but I strongly suggest that users switch to something else such as encfs.

If there are any ecryptfs enthusiasts who know how to recover from random input/output errors, please let me know and I may reconsider this stance.