« back to all changes in this revision
Viewing changes to doc/ecryptfs-faq.html
- browse files at revision 2
- compare with another revision
- download diff
- download tarball
- view history from revision 2
- Committer: mhalcrow@us.ibm.com
- Date: 2007-11-06 22:56:01 UTC
- Revision ID: git-v1:f8357de9d554b274497b5cce9db4347254b7e7eb
Initial import of eCryptfs filesystem userspace utilities (mount helper, daemon component,
etc.)
etc.)
added
removed
doc/ecryptfs-faq.html
1
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
2
<html>
3
<head>
4
<title>
5
eCryptfs
6
</title>
7
</head>
8
<body>
9
10
<h1>eCryptfs</h1>
11
<h3>FAQ</h3>
12
13
<hr>
14
15
<a href="http://ecryptfs.sourceforge.net">Main Page</a>
16
17
<hr>
18
19
<table width="640">
20
<tr>
21
<td>
22
23
<p>
24
25
<h3>Index</h3>
26
27
<ul>
28
29
<li><a href="#novelty">What is novel about eCryptfs?</a></li>
30
31
<li><a href="#versions">What versions of the kernel have eCryptfs
32
support?</a></li>
33
34
<li><a href="#access_lower">Can I access the lower files while
35
eCryptfs is mounted?</a></li>
36
37
<li><a href="#options">What kernel options do I need to enable to
38
build eCryptfs?</a></li>
39
40
<li><a href="#compatibility">On what filesystems can I expect eCryptfs
41
to function?</a></li>
42
43
<li><a href="#stack">Why is the kernel stack such an issue with
44
eCryptfs?</a></li>
45
46
<li><a href="#pubkey">Can I mount eCryptfs with a public key?</a></li>
47
48
<li><a href="#pubkey-about">Why would I want to use public key
49
anyway?</a></li>
50
51
<li><a href="#ecryptfsd">What is <code>ecryptfsd</code>?</a></li>
52
53
<li><a href="#ecryptfs-manager">What is
54
<code>ecryptfs-manager</code>?</a></li>
55
56
<li><a href="#nonroot">Do I have to be root to mount
57
eCryptfs?</a></li>
58
59
<li><a href="#features">How can I find out which features are in my
60
eCryptfs kernel module?</a></li>
61
62
<li><a href="#xattr">How do I store the metadata in the extended
63
attribute region of the lower file?</a></li>
64
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>
68
69
<li><a href="#filename-enc">What about filename encryption?</a></li>
70
71
<li><a href="#sparse">What about sparse files?</a></li>
72
73
<li><a href="#passphrase">How should I select my passphrase?</a></li>
74
75
<li><a href="#protectkey">How can I protect my key?</a></li>
76
77
<li><a href="#lostkey">I forgot my password/lost my key! What can I do
78
to recover my data?</a></li>
79
80
<li><a href="#compare">How does eCryptfs compare with other Linux disk
81
encryption solutions?</a></li>
82
83
<li><a href="#baddir">"<code>Error mounting eCryptfs; rc = [-2];
84
strerr = [No such file or directory]</code>"</a></li>
85
86
<li><a href="#einval">"<code>Error mounting eCryptfs; rc = [-22];
87
strerr = [Invalid argument]</code>"</a></li>
88
89
<li><a href="#keyproblem">"<code>ecryptfs_parse_options: Could
90
not find key with description: [deadbeaf...]"</code></a></li>
91
92
<li><a href="#nothere">My question isn't answered here.</a></li>
93
94
</ul>
95
</p>
96
97
</p>
98
99
<a name="novelty">
100
101
<p><h3>Q. What is novel about eCryptfs?</h3></p>
102
103
<p>
104
Well, nothing, to be honest. All of the techniques used in eCryptfs
105
are directly based on cryptographic technology that was widely known
106
and in practical use in the 1970's.
107
</p>
108
109
<p>
110
Security problems often arise when software tries to ``invent its own
111
crypto'' by deviating from what has been in common practical use for a
112
lengthy period of time. eCryptfs sticks to tried-and-true encryption
113
technology.
114
</p>
115
116
<p>
117
In terms of per-file key management, eCryptfs simply uses the methods
118
of PGP (created by Philip Zimmermann in 1991 and formally specified as
119
a public standard in RFC2440 in 1998) and takes the obvious and
120
conceptually trivial step of applying those methods within a
121
filesystem service in the kernel. eCryptfs employs the well-weathered
122
encryption techniques that have been in common use in the community
123
for over two decades. Other cryptographic filesystems published and
124
widely used in the 1990's use the same basic approach to encrypting
125
files. eCryptfs just happens to be the first such filesystem to make
126
it upstream in the Linux kernel.
127
</p>
128
129
<a name="versions">
130
131
<p><h3>Q. What versions of the kernel have eCryptfs support?</h3></p>
132
133
<p>
134
Linux kernel versions 2.6.19 and later have eCryptfs support. We
135
provide experimental backports, but only the official mainline kernel
136
is supported and is in active development.
137
</p>
138
139
<a name="access_lower">
140
141
<p><h3>Q. Can I access the lower files while eCryptfs is mounted?</h3></p>
142
143
<p>
144
Accessing the lower files during an active eCryptfs mount is somewhat
145
like accessing a block device on which ext3 is mounted. The kernel
146
allows it, and it may work (depending on what you do with the data),
147
but it is not a good idea.
148
</p>
149
150
<a name="options">
151
152
<p><h3>Q. What kernel options do I need to enable to build
153
eCryptfs?</h3></p>
154
155
<p>
156
<code>
157
Code maturity level options ---><br>
158
[*] Prompt for development and/or incomplete code/drivers<br>
159
<br>
160
Security options ---><br>
161
<M> Enable access key retention support<br>
162
<br>
163
Cryptographic options ---><br>
164
<M> MD5 digest algorithm<br>
165
<M> AES cipher algorithms<br>
166
<br>
167
File systems ---><br>
168
Miscellaneous filesystems ---><br>
169
<M> eCrypt filesystem layer support (EXPERIMENTAL)<br>
170
<br>
171
Recommended .config options (some options not available in older kernels):<br>
172
CONFIG_EXPERIMENTAL=y<br>
173
CONFIG_KEYS=y<br>
174
CONFIG_CRYPTO=y<br>
175
CONFIG_CRYPTO_ALGAPI=y<br>
176
CONFIG_CRYPTO_BLKCIPHER=y<br>
177
CONFIG_CRYPTO_HASH=y<br>
178
CONFIG_CRYPTO_MANAGER=y<br>
179
CONFIG_CRYPTO_MD5=y<br>
180
CONFIG_CRYPTO_ECB=y<br>
181
CONFIG_CRYPTO_CBC=y<br>
182
CONFIG_CRYPTO_AES=y<br>
183
CONFIG_ECRYPT_FS=m
184
</code>
185
</p>
186
187
<p>
188
Newer versions of the Linux kernel now have a ``Layered filesystems''
189
submenu under the ``File systems'' menu, where eCryptfs and Unionfs
190
reside.
191
</p>
192
193
<p>
194
Make certain that you have loaded all of the crypto modules that you
195
need to run eCryptfs. This includes <code>ecb</code>,
196
<code>cbc</code>, <code>md5</code>, and at least one popular symmetric
197
cipher, like <code>aes</code>.
198
</p>
199
200
<a name="compatibility">
201
202
<p><h3>Q. On what filesystems can I expect eCryptfs to function?</h3></p>
203
204
<p>
205
eCryptfs has been well tested on ext3 and jfs. eCryptfs on xfs may be
206
problematic because xfs can take up most of the available space for
207
the call stack. eCryptfs currently has some degree of functionality on
208
CIFS, and the eCryptfs development team is working with a member of
209
the CIFS development team to get the kinks worked out. eCryptfs is
210
broken on NFS for all kernels. Unionfs is also affected, and the
211
Unionfs team is making good progress at getting the issues with
212
stacking on NFS resolved.
213
</p>
214
215
<a name="stack">
216
217
<p><h3>Q. Why is the kernel stack such an issue with eCryptfs?</h3></p>
218
219
<p>
220
eCryptfs is a stacked filesystem. This implies that eCryptfs adds on
221
top of whatever call stack exists with current filesystems. Each
222
process in the Linux kernel has a fixed maximum stack size (4k+4k or
223
8k). Some filesystems (such as xfs) push the limit of the stack by
224
themselves; adding eCryptfs on top may cause a stack overflow on these
225
filesystems. If you wish to use eCryptfs on XFS, I recommend that you
226
first perform stress tests to help determine whether your specific
227
configuration will lead to a kernel process stack overflow.
228
</p>
229
230
<a name="pubkey">
231
232
<p><h3>Q. Can I mount eCryptfs with a public key?</h3></p>
233
234
<p>
235
You can mount eCryptfs with a public key if you have public key
236
support (<code>pubkey</code>) in your kernel. You first need to
237
generate a public/private keypair. Run <code>ecryptfs-manager</code>,
238
follow the prompts to generate the keypair for the key module of your
239
choosing, start the <code>ecryptfsd</code> daemon, and then specify
240
the key module when mounting. For instance, for the OpenSSL key
241
module, assuming you created your key in
242
<code>/usb-drive/mykey.pem</code> and you want to do a layover mount
243
on <code>/secret</code>, run:
244
</p>
245
246
<p>
247
<code>
248
# ecryptfsd<br>
249
# mount -t ecryptfs -o key=openssl:keyfile=/usb-drive/mykey.pem /secret /secret
250
</code>
251
</p>
252
253
<a name="pubkey-about">
254
255
<p><h3>Q. Why would I want to use public key anyway?</h3></p>
256
257
<p>
258
Cryptographic keys derived from passphrases are generally
259
worthless. Most passphrases that people can reasonably remember lack
260
even the strength of a 64-bit symmetric key. The idea behind using a
261
public key is to provide an opportunity for two-factor authentication;
262
for instance, with OpenSSL RSA, the PEM file is ``something you have''
263
and the passphrase is ``something you know.'' This works best if you
264
store your public key and your encrypted files on separate media.
265
</p>
266
267
<p>
268
The ``public key'' mode of operation in eCryptfs is actually more
269
general than public key. It allows for arbitrary key modules to
270
perform the File Encryption Key (FEK) encryption and decryption. The
271
key module could do RSA. Or, it could retrieve an employee's key from
272
a Domino server. Or, it could unseal the key protected by a Trusted
273
Computing chip, which will only honor the unseal request if the
274
machine is booted into a trusted state. This TPM-based protection is
275
actually on the work queue for this year.
276
</p>
277
278
<a name="ecryptfsd">
279
280
<p><h3>Q. What is <code>ecryptfsd</code>?</h3></p>
281
282
<p>
283
<code>ecryptfsd</code> is a daemon that runs as the user performing
284
file operations under the eCryptfs mount point. It manages public key
285
operations in userspace on file open events. <code>ecryptfsd</code>
286
only needs to be run when a mount is done with a public key module.
287
</p>
288
289
<a name="ecryptfs-manager">
290
291
<p><h3>Q. What is <code>ecryptfs-manager</code>?</h3></p>
292
293
<p>
294
<code>ecryptfs-manager</code> is an application that manages eCryptfs
295
objects such as keys. You can use <code>ecryptfs-manager</code> to ask
296
key modules to generate new keys for you, for instance.
297
</p>
298
299
<a name="nonroot">
300
301
<p><h3>Q. Do I have to be root to mount eCryptfs?</h3></p>
302
303
<p>
304
eCryptfs mounts can be set up to be done by non-root users. Generally,
305
you want to perform the initial key generation and mount as the root
306
user. Then, you can do a mount as a user by putting the appropriate
307
options in /etc/fstab, adding the keys to the user session keyring
308
(using ecryptfs-manager), and performing the mount in such a way that
309
bypasses the mount helper. This is not very well automated in the
310
current release, but it is possible right now with some manual
311
steps. The instructions on using the PAM module are contained in the
312
README and give the steps necessary to set that up; just follow all
313
the directions except the last PAM step to see how it works:
314
</p>
315
316
<p>
317
<a
318
href="http://ecryptfs.sourceforge.net/README">http://ecryptfs.sourceforge.net/README</a>
319
</p>
320
321
In short, you will want something like this in your fstab:
322
323
<p>
324
<code>
325
/home/user/secret /home/user/secret ecryptfs
326
rw,ecryptfs_sig=deadbeefbaadf00d,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,user,noauto 0 0
327
</code>
328
</p>
329
330
<p>
331
You need to get the corresponding authentication token for the
332
ecryptfs_sig into your user session keyring;
333
<code>ecryptfs-manager</code> and the PAM module can both do this for
334
you. Alternatively, you can write your own application that calls
335
<code>ecryptfs_add_passphrase_key_to_keyring()</code> or
336
<code>ecryptfs_add_key_module_key_to_keyring()</code> in
337
<code>libecryptfs.so</code>. Then you will want to mount with the -i
338
option to prevent the mount helper from being called.
339
</p>
340
341
<a name="features">
342
343
<p><h3>Q. How can I find out which features are in my eCryptfs kernel
344
module?</h3></p>
345
346
<p>
347
View the contents of <code>fs/ecryptfs/version_str</code> under your
348
<code>sysfs</code> mount point (typically <code>/sys</code>). For
349
instance:</p>
350
351
<p>
352
<code>
353
# cat /sys/fs/ecryptfs/version_str<br>
354
passphrase<br>
355
pubkey<br>
356
plaintext passthrough<br>
357
metadata in extended attribute<br>
358
</code>
359
</p>
360
361
<p>
362
In this particular example, the kernel has passphrase support, public
363
key support, plaintext passthrough support, and support for storing
364
cryptographic metadata in the extended attribute regions of the lower
365
files.
366
</p>
367
368
<a name="xattr">
369
370
<p><h3>Q. How do I store the metadata in the extended attribute region
371
of the lower file?</h3></p>
372
373
<p>
374
If your kernel has support for it, mount with the <code>-o
375
xattr</code> option. Be sure to preserve the extended attributes in
376
the lower files, or you will lose your data. Bear in mind that many
377
userspace utilities such as <code>tar</code> lack extended attribute
378
support, and so you need to use utilities like <code>star</code> with
379
the proper options instead.
380
</p>
381
382
<a name="encryptedview">
383
384
<p><h3>Q. I am using the <code>-o xattr</code> option, but my backup
385
tools do not preserve extended attributes. How can I back up the lower
386
files?</h3></p>
387
388
<p>
389
Mount with the <code>-o encrypted_view</code> flag and read the files
390
from under the eCryptfs mount point. The files read will be encrypted,
391
and the cryptographic metadata will be in the headers of the encrypted
392
files that are passed through, even if this metadata is actually
393
stored in the extended attribute regions of the lower files.
394
</p>
395
396
<a name="filename-enc">
397
398
<p><h3>Q. What about filename encryption?</h3></p>
399
400
<p>
401
The namespace problem arises when we consider the case where two files
402
have the same unencrypted name. This can be a problem when the user
403
does not have the key for every file in any given directory. Imagine,
404
for instance, that Alice creates a file named ``meeting_notes.txt'' in
405
a shared directory on an NFS server. The filename is encrypted with a
406
key known only to Alice and Carol. Bob then creates a file in the same
407
shared NFS directory and also names it ``meeting_notes.txt'',
408
encrypting the filename with another key only known to Bob and
409
Carol. Bob's eCryptfs client cannot detect the unencrypted filename
410
conflict in the namespace because Bob does not have Alice's key.
411
</p>
412
413
<p>
414
So two different files that have the same unencrypted name and
415
different encrypted names appear in the same directory. When Carol,
416
who has both Alice's key and Bob's key, lists the contents of the
417
directory, he winds up seeing two different files with the same
418
filename in the same directory, which is a POSIX violation.
419
</p>
420
421
<p>
422
The solution we may implement is to use a separate key just for
423
filename encryption, requiring all filenames encrypted under any given
424
directory to be encrypted with that key. Filename encryption is a
425
planned feature, but there is currently no set date for when it will
426
be completed.
427
</p>
428
429
<a name="sparse">
430
431
<p><h3>Q. What about sparse files?</h3></p>
432
433
<p>
434
eCryptfs does not currently support sparse files. Sequences of
435
encrypted extents with all 0's could be interpreted as sparse regions
436
in eCryptfs without too much implementation complexity. However, this
437
would open up a possible attack vector, since the fact that certain
438
segments of data are all 0's could betray strategic information that
439
the user does not necessarily want to reveal to an attacker. For
440
instance, if the attacker knows that a certain database file with
441
patient medical data keeps information about viral infections in one
442
region of the file and information about diabetes in another section
443
of the file, then the very fact that the segment for viral infection
444
data is populated with data at all would reveal that the patient has a
445
viral infection.
446
</p>
447
448
<a name="passphrase">
449
450
<p><h3>Q. How should I select my passphrase?</h3></p>
451
452
<p>
453
There are plenty of good guides out there to help you choose a strong
454
passphrase. Here is one, for instance: <a
455
href="http://www.iusmentis.com/security/passphrasefaq/">http://www.iusmentis.com/security/passphrasefaq/</a>.
456
</p>
457
458
<a name="protectkey">
459
460
<p><h3>Q. How can I protect my key?</h3></p>
461
462
<p>
463
Make a copy and store it in a physically secure location. For
464
instance, copy your public/private keypair to a USB flash drive or
465
write your passphrase onto a sheet of paper. Then, lock the drive and
466
paper in your desk drawer or put them in a safe deposit box (depending
467
on the sensitivity of the data that the keys protect). Future versions
468
of eCryptfs userspace utilities may implement key splitting functions
469
to provide even more paranoid levels of key protection.
470
</p>
471
472
<p>
473
Do not store your keys under the same physical security context in
474
which you are storing your media. It should be much harder for an
475
attacker to get to your keys than it is for him to get to your media.
476
</p>
477
478
<p>
479
When you use public key mode and generate a new key using
480
<code>ecryptfs-manager</code>, the generated key file is the one that
481
you must back up in order to access your files.
482
</p>
483
484
<p>
485
When mounting with a new key, I recommend performing a full mount,
486
creating a new file, unmounting, clearing the user session keyring
487
(<code>keyctl clear @u</code>), mounting again, and then trying to
488
access the newly created file. This minimizes the likelihood that you
489
will mistype a passphrase and create files that you will not be able
490
to later recover. When mounting in passphrase mode, make sure that the
491
ecryptfs_sig value matches between mounts. Future versions of eCryptfs
492
will store a cache of previous ecryptfs_sig values and warn the user
493
if a mount passphrase does not match any passphrases used for previous
494
mounts.
495
</p>
496
497
<a name="lostkey">
498
499
<p><h3>Q. I forgot my password/lost my key! What can I do to recover
500
my data?</h3></p>
501
502
<p>
503
Nothing; you're screwed. (<a
504
href="http://www.cskk.ezoshosting.com/cs/goodstuff/bs-spc.html">Apologies</a>
505
to Bruce Schneier).
506
</p>
507
508
<p>
509
If you have forgotten your passphrase, your only hope is that you
510
chose a weak passphrase in the first place. There is an outside chance
511
that you might be able to perform a successful dictionary attack to
512
recover your passphrase. If you manage to recover your passphrase that
513
way, then you may as well have not been bothering to encrypt your data
514
in the first place, since a malicious attacker could have done the
515
exact same thing to recover your passphrase.
516
</p>
517
518
<p>
519
If you selected a strong passphrase or lost your key file, you are
520
screwed no matter what. Nobody can help you recover your data.
521
</p>
522
523
<a name="compare">
524
525
<p><h3>Q. How does eCryptfs compare with other Linux disk encryption
526
solutions?</h3></p>
527
528
<p>
529
eCryptfs is an actual filesystem. Some other popular disk encryption
530
technologies are not filesystems; they are block device encryption
531
layers (they provide what appears to be a physical block device to
532
some actual filesystem). There is no filesystem logic in these
533
layers. A few of the more well-known block device encryption layers
534
include dm-crypt, Truecrypt, and Loop-AES. Perhaps the best thing
535
about block device-layer encryption is that it is an order of
536
magnitude simpler to implement than filesystem-layer
537
encryption. Another advantage of block device-layer encryption is that
538
it will encrypt the entire filesystem, including all of the filesystem
539
metadata. However, for many use cases, this can turn out to be more of
540
a disadvantage than an advantage.
541
</p>
542
543
<p>
544
While eCryptfs uses a powerful and flexible approach to protecting
545
filesystem content, block device-layer encryption technology is still
546
required to protect swap space and certain databases that use their
547
own block device partition. The table below provides a
548
compare-and-constrast of the two technologies. I anticipate that block
549
device encryption will be the best solution for some people, while
550
stacked filesystem encryption will be the best solution for
551
others. Sometimes it even makes sense to use them both together, to
552
combine the comprehensive full-disk encryption of a block device layer
553
encryption technology with the transparent per-file encryption
554
provided by eCryptfs (this will result in double-encryption of the
555
file contents).
556
</p>
557
558
<br>
559
560
<table border=1 cellspacing=5 cellpadding=4>
561
562
<tr>
563
<td width="50%"><center><b>Block Device Encryption</b></center></td>
564
<td width="50%"><center><b>Stacked Filesystem Encryption</b></center></td>
565
</tr>
566
567
<tr>
568
<td>Simple in concept and implementation; just transform blocks as
569
they pass through.</td>
570
<td>High level of design complexity; meticulous handling of internal
571
filesystem primitives required.</td>
572
</tr>
573
574
<tr>
575
<td>Must allocate a block device to dedicate for the entire
576
filesystem.</td>
577
<td>Stacks on top of existing mounted filesystems; requires no special
578
on-disk storage allocation effort.</td>
579
</tr>
580
581
<tr>
582
<td>Everything in the filesystem incurs the cost of encryption and
583
decryption, regardless of the confidentiality requirements for the
584
data.</td>
585
<td>Selective encryption of the contents of only the sensitive
586
files.</td>
587
</tr>
588
589
<tr>
590
<td>Fully protects the confidentiality of the directory structures,
591
superblocks, file sizes, file permissions, and so forth.</td>
592
<td>Cannot keep all filesystem metadata confidential. Since stacked
593
filesystems encrypt on a per-file basis, attackers will know the
594
approximate file sizes, for instance.</td>
595
</tr>
596
597
<tr>
598
<td>Coarse granularity; only fixed per-mountpoint encryption policies
599
are possible.</td>
600
<td>Fine granularity; flexible per-file encryption policies are
601
possible.</td>
602
</tr>
603
604
<tr>
605
<td>No notion of ``encrypted files.'' Individual files must be
606
re-encrypted via a userspace application before written to backups,
607
sent via email, etc.</td>
608
<td>Individual encrypted files can be accessed transparently by
609
applications; no additional work needed on the part of applications
610
before moving the files to another location.</td>
611
</tr>
612
613
<tr>
614
<td>Clients cannot use directly on networked filesystems; encryption
615
must be set up and managed on the server, or the client must encase
616
all of his files in a loopback mount, losing the per-file granularity
617
from the perspective of other clients.</td>
618
<td>Clients can stack on locally mounted networked filesystems;
619
individual files are sent to the server and stored in encrypted
620
form.</td> </tr>
621
<tr>
622
<td>Can protect databases that use their own dedicated block device.</td>
623
<td>Can only protect databases that write their tables to regular
624
files in an existing filesystem.</td>
625
</tr>
626
627
<tr>
628
<td>Used to protect swap space.</td>
629
<td>Not designed to protect swap space; we recommend using block
630
device encryption to protect swap space while using eCryptfs on the
631
filesystem.</td>
632
</tr>
633
634
<tr>
635
<td>Possible to hide the fact that the partition is encrypted.</td>
636
<td>The fact that encrypted data exists on the device is obvious to an
637
observer.</td>
638
</tr>
639
640
<tr>
641
<td>Filesystem-agnostic; any filesystem will work on an encrypted
642
block device.</td>
643
<td>Can only be expected to work with existing filesystems that are
644
upstream in the official Linux kernel.</td>
645
</tr>
646
647
</table>
648
649
<p>
650
EncFS is another popular cryptographic filesystem that behaves much
651
like a stacked filesystem. EncFS is a userspace filesystem, and so
652
individual page reads and writes require additional context switches
653
between kernel and userspace. One advantage a userspace cryptographic
654
filesystem is that it is possible to use symmetric ciphers implemented
655
in userspace libraries, but the frequent context switching impacts
656
performance. In addition, EncFS uses FUSE, which suffers from the fact
657
that shared writable memory mappings must be entirely disabled in
658
order to avoid deadlock on some page swap events.
659
</p>
660
661
<a name="baddir">
662
663
<p><h3>Q. "<code>Error mounting eCryptfs; rc = [-2]; strerr = [No
664
such file or directory]</code>"</h3></p>
665
666
<p>
667
Make sure that both the source and destination directories that you
668
provide to the mount command exist.
669
</p>
670
671
<a name="einval">
672
673
<p><h3>Q. "<code>Error mounting eCryptfs; rc = [-22]; strerr =
674
[Invalid argument]</code>"</a></h3></p>
675
676
<p>
677
Check your system log for the real problem.
678
</p>
679
680
<a name="keyproblem">
681
682
<p><h3>Q. "<code>ecryptfs_parse_options: Could not find key with
683
description: [deadbeaf...]"</code></h3></p>
684
685
<p>
686
If the mount fails and the message "<code>ecryptfs_parse_options:
687
Could not find key with description: [deadbeaf...]"</code> is in
688
your system logs, then there was a problem inserting your mount key
689
into your kernel <i>user session</i> keyring.
690
</p>
691
692
<p>
693
After a mount attempt, run <code>keyctl_show</code>. You should see
694
something like this:
695
</p>
696
697
<pre>
698
# keyctl show
699
Session Keyring
700
-3 lswrv---------- 0 0 keyring: _uid_ses.0
701
2 lswrv---------- 0 0 \_ keyring: _uid.0
702
892244932 lswrv---------- 0 0 \_ user: deadbeef...
703
</pre>
704
705
<p>
706
Where <code>deadbeef</code> is the signature that corresponds with
707
your key. If you don't see this, then there is a problem with your
708
keyring setup.
709
</p>
710
711
<p>
712
If you su to root, be sure to initiate the session by using the -
713
flag.
714
</p>
715
716
<p>
717
Finally, try linking your user keyring into your active session
718
keyring:
719
</p>
720
721
<pre>
722
# keyctl link @u @s
723
</pre>
724
725
<a name="nothere">
726
727
<p><h3>Q. My question isn't answered here.</h3></p>
728
729
<p>
730
Send a message to the <a
731
href="http://lists.sourceforge.net/lists/listinfo/ecryptfs-users">ecryptfs-users</a>
732
mailing list.
733
</p>
734
735
<!--
736
<p><h3>Q. </h3></p>
737
738
<p>
739
740
</p>
741
-->
742
743
</td>
744
</tr>
745
</table>
746
747
<br><br><br><br><br><br><br><br><br><br><br><br><br><br>
748
<br><br><br><br><br><br><br><br><br><br><br><br><br><br>
749
<br><br><br><br><br><br><br><br><br><br><br><br><br><br>
750
<br><br><br><br><br><br><br><br><br><br><br><br><br><br>
751
752
</body>
753
</html>
Loggerhead is a web-based interface for Breezy
Version: 2.0.1