1
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
15
<a href="http://ecryptfs.sourceforge.net">Main Page</a>
29
<li><a href="#novelty">What is novel about eCryptfs?</a></li>
31
<li><a href="#versions">What versions of the kernel have eCryptfs
34
<li><a href="#deployment">Will eCryptfs by itself protect all my
37
<li><a href="#access_lower">Can I access the lower files while
38
eCryptfs is mounted?</a></li>
40
<li><a href="#options">What kernel options do I need to enable to
41
build eCryptfs?</a></li>
43
<li><a href="#compatibility">On what filesystems can I expect eCryptfs
46
<li><a href="#stack">Why is the kernel stack such an issue with
49
<li><a href="#pubkey">Can I mount eCryptfs with a public key?</a></li>
51
<li><a href="#pubkey-about">Why would I want to use public key
54
<li><a href="#ecryptfsd">What is <code>ecryptfsd</code>?</a></li>
56
<li><a href="#ecryptfs-manager">What is
57
<code>ecryptfs-manager</code>?</a></li>
59
<li><a href="#nonroot">Do I have to be root to mount
62
<li><a href="#xattr">How do I store the metadata in the extended
63
attribute region of the lower file?</a></li>
65
<li><a href="#encryptedview">I am using the <code>-o xattr</code>
66
option, but my backup tools do not preserve extended attributes. How
67
can I back up the lower files?</a></li>
69
<li><a href="#filename-enc">What about filename encryption?</a></li>
71
<li><a href="#sparse">What about sparse files?</a></li>
73
<li><a href="#passphrase">How should I select my passphrase?</a></li>
75
<li><a href="#protectkey">How can I protect my key?</a></li>
77
<li><a href="#lostkey">I forgot my password/lost my key! What can I do
78
to recover my data?</a></li>
80
<li><a href="#compare">How does eCryptfs compare with other Linux disk
81
encryption solutions?</a></li>
83
<li><a href="#daemon-crash">Why does the eCryptfs daemon crash my
86
<li><a href="#no-ecryptfsac">Once one user can access an eCryptfs
87
file, any users with permission can also access the file. Should not
88
eCryptfs require all users to have the key in order to access the
91
<li><a href="#initcipher">"<code>Unable to allocate crypto cipher
92
with name [---]; rc = [-2]</code>"</a></li>
94
<li><a href="#baddir">"<code>Error mounting eCryptfs; rc = [-2];
95
strerr = [No such file or directory]</code>"</a></li>
97
<li><a href="#einval">"<code>Error mounting eCryptfs; rc = [-22];
98
strerr = [Invalid argument]</code>"</a></li>
100
<li><a href="#keyproblem">"<code>ecryptfs_parse_options: Could
101
not find key with description: [deadbeaf...]"</code></a></li>
103
<li><a href="#sigsize">"<code>ecryptfs_parse_packet_set: Expected
104
signature of size [8]; read size [7]"</code></a></li>
106
<li><a href="#nothere">My question isn't answered here.</a></li>
115
<p><h3>Q. What is novel about eCryptfs?</h3></p>
118
Well, nothing, to be honest. All of the techniques used in eCryptfs
119
are directly based on cryptographic technology that was widely known
120
and in practical use in the 1970's.
124
Security problems often arise when software tries to ``invent its own
125
crypto'' by deviating from what has been in common practical use for a
126
lengthy period of time. eCryptfs sticks to tried-and-true encryption
131
In terms of per-file key management, eCryptfs simply uses the methods
132
of PGP (created by Philip Zimmermann in 1991 and formally specified as
133
a public standard in RFC2440 in 1998) and takes the obvious and
134
conceptually trivial step of applying those methods within a
135
filesystem service in the kernel. eCryptfs employs the well-weathered
136
encryption techniques that have been in common use in the community
137
for over two decades. Other cryptographic filesystems published and
138
widely used in the 1990's use the same basic approach to encrypting
139
files. eCryptfs just happens to be the first such filesystem to make
140
it upstream in the Linux kernel.
145
<p><h3>Q. What versions of the kernel have eCryptfs support?</h3></p>
148
Linux kernel versions 2.6.19 and later have eCryptfs support. We
149
provide experimental backports, but only the official mainline kernel
150
is supported and is in active development.
153
<a name="deployment">
155
<p><h3>Q. Will eCryptfs by itself protect all my data?</h3></p>
158
eCryptfs is just one component in a comprehensive set of mechanisms to
159
protect the confidentiality of your data. Simply mounting eCryptfs
160
over a directory in your home directory will probably not provide
161
sufficient coverage for everything your applications will write to
162
disk. For instance, applications that produce and store thumbnails of
163
your images may write the thumbnails to an unprotected location.
167
Sensitive application data will typically wind up in the following
168
locations, although some applications will write data to other
169
locations not listed here:
173
<li>Anywhere in your home directory</li>
174
<li>The /tmp directory</li>
175
<li>The /var directory</li>
176
<li>The swap device</li>
180
The /tmp directory and the swap device can be easily protected with
181
dm-crypt using a key randomly generated when the system is booted,
182
since the information in those locations does not need to persist
183
between reboots. eCryptfs must mount the /var directory prior to any
184
daemons or other system applications reading from or writing to that
185
location (including the syslog utility). eCryptfs must also mount over
186
the user's home directory prior to the user logging into the system.
190
You will need to consider other applications that diverge from
191
traditional paths for storing data on a case-by-case basis. Analyzing
192
application behavior with the kernel auditing system is one way to
193
profile the behavior of an application, and explicit SE Linux rules
194
that only allow applications to write to encrypted mountpoints helps
195
prevent inadvertent information leakage. We recommend always using
196
eCryptfs together with appropriate Mandatory Access Control (MAC)
197
mechanisms to ensure that your sensitive data is always encrypted.
201
Proper deployment of a comprehensive per-file encryption mechanism is
202
a task best tackled by the entire Linux distribution. The eCryptfs
203
team is working closely with various major Linux distributions to help
204
ensure that eCryptfs is properly used as one component of a
205
comprehensive data protection strategy.
208
<a name="access_lower">
210
<p><h3>Q. Can I access the lower files while eCryptfs is mounted?</h3></p>
213
Accessing the lower files during an active eCryptfs mount is somewhat
214
like accessing a block device on which ext3 is mounted. The kernel
215
allows it, and it may work (depending on what you do with the data),
216
but it is not a good idea.
221
<p><h3>Q. What kernel options do I need to enable to build
226
Code maturity level options ---><br>
227
[*] Prompt for development and/or incomplete code/drivers<br>
229
Security options ---><br>
230
<M> Enable access key retention support<br>
232
Cryptographic options ---><br>
233
<M> MD5 digest algorithm<br>
234
<M> AES cipher algorithms<br>
236
File systems ---><br>
237
Miscellaneous filesystems ---><br>
238
<M> eCrypt filesystem layer support (EXPERIMENTAL)<br>
240
Recommended .config options (some options not available in older kernels):<br>
241
CONFIG_EXPERIMENTAL=y<br>
244
CONFIG_CRYPTO_ALGAPI=y<br>
245
CONFIG_CRYPTO_BLKCIPHER=y<br>
246
CONFIG_CRYPTO_HASH=y<br>
247
CONFIG_CRYPTO_MANAGER=y<br>
248
CONFIG_CRYPTO_MD5=y<br>
249
CONFIG_CRYPTO_ECB=y<br>
250
CONFIG_CRYPTO_CBC=y<br>
251
CONFIG_CRYPTO_AES=y<br>
257
Newer versions of the Linux kernel now have a ``Layered filesystems''
258
submenu under the ``File systems'' menu, where eCryptfs and Unionfs
263
Make certain that you have loaded all of the crypto modules that you
264
need to run eCryptfs. This includes <code>ecb</code>,
265
<code>cbc</code>, <code>md5</code>, and at least one popular symmetric
266
cipher, like <code>aes</code>.
269
<a name="compatibility">
271
<p><h3>Q. On what filesystems can I expect eCryptfs to function?</h3></p>
274
eCryptfs has been well tested on EXT3, and it should work well on
275
other popular local filesystems such as JFS, XFS, ReiserFS, and so
276
forth. Changes in the 2.6.24 kernel make eCryptfs more functional on
277
NFS and CIFS, although there is still a little more work to do in
278
order to make eCryptfs function as well on networked filesystems as it
279
currently works on local filesystems. There is a <a
280
href="http://downloads.sourceforge.net/ecryptfs/ecryptfs-fix-nfs.txt">patch</a>
281
to help resolve an unlink bug with eCryptfs on NFS; this patch will
282
eventually make it upstream once it is well tested.
287
<p><h3>Q. Why is the kernel stack such an issue with eCryptfs?</h3></p>
290
eCryptfs is a stacked filesystem. This implies that eCryptfs adds on
291
top of whatever call stack exists with current filesystems. Each
292
process in the Linux kernel has a fixed maximum stack size (4k+4k or
293
8k). Some filesystems (such as XFS) push the limit of the stack by
294
themselves; adding eCryptfs on top may cause a stack overflow on these
295
filesystems. If you wish to use eCryptfs on XFS, I recommend that you
296
first perform stress tests to help determine whether your specific
297
configuration will lead to a kernel process stack overflow.
302
<p><h3>Q. Can I mount eCryptfs with a public key?</h3></p>
305
You can mount eCryptfs with a public key if you have public key
306
support (<code>pubkey</code>) in your kernel. You first need to
307
generate a public/private keypair. Run <code>ecryptfs-manager</code>,
308
follow the prompts to generate the keypair for the key module of your
309
choosing, start the <code>ecryptfsd</code> daemon, and then specify
310
the key module when mounting. For instance, for the OpenSSL key
311
module, assuming you created your key in
312
<code>/usb-drive/mykey.pem</code> and you want to do a layover mount
313
on <code>/secret</code>, run:
319
# mount -t ecryptfs -o key=openssl:keyfile=/usb-drive/mykey.pem /secret /secret
323
<a name="pubkey-about">
325
<p><h3>Q. Why would I want to use public key anyway?</h3></p>
328
Cryptographic keys derived from passphrases are generally
329
worthless. Most passphrases that people can reasonably remember lack
330
even the strength of a 64-bit symmetric key. The idea behind using a
331
public key is to provide an opportunity for two-factor authentication;
332
for instance, with OpenSSL RSA, the PEM file is ``something you have''
333
and the passphrase is ``something you know.'' This works best if you
334
store your public key and your encrypted files on separate media.
338
The ``public key'' mode of operation in eCryptfs is actually more
339
general than public key. It allows for arbitrary key modules to
340
perform the File Encryption Key (FEK) encryption and decryption. The
341
key module could do RSA. Or, it could retrieve an employee's key from
342
a Domino server. Or, it could unseal the key protected by a Trusted
343
Computing chip, which will only honor the unseal request if the
344
machine is booted into a trusted state.
348
A key module now ships in ecryptfs-utils to interface with
349
cryptographic tokens via PKCS#11. There is also a key module to
350
interface with a TPM chip.
355
<p><h3>Q. What is <code>ecryptfsd</code>?</h3></p>
358
<code>ecryptfsd</code> is a daemon that runs as the user performing
359
file operations under the eCryptfs mount point. It manages public key
360
operations in userspace on file open events. <code>ecryptfsd</code>
361
only needs to be run when a mount is done with a public key module.
364
<a name="ecryptfs-manager">
366
<p><h3>Q. What is <code>ecryptfs-manager</code>?</h3></p>
369
<code>ecryptfs-manager</code> is an application that manages eCryptfs
370
objects such as keys. You can use <code>ecryptfs-manager</code> to ask
371
key modules to generate new keys for you, for instance.
376
<p><h3>Q. Do I have to be root to mount eCryptfs?</h3></p>
379
eCryptfs mounts can be set up to be done by non-root users. Generally,
380
you want to perform the initial key generation and mount as the root
381
user. Then, you can do a mount as a user by putting the appropriate
382
options in /etc/fstab, adding the keys to the user session keyring
383
(using ecryptfs-manager), and performing the mount in such a way that
384
bypasses the mount helper. This is not very well automated in the
385
current release, but it is possible right now with some manual
386
steps. The instructions on using the PAM module are contained in the
387
README and give the steps necessary to set that up; just follow all
388
the directions except the last PAM step to see how it works:
393
href="http://ecryptfs.sourceforge.net/README">http://ecryptfs.sourceforge.net/README</a>
396
In short, you will want something like this in your fstab:
400
/home/user/secret /home/user/secret ecryptfs
401
rw,ecryptfs_sig=deadbeefbaadf00d,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,user,noauto 0 0
406
You need to get the corresponding authentication token for the
407
ecryptfs_sig into your user session keyring;
408
<code>ecryptfs-manager</code> and the PAM module can both do this for
409
you. Alternatively, you can write your own application that calls
410
<code>ecryptfs_add_passphrase_key_to_keyring()</code> or
411
<code>ecryptfs_add_key_module_key_to_keyring()</code> in
412
<code>libecryptfs.so</code>. Then you will want to mount with the -i
413
option to prevent the mount helper from being called.
418
<p><h3>Q. How do I store the metadata in the extended attribute region
419
of the lower file?</h3></p>
422
If your kernel has support for it, mount with the <code>-o
423
xattr</code> option. Be sure to preserve the extended attributes in
424
the lower files, or you will lose your data. Bear in mind that many
425
userspace utilities such as <code>tar</code> lack extended attribute
426
support, and so you need to use utilities like <code>star</code> with
427
the proper options instead.
430
<a name="encryptedview">
432
<p><h3>Q. I am using the <code>-o xattr</code> option, but my backup
433
tools do not preserve extended attributes. How can I back up the lower
437
Mount with the <code>-o encrypted_view</code> flag and read the files
438
from under the eCryptfs mount point. The files read will be encrypted,
439
and the cryptographic metadata will be in the headers of the encrypted
440
files that are passed through, even if this metadata is actually
441
stored in the extended attribute regions of the lower files.
444
<a name="filename-enc">
446
<p><h3>Q. What about filename encryption?</h3></p>
449
The namespace problem arises when we consider the case where two files
450
have the same unencrypted name. This can be a problem when the user
451
does not have the key for every file in any given directory. Imagine,
452
for instance, that Alice creates a file named ``meeting_notes.txt'' in
453
a shared directory on an NFS server. The filename is encrypted with a
454
key known only to Alice and Carol. Bob then creates a file in the same
455
shared NFS directory and also names it ``meeting_notes.txt'',
456
encrypting the filename with another key only known to Bob and
457
Carol. Bob's eCryptfs client cannot detect the unencrypted filename
458
conflict in the namespace because Bob does not have Alice's key.
462
So two different files that have the same unencrypted name and
463
different encrypted names appear in the same directory. When Carol,
464
who has both Alice's key and Bob's key, lists the contents of the
465
directory, he winds up seeing two different files with the same
466
filename in the same directory, which is a POSIX violation.
470
The solution we may implement is to use a separate key just for
471
filename encryption, requiring all filenames encrypted under any given
472
directory to be encrypted with that key. Filename encryption is a
473
planned feature, but there is currently no set date for when it will
479
<p><h3>Q. What about sparse files?</h3></p>
482
eCryptfs does not currently support sparse files. Sequences of
483
encrypted extents with all 0's could be interpreted as sparse regions
484
in eCryptfs without too much implementation complexity. However, this
485
would open up a possible attack vector, since the fact that certain
486
segments of data are all 0's could betray strategic information that
487
the user does not necessarily want to reveal to an attacker. For
488
instance, if the attacker knows that a certain database file with
489
patient medical data keeps information about viral infections in one
490
region of the file and information about diabetes in another section
491
of the file, then the very fact that the segment for viral infection
492
data is populated with data at all would reveal that the patient has a
496
<a name="passphrase">
498
<p><h3>Q. How should I select my passphrase?</h3></p>
501
There are plenty of good guides out there to help you choose a strong
502
passphrase. Here is one, for instance: <a
503
href="http://www.iusmentis.com/security/passphrasefaq/">http://www.iusmentis.com/security/passphrasefaq/</a>.
506
<a name="protectkey">
508
<p><h3>Q. How can I protect my key?</h3></p>
511
Make a copy and store it in a physically secure location. For
512
instance, copy your public/private keypair to a USB flash drive or
513
write your passphrase onto a sheet of paper. Then, lock the drive and
514
paper in your desk drawer or put them in a safe deposit box (depending
515
on the sensitivity of the data that the keys protect). Future versions
516
of eCryptfs userspace utilities may implement key splitting functions
517
to provide even more paranoid levels of key protection.
521
Do not store your keys under the same physical security context in
522
which you are storing your media. It should be much harder for an
523
attacker to get to your keys than it is for him to get to your media.
527
When you use public key mode and generate a new key using
528
<code>ecryptfs-manager</code>, the generated key file is the one that
529
you must back up in order to access your files.
533
When mounting with a new key, I recommend performing a full mount,
534
creating a new file, unmounting, clearing the user session keyring
535
(<code>keyctl clear @u</code>), mounting again, and then trying to
536
access the newly created file. This minimizes the likelihood that you
537
will mistype a passphrase and create files that you will not be able
538
to later recover. When mounting in passphrase mode, make sure that the
539
ecryptfs_sig value matches between mounts. To help avoid the pitfall
540
of mistyping a passphrase on mount, eCryptfs stores a cache of
541
previous ecryptfs_sig values and warns the user if a mount passphrase
542
does not match any passphrases used for previous mounts.
547
<p><h3>Q. I forgot my password/lost my key! What can I do to recover
551
Nothing; you're screwed. (<a
552
href="http://www.cskk.ezoshosting.com/cs/goodstuff/bs-spc.html">Apologies</a>
557
If you have forgotten your passphrase, your only hope is that you
558
chose a weak passphrase in the first place. There is an outside chance
559
that you might be able to perform a successful dictionary attack to
560
recover your passphrase. If you manage to recover your passphrase that
561
way, then you may as well have not been bothering to encrypt your data
562
in the first place, since a malicious attacker could have done the
563
exact same thing to recover your passphrase.
567
If you selected a strong passphrase or lost your key file, you are
568
completely out of luck. Nobody can help you recover your data.
573
<p><h3>Q. How does eCryptfs compare with other Linux disk encryption
577
eCryptfs is an actual filesystem. Some other popular disk encryption
578
technologies are not filesystems; they are block device encryption
579
layers (they provide what appears to be a physical block device to
580
some actual filesystem). There is no filesystem logic in these
581
layers. A few of the more well-known block device encryption layers
582
include dm-crypt, Truecrypt, and Loop-AES. Perhaps the best thing
583
about block device-layer encryption is that it is an order of
584
magnitude simpler to implement than filesystem-layer
585
encryption. Another advantage of block device-layer encryption is that
586
it will encrypt the entire filesystem, including all of the filesystem
587
metadata. However, for many use cases, this can turn out to be more of
588
a disadvantage than an advantage.
592
While eCryptfs uses a powerful and flexible approach to protecting
593
filesystem content, block device-layer encryption technology is still
594
required to protect swap space and certain databases that use their
595
own block device partition. The table below provides a
596
compare-and-constrast of the two technologies. I anticipate that block
597
device encryption will be the best solution for some people, while
598
stacked filesystem encryption will be the best solution for
599
others. Sometimes it even makes sense to use them both together, to
600
combine the comprehensive full-disk encryption of a block device layer
601
encryption technology with the transparent per-file encryption
602
provided by eCryptfs (this will result in double-encryption of the
608
<table border=1 cellspacing=5 cellpadding=4>
611
<td width="50%"><center><b>Block Device Encryption</b></center></td>
612
<td width="50%"><center><b>Stacked Filesystem Encryption</b></center></td>
616
<td>Simple in concept and implementation; just transform blocks as
617
they pass through.</td>
618
<td>High level of design complexity; meticulous handling of internal
619
filesystem primitives required.</td>
623
<td>Must allocate a block device to dedicate for the entire
625
<td>Stacks on top of existing mounted filesystems; requires no special
626
on-disk storage allocation effort.</td>
630
<td>Everything in the filesystem incurs the cost of encryption and
631
decryption, regardless of the confidentiality requirements for the
633
<td>Selective encryption of the contents of only the sensitive
638
<td>Fully protects the confidentiality of the directory structures,
639
superblocks, file sizes, file permissions, and so forth.</td>
640
<td>Cannot keep all filesystem metadata confidential. Since stacked
641
filesystems encrypt on a per-file basis, attackers will know the
642
approximate file sizes, for instance.</td>
646
<td>Coarse granularity; only fixed per-mountpoint encryption policies
648
<td>Fine granularity; flexible per-file encryption policies are
653
<td>No notion of ``encrypted files.'' Individual files must be
654
re-encrypted via a userspace application before written to backups,
655
sent via email, etc.</td>
656
<td>Individual encrypted files can be accessed transparently by
657
applications; no additional work needed on the part of applications
658
before moving the files to another location.</td>
662
<td>Clients cannot use directly on networked filesystems; encryption
663
must be set up and managed on the server, or the client must encase
664
all of his files in a loopback mount, losing the per-file granularity
665
from the perspective of other clients.</td>
666
<td>Clients can stack on locally mounted networked filesystems;
667
individual files are sent to the server and stored in encrypted
670
<td>Can protect databases that use their own dedicated block device.</td>
671
<td>Can only protect databases that write their tables to regular
672
files in an existing filesystem.</td>
676
<td>Used to protect swap space.</td>
677
<td>Not designed to protect swap space; we recommend using block
678
device encryption to protect swap space while using eCryptfs on the
683
<td>Possible to hide the fact that the partition is encrypted.</td>
684
<td>The fact that encrypted data exists on the device is obvious to an
689
<td>Filesystem-agnostic; any filesystem will work on an encrypted
691
<td>Can only be expected to work with existing filesystems that are
692
upstream in the official Linux kernel.</td>
698
EncFS is another popular cryptographic filesystem that behaves much
699
like a stacked filesystem. EncFS is a userspace filesystem, and so
700
individual page reads and writes require additional context switches
701
between kernel and userspace. One advantage a userspace cryptographic
702
filesystem is that it is possible to use symmetric ciphers implemented
703
in userspace libraries, but the frequent context switching impacts
707
<a name="daemon-crash">
709
<p><h3>Why does the eCryptfs daemon crash my kernel?</h3></p>
712
You are probably using a kernel with the netlink interface to the
713
userspace daemon. The netlink interface with the userspace daemon is
718
To resolve the issue, there is a <a
719
href="http://downloads.sourceforge.net/ecryptfs/ecryptfs-miscdev-kernel-20080415-0.txt">patch</a>
720
to migrate eCryptfs from using netlink for kernel-daemon
721
communications to using a device handle instead. This patch has been
722
merged into the -mm tree, and we anticipate that this patch will find
723
its way into kernel release 2.6.26. In addition to this patch, you
724
will need ecryptfs-utils release 44 or greater.
727
<a name="no-ecryptfsac">
729
<p><h3>Once one user can access an eCryptfs file, any users with
730
permission can also access the file. Should not eCryptfs require all
731
users to have the key in order to access the files?</h3></p>
734
eCryptfs deliberately makes no attempt to re-implement the
735
discretionary and mandatory access control mechanisms already present
736
in the Linux kernel. eCryptfs will simply require that a File
737
Encryption Key (FEK) be associated with any given inode in order to
738
decrypt the contents of the file on disk. This prevents an attacker
739
from accessing the file contents outside the context of the trusted
740
host environment; for instance, by removing the storage device or by
741
booting a live CD. This is the only type of unauthorized access that
742
eCryptfs is intended to prevent.
746
Once eCryptfs has associated that FEK with the inode, it does not
747
impose any additional restrictions on who or what can access the
748
files, deferring to the standard user/group/other permissions,
749
capabilities, SE Linux type enforcement, and so forth to regulate
750
access to the files. eCryptfs maintains no pedigree regarding how the
751
FEK found its way to the inode, so it has no way of knowing that any
752
particular UID should or should not be able to open the file, nor
753
should eCryptfs do such a thing.
757
Having eCryptfs impose additional access control onto the decrypted
758
file contents in a trusted host environment would provide no
759
additional security while introducing unintended usability issues. For
760
instance, a user may wish to share his decrypted files with certain
761
other users on the system without having to share his key with them or
762
add their keys to a set of keys wrapping the inode's FEK. Users expect
763
to be able to accomplish such a task via users, groups, capabilities,
764
and types, and eCryptfs defers access control decisions on trusted
765
host environments to these existing access control mechanisms.
768
<a name="initcipher">
770
<p><h3>Q. "<code>Unable to allocate crypto cipher with name
771
[---]; rc = [-2]</code>"</h3></p>
774
Make sure that you have enabled the kernel crypto API and that you
775
have built the ciphers, hashes, and chaining modes that you wish to
776
use. This will usually be md5, aes, cbc, and ecb. Also, make sure that
777
the requested key size is valid for your cipher.
782
<p><h3>Q. "<code>Error mounting eCryptfs; rc = [-2]; strerr = [No
783
such file or directory]</code>"</h3></p>
786
Make sure that both the source and destination directories that you
787
provide to the mount command exist.
792
<p><h3>Q. "<code>Error mounting eCryptfs; rc = [-22]; strerr =
793
[Invalid argument]</code>"</a></h3></p>
796
Check your system log for the real problem.
799
<a name="keyproblem">
801
<p><h3>Q. "<code>ecryptfs_parse_options: Could not find key with
802
description: [deadbeaf...]"</code></h3></p>
805
If the mount fails and the message "<code>ecryptfs_parse_options:
806
Could not find key with description: [deadbeaf...]"</code> is in
807
your system logs, then there was a problem inserting your mount key
808
into your kernel <i>user session</i> keyring.
812
After a mount attempt, run <code>keyctl_show</code>. You should see
819
-3 lswrv---------- 0 0 keyring: _uid_ses.0
820
2 lswrv---------- 0 0 \_ keyring: _uid.0
821
892244932 lswrv---------- 0 0 \_ user: deadbeef...
825
Where <code>deadbeef</code> is the signature that corresponds with
826
your key. If you don't see this, then there is a problem with your
831
If you su to root, be sure to initiate the session by using the -
836
Finally, try linking your user keyring into your active session
846
<p><h3>Q. "<code>ecryptfs_parse_packet_set: Expected
847
signature of size [8]; read size [7]</code>"</h3></p>
850
Older versions of eCryptfs shipping in older kernels had a minor bug
851
where eCryptfs would only write out and read in 7 of the 8 key
852
signature characters to the metadata of the lower file. This violates
853
the eCryptfs spec, so newer versions of eCryptfs correct this bug and
854
refuse to read files that do not conform to the spec.
858
The current correctly implemented version of eCryptfs cannot read
859
files created with the early nonconformant and buggy release. If you
860
have any files created with the earlier version, you will need to boot
861
with the earlier version of eCryptfs and copy the decrypted files to
862
secure location (e.g., a loopback mount image protected with
863
dm-crypt). You will then need to copy the data from the secure
864
location into an eCryptfs mount using the most recent kernel release.
868
Note that the Versions of eCryptfs from 2.6.24 and on will be able to
869
read files created by earlier versions, back through to 2.6.24, as
870
indicated in the ecryptfs-utils package README file:
875
eCryptfs is still in a developmental stage. When you upgrade the
876
eCryptfs kernel module, it is possible that the eCryptfs file format
877
has been updated. For this reason you should copy your files to an
878
unencrypted location and then copy the files back into the new
879
eCryptfs mount point to migrate the files. File format version 3 and
880
beyond (in kernel version 2.6.24) is expected to remain readable,
887
<p><h3>Q. My question isn't answered here.</h3></p>
890
Send a message to the <a
891
href="http://lists.sourceforge.net/lists/listinfo/ecryptfs-users">ecryptfs-users</a>
907
<br><br><br><br><br><br><br><br><br><br><br><br><br><br>
908
<br><br><br><br><br><br><br><br><br><br><br><br><br><br>
909
<br><br><br><br><br><br><br><br><br><br><br><br><br><br>
910
<br><br><br><br><br><br><br><br><br><br><br><br><br><br>
added
removed
doc/sourceforge_webpage/ecryptfs-faq.html
