Displaying 4 results from an estimated 4 matches for "microdevsi".
Did you mean:
microdevsys
2018 May 22
1
[SOLVED] [Nfs-ganesha-support] volume start: gv01: failed: Quorum not met. Volume operation not allowed.
Hey All,
Appears I solved this one and NFS mounts now work on all my clients. No
issues since fixing it a few hours back.
RESOLUTION
Auditd is to blame for the trouble. Noticed this in the logs on 2 of
the 3 NFS servers (nfs01, nfs02, nfs03):
type=AVC msg=audit(1526965320.850:4094): avc: denied { write } for
pid=8714 comm="ganesha.nfsd" name="nfs_0"
2018 Feb 26
1
NFS Ganesha HA w/ GlusterFS
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
2018 May 08
1
volume start: gv01: failed: Quorum not met. Volume operation not allowed.
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
2012 Oct 14
5
wins: no nmblookup on 192.168.1.255 but 192.168.1.2
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: