[Gluster-users] Problems with eCryptfs using a Gluster backend.

[Lance Reed]

I forgot to include the versions of the code I am using:
fuse-2.8.3-4.el6.x86_64
glusterfs-libs-3.4.2-1.el6.x86_64
glusterfs-server-3.4.2-1.el6.x86_64
glusterfs-3.4.2-1.el6.x86_64
glusterfs-fuse-3.4.2-1.el6.x86_64
fuse-libs-2.8.3-4.el6.x86_64
glusterfs-cli-3.4.2-1.el6.x86_64


Thanks in advance for any ideas on the subject.


On Tue, Feb 25, 2014 at 6:15 PM, Lance Reed <reed.r.lance at gmail.com> wrote:

> I am attempting to setup encrypted user home directories via eCryptfs
> using gluster as a backend.
>
> Very simple setup currently has a small two node gluster cluster mounted
> by a separate client.  Normal gluster client and NFS mount / file options
> are working fine.
>
>
> e.g.
> https://wiki.archlinux.org/index.php/ECryptfs#Encrypting_a_home_directory
>
> In my attempts lay ecryptfs on top of the mounted native gluster setup, I
> am unable to edit a file, write etc.  I either get zero length or fixed
> sizes.
>
> Only log messages I get are:
> "Either the lower file is not in a valid eCryptfs format, or the key could
> not be retrieved. Plaintext passthrough mode is not enabled; returning -EIO"
>
> I am posting in this forum to see if anyone knows of any reason why this
> may be failing from the Glusterfs side.
>
> I am trying Centos / RHEL.
> See these bugs:
> Bug 762976 - (GLUSTER-1244) ecryptfs does not work when the directory to
> be encrypted is on gluster mount
> https://bugzilla.redhat.com/show_bug.cgi?id=762976
>
> A non-empty file created on glusterfs with ecryptfs reports as a file of
> size zero
> https://bugzilla.redhat.com/show_bug.cgi?id=989702#c1
>
> These look to be issues with O_DIRECT usage in fuse.
> I was hoping someone might have an idea or remember some of this to help
> me figure out if using glusterfs for a backend with  eCryptfs is even an
> option.
>
> Is it possible that this bug is still the core problem?
> "ecryptfs does not work properly over nfs, cifs, samba, WebDAV, or aufs"
> https://bugs.launchpad.net/ecryptfs/+bug/277578
> It is old but still seems to be open..
>
> Thanks very much in advance for any ideas on the problem.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-users/attachments/20140226/e489513f/attachment.html>