search for: microdevsys

...wasn't the case either. I've also added the third brick to the Gluster FS, nfs03, trying to see if the backend FS was to blame since Gluster FS recommends 3 bricks minimum for replication, but that had no effect. In case anyone runs into this, I've added notes here as well: http://microdevsys.com/wp/kernel-nfs-nfs4_discover_server_trunking-unhandled-error-512-exiting-with-error-eio-and-mount-hangs/ http://microdevsys.com/wp/nfs-reply-xid-3844308326-reply-err-20-auth-rejected-credentials-client-should-begin-new-session/ The errors thrown included: NFS reply xid 3844308326 reply ERR 20...

On 02/25/2018 08:29 PM, TomK wrote: > Hey Guy's, > > A success story instead of a question. > > With your help, managed to get the HA component working with HAPROXY and > keepalived to build a fairly resilient NFS v4 VM cluster.? ( Used > Gluster, NFS Ganesha v2.60, HAPROXY, keepalived w/ selinux enabled ) > > If someone needs or it could help your work, please PM

On 4/11/2018 11:54 AM, Alex K wrote: Hey Guy's, Returning to this topic, after disabling the the quorum: cluster.quorum-type: none cluster.server-quorum-type: none I've ran into a number of gluster errors (see below). I'm using gluster as the backend for my NFS storage. I have gluster running on two nodes, nfs01 and nfs02. It's mounted on /n on each host. The path /n is

Hi, here is a client computer and a server computer (Debian Wheezy, armel, samba Version 3.6.6, IP address: 192.168.1.2, Name: xyz). Problem: wins doesn't answer nmblookups by the client on the broadcast address: client$ nmblookup -S xyz querying xyz on 192.168.1.255 name_query failed to find name xyz Why is that so? How to fix this? When I specify the the server IP I do get an answer: