SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
I recently upgraded my laptop to Slackware64-current. I have multiple NFS shares that I used to be able to mount when I was running 14.1.
I have rc.rpc and rc.nfsd set to executable, but when I try to restart rc.rpc it takes 3-4 minutes to return to the prompt and returns an exit code of 1.
My /etc/fstab:
In an effort to figure out what was wrong, I did remove the aaa_elflibs from /etc/slackpkg/blacklist and subsequently ran slackpkg install-new && slackpkg upgrade-all && slackpkg clean-system.
Before I did that, /sbin/rpc.statd wouldn't actually start with an exit code of 130, but since I made the change and rebooted, it will start and run but it won't let me mount the share.
I can also use the -o nolock option to bypass statd, but that isn't optimal for me.
You restart nfsd on the server? What do server logs say?
Just as I thought, restarting nfs server side accomplished nothing.
I only get a successful mount message when I use the -o nolock,ro options from the -current machine
I can mount/remount all my shares from the 14.1 machines without problems.
Just as I thought, restarting nfs server side accomplished nothing.
I only get a successful mount message when I use the -o nolock,ro options from the -current machine
I can mount/remount all my shares from the 14.1 machines without problems.
Oct 1 20:56:15 alain rpc.statd[599]: Version 1.3.1 starting
Oct 1 20:56:15 alain sm-notify[600]: Version 1.3.1 starting
Oct 1 20:56:15 alain sm-notify[600]: Already notifying clients; Exiting!
gezley,
Here is some output I collected by running "nstat -npl | grep rpc"
It's hard to know what's wrong. Is the NFS server running Slackware? There was an update to nfs-utils on -current earlier this year. Perhaps there is a mismatch with NFS on an older Slackware?
Do you have iptables running on the server, perhaps allowing only a limited range within the DHCP scope? The fact that it works when nolock is specified suggests not but it doesn't hurt to clear these things up first.
It's hard to know what's wrong. Is the NFS server running Slackware? There was an update to nfs-utils on -current earlier this year. Perhaps there is a mismatch with NFS on an older Slackware?
Do you have iptables running on the server, perhaps allowing only a limited range within the DHCP scope? The fact that it works when nolock is specified suggests not but it doesn't hurt to clear these things up first.
Yes, the NFS server is running Slackware64-14.1. The mismatch concern came to my mind as well, but if that's the case, it will force me to upgrade everything to 14.? at the same time.
I do not have iptables running (I know, but I'm still learning).
I'm not intimately familiar with what exactly each rpc process does, but according to the rc.rpc script, the -nolock option is for cases where statd either doesn't work or you are OK with mounting the shares read-only. Please correct me if I'm wrong.
I've just noticed this path - /usr/sbin/exportfs. I assume it's just a typo? You export your shares in /etc/exports .
Might be worth looking at the Slackware docs page just to make sure you have everything right. I haven't done it too often but whenever I have set up NFS on Slackware it's been straightforward with these instructions.
Another thing to check is the kernel config on both server and current:
Code:
grep NFS /boot/config > ~/server-nfs # do this on server
grep NFS /boot/config > ~/current-nfs # do this on current
diff server-nfs current-nfs # now copy both files to current directory and diff
The /usr/sbin/exportfs was just a way for me to show what is being exported by the server. I do have /etc/exports setup (and usable by every other machine on my network, with exception to the -current build).
I will check the kernel configs when I get home, thanks for the additional guidance!
The /usr/sbin/exportfs was just a way for me to show what is being exported by the server.
Sorry, I was on autopilot there!
Quote:
I do have /etc/exports setup (and usable by every other machine on my network, with exception to the -current build).
Yes I do bear that in mind. A couple more things to consider:
a) what happens if you comment out the NFS mount in fstab and mount it manually? If it works, perhaps the network is coming up too late for the fstab entry.
b) If you set up a temporary NFS share on the -current machine can the 14.1 clients connect to it without this trouble?
a) what happens if you comment out the NFS mount in fstab and mount it manually? If it works, perhaps the network is coming up too late for the fstab entry.
b) If you set up a temporary NFS share on the -current machine can the 14.1 clients connect to it without this trouble?
A) I have attempted to mount manually with no result and very little feedback from the system.
Code:
sudo mount -v -t nfs eddie:/home/izzle121/.common /home/izzle121/.common/
mount.nfs: timeout set for Sat Oct 3 21:45:58 2015
mount.nfs: rpc.statd is not running but is required for remote locking.
mount.nfs: Either use '-o nolock' to keep locks local, or start statd.
mount.nfs: an incorrect mount option was specified
sudo mount -v -t nfs -o nolock,ro eddie:/home/jared/.common /home/jared/.common/
mount.nfs: timeout set for Sat Oct 3 21:49:39 2015
mount.nfs: trying text-based options 'nolock,addr=192.168.1.103'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: trying 192.168.1.103 prog 100003 vers 3 prot TCP port 2049
mount.nfs: prog 100005, trying vers=3, prot=17
mount.nfs: trying 192.168.1.103 prog 100005 vers 3 prot UDP port 34619
eddie:/home/jared/.common on /home/jared/.common type nfs (ro,nolock)
Now the state of the -current machine:
Code:
ps axc|grep rpc.statd
No feedback, statd only runs briefly after restarting rc.rpc, then dies. I've attempted to run "/usr/sbin/rpc.statd -d" manually and seen no success/failure feedback
When I export a file from the -current machine and attempt to mount it from a 14.1 machine:
Code:
sudo mount -v -t nfs alain:/export /mnt/tmp
Password:
mount.nfs: timeout set for Sat Oct 3 21:52:30 2015
mount.nfs: trying text-based options 'addr=192.168.1.107'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: portmap query retrying: RPC: Program not registered
mount.nfs: prog 100003, trying vers=3, prot=17
mount.nfs: portmap query failed: RPC: Program not registered
mount.nfs: requested NFS version or transport protocol is not supported
I was thinking it might be a problem with nfs-utils, so I attempted to rollback to version 1.2.8 with the same result. I'm suspicious now that some dependency is broken on my system, but I'm unsure what exactly the dependencies for nfs-utils would be, or how to find it.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
