Thanks - sorry for the delay responding.  I switched it to running as 
super-user and that has fixed the problem.  I'll have to investigate 
mount-broker in future.

Iain


On 5 Sep 2013, at 17:30, Venky Shankar <[email protected]> wrote:

> 'system' namespace is flipped to 'trusted' for geo-replication auxillary 
> mount. So, it should be left as 'system' in the source.
> 
> I see that you're trying to connect to the remote slave as a non-super user. 
> For that, you'd need to access the slave via mount-broker, which would 
> require some modification in the glusterd volfile.
> 
> Thanks,
> -venky
> 
> 
> On Thu, Sep 5, 2013 at 10:48 AM, Amar Tumballi <[email protected]> wrote:
> On 08/28/2013 11:15 PM, Iain Buchanan wrote:
> Hi,
> 
> I'm running GlusterFS 3.3.2 and I'm having trouble getting geo-replication to 
> work.  I think it is a problem with extended attributes.  I'll using ssh with 
> a normal user to perform the replication.
> 
> On the server log in /var/log/glusterfs/geo-replication/VOLNAME/ssh….log I'm 
> getting an error "ReceClient: call …:…:… (xtime) failed on peer with 
> OSError".  On the replication target I'm getting the same error, but with a 
> stack trace leading back to where it tries to set extended attributes in the 
> Python replication code.  It appears to be trying to get the attribute 
> "system.glusterfs.xyz.xtime" at line 365 of 
> /usr/lib/glusterfs/glusterfs/python/syncdaemon/resource.py: 
> "Xattr.lgetxattr(path, '.'.join([cls.GX_NSPACE, uuid, 'xtime')], 8))".
> I don't know anything about extended attributes, but I can't get anything in 
> the "system" namespace manually, even running as root - e.g.
>         touch a
>         getfattr -n system.test a
> 
> The above returns "Operation not supported" rather than "No such attribute".  
> The "user" and "trusted" namespace work fine - this is on ext3 with 
> user_xattr set in the mount options, and also on the server (ext4).
> Yes, 'system' is not allowed to be used by a process.
> 
> On the server side I can see files have things set in the "trusted" namespace 
> (e.g. with "getfattr -m - filename").
> 
> Should the setting of GX_NSPACE set the namespace to be "system" for non-root 
> or should it always be "trusted"? (line 248 in resource.py)  If I force it to 
> be "trusted" it seems to get further (I get occasional "Operation not 
> permitted" lines, but I think this is file permission related).
> Looks like a bug. Please change 'system' to 'user' in resource.py file, and 
> see if it works.
> 
> Regards,
> Amar
> 
> Iain
> 
> 
> _______________________________________________
> Gluster-users mailing list
> [email protected]
> http://supercolony.gluster.org/mailman/listinfo/gluster-users
> 
> _______________________________________________
> Gluster-users mailing list
> [email protected]
> http://supercolony.gluster.org/mailman/listinfo/gluster-users
> 
> _______________________________________________
> Gluster-users mailing list
> [email protected]
> http://supercolony.gluster.org/mailman/listinfo/gluster-users

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

_______________________________________________
Gluster-users mailing list
[email protected]
http://supercolony.gluster.org/mailman/listinfo/gluster-users

Reply via email to