diff options
| author | ebiggers <ebiggers@google.com> | 2019-07-27 19:24:19 -0700 |
|---|---|---|
| committer | Joseph Richey <joerichey@google.com> | 2019-07-27 19:24:19 -0700 |
| commit | b41569d397d3e66099cde07d8eef36b2f42dd0ec (patch) | |
| tree | 2a191031b63d0bd62f85859bae9e79b4d29349c6 /README.md | |
| parent | a4f6ff3d43f1290952780806a8c752144c16f52c (diff) | |
README.md: improve documentation for moving files into encrypted dirs (#138)
Resolves https://github.com/google/fscrypt/issues/124
Diffstat (limited to 'README.md')
| -rw-r--r-- | README.md | 26 |
1 files changed, 26 insertions, 0 deletions
@@ -631,6 +631,32 @@ debugfs -w -R "feature -encrypt" /dev/device fsck -fn /dev/device ``` +#### Getting "Operation not permitted" when moving files into an encrypted directory. + +This occurs when the kernel version is older than v5.1 and the source files are +on the same filesystem and are either unencrypted or are in a different +encrypted directory hierarchy. + +Solution: copy the files instead, e.g. with `cp`. + +`mv` works on kernels v5.1 and later, since those kernels return the correct +error code to make `mv` fall back to a copy itself. + +__HOWEVER:__ in either case, it is important to realize that the original files +may remain recoverable from free space on the disk after they are deleted. It's +much better to keep all files encrypted from the very beginning. + +As a last resort, the `shred` program may be used to try to overwrite the +original files, e.g.: + +```shell +cp file encrypted_dir/ +shred -u file +``` + +However, `shred` isn't guaranteed to be effective on all filesystems and storage +devices. + ## Legal Copyright 2017 Google Inc. under the |