On 7/10/2017 7:35 μμ, Nikolaos Milas wrote:
I am still trying to find a solution.
The problem was finally traced down to a Cisco ASA bug (this firewall
device lies between the connected networks); bug CSCuq80704 was resolved
by an ASA software update.
NFS packets were incorrectly being
On 4/10/2017 3:09 μμ, Nikolaos Milas wrote:
Problem solved - at least in my case - by changing the NFS Export
Options (of the NFS shared directory, at the data storage system) from
secure to insecure.
In the end, it occurred that the issue re-appeared after a couple of days.
So, it seems
On 2/10/2017 11:46 μμ, Nikolaos Milas wrote:
Unfortunately, it doesn't work for me.
Problem solved - at least in my case - by changing the NFS Export
Options (of the NFS shared directory, at the data storage system) from
secure to insecure. That is, I changed from:
On 2/10/2017 11:19 πμ, Patrick Begou wrote:
This config is working fior me, with just using an older kernel.
Thanks Patrick,
Unfortunately, it doesn't work for me. I tried booting with an older
kernel (3.10.0-514.21.1.el7.x86_64) and/or downgrading rpcbind to
rpcbind-0.2.0-38.el7.x86_64
This config is working fior me, with just using an older kernel.
[root@mnemosyne ~]# uname -r
3.10.0-514.21.2.el7.x86_64
[root@mnemosyne ~]# rpm -qa | grep rpcbind
rpcbind-0.2.0-42.el7.x86_64
[root@mnemosyne ~]# rpm -qa | grep nfs
libnfsidmap-0.25-17.el7.x86_64
nfs-utils-1.3.0-0.48.el7.x86_64
On 22/9/2017 8:15 μμ, Nikolaos Milas wrote:
I have created bug report: https://bugs.centos.org/view.php?id=13891
for this.
I have also created
https://bugzilla.redhat.com/show_bug.cgi?id=1494834
and I have uploaded a lot of (hopefully useful) information, but there
doesn't seem to exist
On 22/9/2017 3:46 μμ, Nikolaos Milas wrote:
Based on the facts and experience, it looks like a bug. After all, it
occurred right after upgrade to 7.4, without any system configuration
changes.
I have created bug report: https://bugs.centos.org/view.php?id=13891 for
this.
Isn't there
On 22/9/2017 2:58 μμ, Nikolaos Milas wrote:
...
or through /etc/fstab:
10.201.40.34:/data/col1/hesperia-mount /hesperiamount2 nfs
auto,noatime,nolock,bg,nfsvers=3,intr,tcp,actimeo=1800 0
Correction: the /etc/fstab nfs mount line has one more zero:
On 2/6/2017 1:46 μμ, Nikolaos Milas wrote:
After a bit of search, I found the associated reports:
https://bugs.centos.org/view.php?id=13351
https://bugzilla.redhat.com/show_bug.cgi?id=1454876
No solution yet, but -as a workaround- it seems that -at least- nfs
problems are indeed solved with
On 2/6/2017 10:58 πμ, Nikolaos Milas wrote:
Have you checked if this bug/behavior has been reported or should we
file a bug report?
After a bit of search, I found the associated reports:
https://bugs.centos.org/view.php?id=13351
https://bugzilla.redhat.com/show_bug.cgi?id=1454876
No
On 2/6/2017 10:40 πμ, Philippe BOURDEU d'AGUERRE wrote:
Reverting to rpcbind-0.2.0-38.el7 solves the problem for me
Thank you very much Philippe,
I notice that I have upgraded to rpcbind-0.2.0-38.el7_3.x86_64 on May 26.
Have you checked if this bug/behavior has been reported or should we
Le 02/06/2017 à 08:41, Nikolaos Milas a écrit :
Questions:
* Is this a known issue/bug?
I have same problem since last rpcbind package update
(rpcbind-0.2.0-38.el7_3)
* Have we possibly made any NFS misconfigurations (which however have
not caused any errors for about a year now)?
Hello,
We have a VM (under KVM - a VPS service by our ISP) running CentOS 7.
On it we have 2 NFS mounts, one for backup and one as a live file system
(where there are two user homes as well):
13 matches
Mail list logo
