of NFS server. Some peculiarities appear if you intend to run  {{Note|for information about NFS serverin client inside container, see [[VENFS]].}}

Binary RPMs that are provided Kernel-space NFS server is supported by OpenVZ community contain latest RHEL5 and RHEL6 based kernels compiledand since vzctl-3.0.24. without NFS server NB! Currently only NFSv3 is supported - no NFSv4 supportyet. Thus you have  === Prerequisites ===In order torun an NFS server inside a container, make sure:[[Kernel build|recompile the * '''nfsd kernel]] with module is loaded on host system before starting a container'''* '''nfsd feature for a container is turned on''' (<code>vzctl set $CTID --feature nfsd:on --save</code>CONFIG_NFSD) ===mSetup ===* Make sure that rpcbind service is started before nfs service:: <code>chkconfig rpcbind on && service rpcbind start</code>. After booting * Disable NFSv4 and nfsd module loading warnings in this /etc/sysconfig/nfs by uncommenting the following lines: MOUNTD_NFS_V3="yes" RPCNFSDARGS="-N 4" NFSD_MODULE="noload"* Start NFS service:: <code>chkconfig nfs on && service nfs start</code> === Troubleshooting === Make sure that:# you have enabled nfsd feature for your container# nfsd kernel module is loaded before you started the container ==== rpcbind ==== If you'll be ablesee this:<pre># service nfs start...to use Starting NFS server on services: [[HN] OK ]Starting NFS quotas: Cannot register service: RPC: Unable to receive; errno = Connection refusedrpc.rquotad: unable to register (RQUOTAPROG, RQUOTAVERS, udp).</pre> It means you haven't started rpcbind service. Solution:<pre>chkconfig rpcbind on && service rpcbind start</pre> ==== nfsd module ====If you see this:<pre># service nfs start....In-kernel Starting NFS server runs kernel threads daemon: rpc.nfsd: Unable to service requests of clientsaccess /proc/fs/nfsd errno 2 (No such file or directory).Please try, as root, 'mount -t nfsd nfsd /proc/fs/nfsd' and then restart rpc.nfsd to correct the problemBut for security reasons kernel threads are prohibited in [[VEFAILED]]s! So # mount -t nfsd nfsd /proc/fs/nfsdmount: unknown filesystem type 'nfsd'</pre> It means you wonhaven'tloaded nfsd kernel module on host before starting container. ==== warnings ==== If you see this:<pre># /etc/init.d/nfs startFATAL: Module nfsd not found.FATAL: Error running install command for nfsdbe able ...</pre> It is actually harmless, you don't need to do anything. In case you want this to run NFS server inside [[VE]] without patching go away, uncomment (or add) the kernelline   NFSD_MODULE="noload" in <code>/etc/sysconfig/nfs</code> file.

Advantage of user-space NFS server is that it can be ran without any does not require kernel support in the kernel.Also if it crashes — there is no crash of a the system: just one process crashesdies, not the kernel!The disadvantage of user-space NFS server is its productivity: no one can be faster then than in-kernel implementation.

There is a small trick you have to know about runing running <code>mountd</code> and <code>nfsd</code> (these two daemons and <code>portmap</code> constitute a user-space server). You should run them with the <code>-r</code> option:

The reason is that these daemons check the major number of the device where the directory to export resides.If major equals 0 then daemons suppose assume that it is NFS and don't want to re-export it. Symptoms arethat clients will always get a "permission denied" error. Simfs (the file system on what VE which container is located)is assosiated associated with so called unnamed device, in which major equals 0. So, to prevent daemons from checking for