This was a bug in NFS server kernel module. It was patched in December 2013.
Starting with kernel 3.14, rpcbind is no longer required to run in-kernel NFS server.
(assuming that server is configured to use only NFSv4 and higher)
You can find more information about that change in this ...
We really expect question-askers to have done at least a bit of homework first to be honest, anyway here we go.
NFS is a file-sharing protocol, it doesn't define anything about the underlying filesystem at all, simply the protocol of how to access files on it.
Ceph is a distributed filesystem AND sharing mechanism, it defines how the data is stored on one ...
For anyone who is looking for answers to this kind of question, the comment from Michael solved my problem.
We have direct connect to AWS and after adding the right inbound rule (TCP 2049 office subnet) to the security group, I am able to mount EFS to my local macbook.
sudo mount -t nfs -o vers=4 -o tcp -w x.x.x.x:/ efs
The kernel does a up-calls to idmapd daemon to get the mapping. As this is quite expensive operation, the results are cached. To clean the cache run:
# nfsidmap -c
The command available in RHEL6.3 ( and clones ) and part of the nfs-utils package.
Great questions, highlights a bigger point with the documentation IMO. Here is an attempt at a complete answer:
What does "subsequent exports on that line only" mean?
An example's probably easiest here:
/export/stuff -rw 10.0.0.54 10.0.0.55
is equivalent to:
/export/stuff 10.0.0.54(rw) 10.0.0.55(rw)
Is fsid=0 not required anymore?
This depends on your ...
I've found the solution:
Looking at an strace of the rpc.svcgssd daemon, I saw that the last file opened before the error ways the /etc/krb5.keytab.
The keytab on the server was generated using kadmin with a kinit of "kadmin/admin".
A kinit -k -t /etc/krb5.keytab nfs/SERVER.example.com@REALM on the SERVER resulted in a invalid password errror. So i ...
In RHEL 7, the same SELinux policies that apply to Apache also apply to nginx. So you can use the same booleans:
httpd_use_nfs (off , off) Allow httpd to use nfs
Set the correct boolean to allow the web server to use NFS.
setsebool -P httpd_use_nfs 1
You specifying the wrong module. As you want to configure nfs server, then you have to provide the option for nfsd module:
echo "options nfsd nfs4_disable_idmapping=0" > /etc/modprobe.d/nfsd.conf
Note that this should be "options nfsd" for the server module (not "options nfs").
Now we've got it working (-fstype=nfs is not needed, and probably not valid, in a map) your question betrays a misunderstanding about how automount presents to the user.
Here's an automount entry in my master file
and the corresponding map
# cat /etc/auto.master.d/mnt
helvellyn -ro,soft,intr 10.18.145.31:/var/log/...
My colleague spotted the solution in the tcpdump, that the only other difference between the good and bad connection attempts is the source port.
Then Google told me that I need the insecure option to the export, because after the forward the source port is above 1024 and in the normal case it is below 1024 and insecure tells to the server that it can ...
The best solution is of course to migrate your users to a single user database such as LDAP, FreeIPA etc. That is a little effort now but will save you a lot of grief in the future.
But you're in "luck" because as of NFS version 4 you don't need matching UID's anymore. The NFSv4 calls between client and server use names and idmapd is used translate those ...
iotop and then o - you will see which process reads and/or writes and how much to the HDD.
Check the pid of that process and do netstat -entp | grep <pid> - that way you will see established tcp connection and from which address it's coming. Use enp to check for both tcp and udp sessions.
You can also do a netstat -anp | grep 2049 - that way getting ...
Only rpc.mountd and nfsd are required to be running for NFSv4.
NFSv4 runs on TCP port 2049. The NFS server must accept incoming connections on this port. Unlike previous versions of NFS, this is the only port that is required.
About the problem
You can have a problem where two or more files have the same readdir cookie.
This problem is more common when using a NFS filesystem (v3 or v4) over an EXT4 backend and with a lot of files in the same directory (more than 50000). It problem can also occur when using GlusterFS instead of NFS.
PS: This problem can occur also with only few ...
I found the cause of this problem.
It appears that the NFS v4 ACLs take apply the user's umask.
My users had a umask of 002, so the lack of write on others was causing the 'w' 'a' 'd' and 'D' flags to be removed.
As far as I can tell this behavior is different to POSIX ACLs.
In any case the solution for me was to set the user's umask to 0.
In my case one ...
If you want to limit the amount of disk space each user (or group) is
using, then you can set up disk quotas on the NFS server (as
mentioned in another answer already). You can easily find tutorials
about how to do that. Once disk quotas are enabled, you can set the
maximum disk space each user is able to use (the default is not to
have any limit, so you ...
res_exportfs_export2_stop_0 on xx.xx.xx.1 'unknown error' (1): call=47, status=Timed Out, last-rc-change='Tue Mar 31 12:53:04 2015', queued=0ms, exec=20003ms
Shows that your res_exportfs2 resources failed to stop due to a timeout. It may simply be that it needs a longer timeout. Try configuring a stop timeout for this resource like so:
You can't create a pNFS server using stock kernels for CentOS 6.x/7.x
The pNFS server support is added in 4.0 kernel and available for block layout type only (pNFS defineds BLOCK, OBJECT and FILE layouts types). CentOS 6.x clients support FILE layout type only (7.x supports all three types).
There are two open source user space NFS servers which you can ...
It isn't really a matter of advantages or disadvantages. The access modes are very different, and it's therefore a matter of to what use you are going to put your server.
File mode is the classic mode. Your file system is handled by your server, and lots of NFS clients can use the export at the same time and attach it to their file system with a mount. They ...
My personal recommendation would be to use NIC teaming, for a number of reasons. NIC teaming/boding will allow for link redundancy and/or load balancing, depending on which options you select and your hardware/OS choices.
If you opt for a load-balanced configuration, traffic will be split across both links, effectively giving you a single, logical 2Gbps "...
There are patches for libacl to do some kind of mapping between nfs4 and Posix ACLs. They seem to be unmaintained. I've never tried it.
How I would troubleshoot this:
if ~/.emacs.d/ is provided by a NFS mount, and
the target file is a NFS mount provided by a second NFS server, and
copying all of that local to the client removes the delay,
I'd then move one of them at a time back to NFS and try to recreate the problem.
On re-reading your original post, I realize I assumed you have two ...
timeo and retrans are effective only on soft nfs not on hard nfs.
Need to change the /etc/fstab like this:
<remote-host-ip>:/path/to/origin /shared/point nfs soft,timeo=30 0 0
timeo is timeout value of 30 deciseconds (3 seconds). there is also the retrans means how much retries to do in case of error.
then in case of server or service down, an error ...
You need to mount
mount -t nfs4 192.168.1.52:/export/dir /mnt
Edit: Strike that - it's my daily NFSv3 practice shining through (and missing the crucial v4 part in the question).
Try to remove the link and bind the dir instead:
mount --bind /my/dir /exports/dir
and if it works, add the mount to /etc/fstab.
/my/dir /exports/dir ...
OK. I think I solved this. It seems that I had a "-T" in RPCNFSDCOUNT in /etc/default/nfs-kernel-server. This disables TCP which is required for NFSv4.
Removing -T and restarting nfs-kernel-server solves the problem.
The problem is that you have fsid=0 for two exported filesystems. That is the error message you're getting. fsid=0 is used to set the top of the exported filesystem tree in nfsv4. Set that only once. Typically you'd have something like this i /etc/exports on the server:
I have solved the problem. I'm posting a reply here in case someone else faces the same issue.
The solution was very simple. I needed to make sure that the cross-realm authentication principals were created with a single encoding type, of type rc4-hmac:
addprinc -e rc4-hmac krbtgt/AD.EXAMPLE.COM@EXAMPLE.COM
addprinc -e rc4-hmac krbtgt/EXAMPLE.COM@AD....
One solution to this issue is to use pam_mkhomedir to create their home directory on their first login to a system. The description in the manpage:
The pam_mkhomedir PAM module will create a users home directory if it
does not exist when the session begins. This allows users to be
present in central database (such as NIS, kerberos or LDAP) ...