On 03/09/2012 09:53 PM, WALKER RICHARD wrote:
"You didn't answer my question about whether or not Smoothwall always
assigns the same IP to the server box. This is important since if it
doesn't then every time the server restarts the network interface you
are taking a chance it will get assigned a different IP and break the
client fstab entries."
Sorry, that was in the first reply which disappeared in a flash of
accidentally highlighted text. I have taken no particular steps to
influence Smoothwall's DHCP address allocation other than to limit the
dynamic addresses to the range from 100 to 127. By observation, over
the last ten years or so, the same interfaces tend to get the same
addresses, though it may also depend on which machine hosts the boot
disc I am preparing. The maximum lease time is 2 hours, but I doubt if
that has much to do with it. Maybe I'm just lucky; I cannot remember
the last time I noticed an address change.
I don't use dhcp except for wireless but I think most dhcp implentations
generally use the same IPs over again, you just can't rely on it. Static
IPs also allow for specialized firewall and routing configurations, but
if it works and you're happy with the configuration I wouldn't worry
about it.
"Has this configuration ever worked correctly? The exports file looks
fine but IIRC the fstab entry should match the exports file path, i.e.
it should be: 192.168.0.101:/home/richmag/Videos /mnt/Videos ...."
Sorry again, perhaps I should have made these entries look "more
normal". Because the boot disc which provided the MGA1 and 2010.2
environments on this box has been used for a lot of testing of
upgrades and 32/64 bit environments I use a system of hidden home
directories and boot-time generated symlinks to match my home
directories to my current user name. In recent times I have noticed
that applications may sometimes unexpectedly use the real directory
name and sometimes as expected the name of the symlink. I have long
since stopped worrying about how to fix this "problem"; it looks
stupid but it still works.
It is a bit unusual but I don't think this is your problem, and again,
if it ain't broken...
So the answer is yes, this always works as expected. I have only been
able to make if fail reliably (:-) in Mageia 1 with an unmodified port
parameter for rpc.mountd. As noted above I have also completed a test
under Mageia 2 (using a different boot disc on the same box) and it
works perfectly - no need to hack /etc/sysconfig/nfs-server.
I'm off to bed now - long journey in the morning. Here is the report
from the MGA2 system which is working just fine. I'll try to get the
same info for the broken MGA1 setup tomorrow.
[root@Tureen rich]# systemctl status nfs-server.service
nfs-server.service - LSB: Kernel NFS server support
Loaded: loaded (/etc/rc.d/init.d/nfs-server)
Active: active (running) since Sat, 10 Mar 2012 02:43:32 +0000; 4min
52s ago
Process: 1540 ExecStart=/etc/rc.d/init.d/nfs-server start
(code=exited, status=0/SUCCESS)
CGroup: name=systemd:/system/nfs-server.service
└ 1645 rpc.mountd --port 4003
You mentioned in an earlier post that the mga1 box worked once after you
commented out the RPCMOUNTD_OPTIONS="--port 4003" option in
/etc/sysconfig/nfs-server. I just checked the mga1 test server I set up
yesterday and this option isn't set at all. Is it possible you are
mixing files from different Mandriva/Mageia versions? Perhaps try
un-installing nfs-utils and deleting all it's config files and start
again with a clean package install.
