[Bug 1305335] Re: Cutting or copying files on btrfs to ecryptfs results in data loss
** No longer affects: nautilus (Ubuntu) ** Tags added: kernel-fs ** Changed in: linux (Ubuntu) Status: Confirmed = Triaged -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to nautilus in Ubuntu. https://bugs.launchpad.net/bugs/1305335 Title: Cutting or copying files on btrfs to ecryptfs results in data loss To manage notifications about this bug go to: https://bugs.launchpad.net/ecryptfs/+bug/1305335/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 1305335] Re: Cutting or copying files on btrfs to ecryptfs results in data loss
As a follow-up to comment #16: generally attempting to clone a file in
a non-ecryptfs folder into a mounted ecryptfs folder appears to succeed
but in fact creates a zero-length invalid target file, but going the
other way (cloning from the mounted ecryptfs folder into the non-
ecryptfs folder) fails as it should. (Both cp --reflink=auto and glib's
file_copy_fallback try a clone operation and then try a non-clone
operation if this fails, so this second case is fine.)
The attached script demonstrates both cases by creating a mounted
ecryptfs system in /tmp/ecryptfs-test and using the folder 'private' to
hold the 'lower' encrypted ecryptfs files and the folder 'plaintext' as
the 'higher' mounted ecryptfs folder and then trying the clone operation
in both directions. ( /tmp must be on a btrfs partition and you need at
least ecryptfs-utils installed but you don't need an encrypted home
folder.)
The btrfs_ioctl_clone command (in fs/btrfs/ioctl.c in the kernel source)
is designed to only perform a clone if the source and dest files have
the same VFS mountpoint and to fail with EXDEV (invalid cross-device
link) if they don't:
ret = -EXDEV;
if (src_file.file-f_path.mnt != file-f_path.mnt)
goto out_fput;
When trying to clone from the 'plaintext' folder into /tmp/ecryptfs-
test, this test fails (the mountpoints are represented by two different
dentries, '@' and '/').
However, when cloning into the 'plaintext' folder, btrfs_ioctl_clone is
actually being asked to clone using the 'lower' ecryptfs file as the
target (ie the target points to the 'private' folder, not the
'plaintext' folder), so the test passes. This is obviously wrong -
ecryptfs is designed so that the information gets directed to the
'plaintext' folder, intercepted in the kernel, and stored encrypted
instead in the 'private' folder.
To demonstrate this, I added this code just before the test:
{
#define BUFLEN 256
char src_path[BUFLEN],dest_path[BUFLEN];
int i;
for (i=0;iBUFLEN;++i) src_path[i]=dest_path[i]=0;
printk(KERN_INFO btrfs reflink src: %s [mnt %s], dest: %s [mnt %s]\n,
dentry_path_raw(src_file.file-f_path.dentry, src_path, BUFLEN),
src_file.file-f_path.mnt-mnt_root-d_iname,
dentry_path_raw(file-f_path.dentry, dest_path, BUFLEN),
file-f_path.mnt-mnt_root-d_iname
);
}
With that code included in the kernel, the syslog shows something like
this after running the attached test script:
... btrfs reflink src: /@/tmp/ecryptfs-test/test [mnt @], dest: /@/tmp
/ecryptfs-test/private/ECRYPTFS_FNEK_ENCRYPTED... [mnt @]
ie the target file passed to btrfs_ioctl_clone is the 'lower' file in
'private'. (Note that after the clone, trying to access this file
results in an I/O error.)
I checked the cp code, and it calls:
return ioctl (dest_fd, BTRFS_IOC_CLONE, src_fd);
I used readlink to get the file path for dest_fd from
/proc/self/fd/file desriptor, and it returned /tmp/ecryptfs-
test/plaintext/test, so desc_fd in the cp command is pointing to the
correct path for the 'higher' file.
My guess is that ecryptfs intercepts this 'higher' path and converts it
to the 'lower' path before it gets passed through to btrfs, but it
should just do a pass-through for the btrfs clone operation.
** Attachment added: Script demonstrating the bug
https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1305335/+attachment/4325528/+files/test-reflink.sh
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to nautilus in Ubuntu.
https://bugs.launchpad.net/bugs/1305335
Title:
Cutting or copying files on btrfs to ecryptfs results in data loss
To manage notifications about this bug go to:
https://bugs.launchpad.net/ecryptfs/+bug/1305335/+subscriptions
--
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 1305335] Re: Cutting or copying files on btrfs to ecryptfs results in data loss
In case anyone still reads bugzilla.kernel.org, I reported this at https://bugzilla.kernel.org/show_bug.cgi?id=93691. ** Bug watch added: Linux Kernel Bug Tracker #93691 http://bugzilla.kernel.org/show_bug.cgi?id=93691 -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to nautilus in Ubuntu. https://bugs.launchpad.net/bugs/1305335 Title: Cutting or copying files on btrfs to ecryptfs results in data loss To manage notifications about this bug go to: https://bugs.launchpad.net/ecryptfs/+bug/1305335/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 1305335] Re: Cutting or copying files on btrfs to ecryptfs results in data loss
@whoop: If you mean that the thumbnail file length is correct but the image file is zero bytes, the reason is that the thumbnail file isn't copied from the non-ecryptfs folder to the ecryptfs folder. Instead, the system stores thumbnails in ~/.cache/thumbnails. So it creates a new thumbnail file for the newly-copied zero-byte image file in the ecryptfs folder, meaning the thumbnail file itself is valid. But the system tries to generate the thumbnail image from the zero-byte image file, which means that the thumbnail image is broken and so it appears broken in nautilus. -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to nautilus in Ubuntu. https://bugs.launchpad.net/bugs/1305335 Title: Cutting or copying files on btrfs to ecryptfs results in data loss To manage notifications about this bug go to: https://bugs.launchpad.net/ecryptfs/+bug/1305335/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 1305335] Re: Cutting or copying files on btrfs to ecryptfs results in data loss
@Rocko: Do you have an explanation on why the thumbnail gets broken when I cp a jpg to the ecryptfs folder? The number of bytes are correct... -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to nautilus in Ubuntu. https://bugs.launchpad.net/bugs/1305335 Title: Cutting or copying files on btrfs to ecryptfs results in data loss To manage notifications about this bug go to: https://bugs.launchpad.net/ecryptfs/+bug/1305335/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 1305335] Re: Cutting or copying files on btrfs to ecryptfs results in data loss
I still have a running system with this issue. It is not an ubuntu box but Arch 64. This is a fresh install. I stole the disk layout from the ubuntu documentation for this system: one btrfs partition with @ subvolume for / and @home subvolume for /home. The system also uses a vfat ESP as it is an UEFI install. Default kernel: currently 3.18.6-1-ARCH I installed ecryptfs-utils (ecryptfs-utils 104-1) from the arch repo and did the following as configuration: https://wiki.archlinux.org/index.php/ECryptfs#Without_ecryptfs-utils The described setup above is currently working on an ext4 arch 64 bit system but not on btrfs system... A copy or move with nautilus to Private folder results in file(s) with 0 bytes (on all file formats I have tested). A cp or mv to Private folder results in proper amount of bytes but something is also wrong as thumbnails for jpg are not showing in Private folder with nautilus although thumbnails are enabled. So maybe header is getting corrupted or something. I also tested avi and tga but these did give me thumbnails. I have not tested other file formats at this time. -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to nautilus in Ubuntu. https://bugs.launchpad.net/bugs/1305335 Title: Cutting or copying files on btrfs to ecryptfs results in data loss To manage notifications about this bug go to: https://bugs.launchpad.net/ecryptfs/+bug/1305335/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 1305335] Re: Cutting or copying files on btrfs to ecryptfs results in data loss
The 3.19 kernel still has the problem. You can reproduce it by copying a test file from say /home into an encrypted home directory using --reflink: echo test /home/test cp --reflink=always /home/test ~ ls -l ~/test # This shows 0 bytes This command, however, copies the file correctly, assuming you haven't aliased cp to use reflink: echo test /home/test cp /home/test ~ ls -l ~/test # This shows 5 bytes nautilus is using the g_local_file_copy library command in glib, which since automatically applies reflink since 2.36.4 (libglib2.0-bin is at 2.43.4-1 in Vivid). See the comment at http://upstream.rosalinux.ru/changelogs/glib/2.36.4/changelog.html, where it lists Btrfs clone/reflink ioctl support in g_local_file_copy as one of the changes. So one solution would seem to be to modify the copy functionality to disable reflink (or disallow the copy) if it detects it is copying into a mounted ecryptfs directory (eg using /proc/mounts) from a directory that is not in the same mount. Presumably ecryptfs intercepts the copy request, so perhaps the check should be done in ecryptfs? -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to nautilus in Ubuntu. https://bugs.launchpad.net/bugs/1305335 Title: Cutting or copying files on btrfs to ecryptfs results in data loss To manage notifications about this bug go to: https://bugs.launchpad.net/ecryptfs/+bug/1305335/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 1305335] Re: Cutting or copying files on btrfs to ecryptfs results in data loss
Just to note: in the example commands above, of course, /home needs to be write-accessible to the current user, or you need to use a command like su root -c echo test /home/test. -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to nautilus in Ubuntu. https://bugs.launchpad.net/bugs/1305335 Title: Cutting or copying files on btrfs to ecryptfs results in data loss To manage notifications about this bug go to: https://bugs.launchpad.net/ecryptfs/+bug/1305335/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 1305335] Re: Cutting or copying files on btrfs to ecryptfs results in data loss
** Tags added: kernel-bug-exists-upstream -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to nautilus in Ubuntu. https://bugs.launchpad.net/bugs/1305335 Title: Cutting or copying files on btrfs to ecryptfs results in data loss To manage notifications about this bug go to: https://bugs.launchpad.net/ecryptfs/+bug/1305335/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 1305335] Re: Cutting or copying files on btrfs to ecryptfs results in data loss
Also, just to confirm, this issue only happens if you copy the files using Nautilus? It does not happen if you copy from a terminal? -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to nautilus in Ubuntu. https://bugs.launchpad.net/bugs/1305335 Title: Cutting or copying files on btrfs to ecryptfs results in data loss To manage notifications about this bug go to: https://bugs.launchpad.net/ecryptfs/+bug/1305335/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 1305335] Re: Cutting or copying files on btrfs to ecryptfs results in data loss
Did this issue start happening after an update/upgrade? Was there a prior kernel version where you were not having this particular problem? Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v3.19 kernel[0]. If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'. If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'. If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream'. Once testing of the upstream kernel is complete, please mark this bug as Confirmed. Thanks in advance. [0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.19-vivid/ ** Tags added: kernel-key ** Changed in: linux (Ubuntu) Importance: Undecided = High ** Changed in: linux (Ubuntu) Importance: High = Critical -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to nautilus in Ubuntu. https://bugs.launchpad.net/bugs/1305335 Title: Cutting or copying files on btrfs to ecryptfs results in data loss To manage notifications about this bug go to: https://bugs.launchpad.net/ecryptfs/+bug/1305335/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 1305335] Re: Cutting or copying files on btrfs to ecryptfs results in data loss
Hi Joseph, This bug freaked me out so much I re-formatted to EXT4 and started over. I don't have a system that I can test this on now. The bug appeared on a completely fresh install of 14.04 beta 2 and the bug was still present in the release. Unfortunately, I never had any experience with BTRFS prior so I can't tell you how it worked before. As I recall, I had success doing copies via the terminal command line using CP -R, so I assumed the bug was in how nautilus handled file copies. My experience also was that once I got a file INTO the private directory, I was able to open, edit, and save correctly without error. Still, the whole thing sent shivers up my spine, and I'm not as technically-abled as others on this bug. I had to dump BTRFS as soon as I could. -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to nautilus in Ubuntu. https://bugs.launchpad.net/bugs/1305335 Title: Cutting or copying files on btrfs to ecryptfs results in data loss To manage notifications about this bug go to: https://bugs.launchpad.net/ecryptfs/+bug/1305335/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 1305335] Re: Cutting or copying files on btrfs to ecryptfs results in data loss
** Package changed: linux-meta (Ubuntu) = linux (Ubuntu) ** Changed in: linux (Ubuntu) Status: New = Confirmed -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to nautilus in Ubuntu. https://bugs.launchpad.net/bugs/1305335 Title: Cutting or copying files on btrfs to ecryptfs results in data loss To manage notifications about this bug go to: https://bugs.launchpad.net/ecryptfs/+bug/1305335/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 1305335] Re: Cutting or copying files on btrfs to ecryptfs results in data loss
Status changed to 'Confirmed' because the bug affects multiple users. ** Changed in: linux (Ubuntu) Status: New = Confirmed -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to nautilus in Ubuntu. https://bugs.launchpad.net/bugs/1305335 Title: Cutting or copying files on btrfs to ecryptfs results in data loss To manage notifications about this bug go to: https://bugs.launchpad.net/ecryptfs/+bug/1305335/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 1305335] Re: Cutting or copying files on btrfs to ecryptfs results in data loss
** Also affects: linux-meta (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to nautilus in Ubuntu. https://bugs.launchpad.net/bugs/1305335 Title: Cutting or copying files on btrfs to ecryptfs results in data loss To manage notifications about this bug go to: https://bugs.launchpad.net/ecryptfs/+bug/1305335/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
