This is the FAQ section. Most of it was written by Alan Cox.
can't register with portmap: system error on send
You are probably using a Caldera system. There is a bug in the rc scripts. Please contact Caldera to obtain a fix.
The reason is that nfsd caches open file handles for performance reasons (remember, it runs in user space). While nfsd has a file open (as is the case after writing to it), the kernel won't allow you to execute it. Nfsds newer than spring 95 release open files after a few seconds, older ones would cling to them for days.
The Linux NFS server defaults to read only. RTFM the ``exports''
and nfsd manual pages. You will need to alter /etc/exports
.
On older versions of Linux you must mount a NFS servers with
rsize=1024,wsize=1024
.
Basically don't do it then.
No, not at present.
Make sure your users are in 8 groups or less. Older servers require this.
Do not unmount NFS servers when rebooting or halting, just
ignore them, it will not hurt anything if you don't unmount them.
The command is umount -avt nonfs
.
NFS writes are normally synchronous (you can disable this if you don't mind risking losing data). Worse still BSD derived kernels tend to be unable to work in small blocks. Thus when you write 4K of data from a Linux box in the 1K packets it uses BSD does this
read 4K page
alter 1K
write 4K back to physical disk
read 4K page
alter 1K
write 4K page back to physical disk
etc..
Better systems don't have this problem. The Linux client is however quite slow anyway.
Yes, totally. Running NFS in an uncontrolled environment is rather like leaving your front door open, painting `On holiday' on your house and posting maps to every known criminal... In a fairly secure environment or when you can recover data from stupid misuse its pretty much OK. The worst someone can easily do is alter all the files on an NFS mounted disk and/or crash the machine. So long as you don't mount your system files writable you should be vaguely safe.
Because it's the only uniformly supported file sharing protocol for Unix. And because it works, mostly.
There are three main NFS behaviors on server down:
Your NFS client will report an error to the process concerned if an NFS server doesn't answer after a few retries. If you want to use this you should check that your software handles it gracefully. I would not recommend using this setting.
Your NFS client will try forever unless killed off. Operations will be restarted when the NFS server recovers or reboots.
As hard but Ctrl-C will interrupt a hung process. In a few cases - notably nfs mounted /usr/spool/mail disks this doesn't help as the shell will be ignoring Ctrl-C when it checks you have mail... I recommend this setting for all NFS mounts, including the mail spool.