Bind mounts

2010-04-13T10:05:24Z

Chernomor: set Category:HOWTO

Recent Linux kernels support an operation called 'bind mounting' which makes part of a mounted filesystem visible at some other mount point. See 'man mount' for more information.

Bind mounts can be used to make directories on the hardware node visible to the container.

== Filesystem layout ==
OpenVZ uses two directories. Assuming our container is numbered 777, these directories are:

* <code>VE_PRIVATE</code>: $VZDIR/private/777
* <code>VE_ROOT</code>: $VZDIR/root/777

{{Note|<code>$VZDIR</code> is usually <code>/vz</code>, on Debian systems however this is <code>/var/lib/vz</code>. In this document this is further referred to as <code>$VZDIR</code> -- substitute it with what you have.}}

<code>VE_PRIVATE</code> is a place for all the container files. <code>VE_ROOT</code> is the mount point to which <code>VE_PRIVATE</code> is mounted during container start (or when you run <code>vzctl mount</code>

{{Warning|If you want to do a bind mount for container, you need to '''use <code>VE_ROOT</code>''' (not <code>VE_PRIVATE</code>!) and '''make sure that container is mounted''' (this can be checked using <code>vzctl status</code>).}}

== Manual mount example ==

On the HN we have a directory <code>/home</code> which we wish to make available (shared) to container 777.

The correct command to issue on the HN is:

mount --bind /home $VZDIR/root/777/home

The container must be started (or at least mounted) and the destination directory must exist. The container will see this directory mounted like this:

# df
Filesystem 1K-blocks Used Available Use% Mounted on
simfs 10485760 298728 10187032 3% /
ext3 117662052 104510764 7174408 94% /home

During the container stop vzctl unmounts that bind mount, so you have to mount it again when you start the container for the next time. Luckily there is a way to automate it.

== Make the mount persistent ==

Put a mount script in OpenVZ configuration directory (<code>/etc/vz/conf/</code>) with the name <code>''CTID''.mount</code> (where <code>''CTID''</code> is container ID, like 777). This script will be executed every time you run <code>vzctl mount</code> or <code>vzctl start</code> for a particular container. If you need to the same for all containers, use the global mount script named <code>vps.mount</code>.

From any mount script you can use the following environment variables:
* <code>${VEID}</code> -- container ID (like <code>777</code>).
* <code>${VE_CONFFILE}</code> -- container configuration file (like <code>/etc/vz/conf/777.conf</code>)

Now, in order to get the value of <code>VE_ROOT</code> you need to source both the global OpenVZ configuration file, and then the container configuration file, in that particular order. This is the same way vzctl uses to determine <code>VE_ROOT</code>.

=== Mount script example ===
Here is an example of such a mount script (it can either be <code>/etc/vz/conf/vps.mount</code> or <code>/etc/vz/conf/''CTID''.mount</code>)
#!/bin/bash
source /etc/vz/vz.conf
source ${VE_CONFFILE}
mount --bind /mnt/disk ${VE_ROOT}/mnt/disk

=== Unmount script example ===
For unmounting a filesystem, <code>/etc/vz/conf/vps.umount</code> or <code>/etc/vz/conf/''CTID''.umount</code> script can be used in the same way:

#!/bin/bash
source /etc/vz/vz.conf
source ${VE_CONFFILE}
umount ${VE_ROOT}/mnt/disk

{{Note|<code>''CTID''.umount</code> script is not strictly required, since vzctl tries to unmount everything on CT stop. But you'd better have it anyway.}}

== Read-only bind mounts ==

Since Linux kernel 2.6.26, bind mounts can be made read-only. The trick is to first mount as usual, and then remount it read-only:

mount --bind /home $VZDIR/root/777/home
mount --bind -oremount,ro $VZDIR/root/777/home

== See also ==
* [[NFS]]
* [[FUSE]]
* [[Mounting filesystems]]

[[Category:HOWTO]]

NFS server inside container

2009-04-24T08:18:38Z

Chernomor: Notes about nfs-user-server and busybox.

There are two ways to setup NFS server on common [[HN]]:
use a user-space NFS server daemon or use an in-kernel implementation
of NFS server. Some peculiarities appear if you intend to run NFS server
in [[container]].

{{Note|for information about NFS client inside container, see [[NFS]].}}

== Kernel NFS server ==
Binary RPMs that are provided by OpenVZ community contain kernels compiled
without NFS server support. Thus you have to
[[Kernel build|recompile the kernel]] with <code>CONFIG_NFSD=m</code>. After booting in this kernel you'll be able
to use NFS server on [[HN]].
In-kernel NFS server runs kernel threads to service requests of clients.
But for security reasons kernel threads are prohibited in [[container]]s! So you won't
be able to run NFS server inside [[container]] without patching the kernel.

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

One well-known implementation of NFS server is "The LINUX User-Space NFS Server" by Olaf Kirch.
Some Linux distributions contain this package: Debian Sarge (<code>nfs-user-server</code>), OpenSUSE 10.0 (<code>nfs-server</code>).
For other distributions you can download sources (for example from Debian repository) and compile it.
There is a small trick you have to know about 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:
<pre>
# portmap
# rpc.mountd -r
# rpc.nfsd -r
</pre>
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 assume that it is NFS and don't want to re-export it. Symptoms are
that clients will always get a "permission denied" error. Simfs (the file system on which container is located)
is associated with so called unnamed device, in which major equals 0. So, to prevent daemons from checking for
re-exporting — just use this <code>-r</code> option.

“The LINUX User-Space NFS Server” by Olaf Kirch implements NFSv2. It means that only files with sizes less
than 2GB are processed. If you intend to use such big files then you should use another user-space NFS server
implementation: [http://unfs3.sourceforge.net/ unfs3]. It implements v3 of NFS protocol standard.

Please note that the user-space NFS server does not provide locking, or at least I couldn't get locking to work - [[User:Elronxenu|Elronxenu]] 19:49, 15 November 2007 (EST)

=== On Debian Lenny ===

The current stable debian version 5.0 (lenny) provides two packages for user space nfs support: <code>nfs-user-server</code> and <code>unfs3</code>. Here i describe my experiences with them --[[User:Strimo|Strimo]] 17:47, 16 February 2009 (UTC)

==== nfs-user-server ====

<pre>
aptitude install nfs-user-server
</pre>

First i used nfs-user-server package since i didn't know unfs3. After installing i always got the '''permission denied''' error when i tried to mount any exported path until i found this article. So i patched the /etc/init.d/nfs-user-server file to include the <code>-r</code> parameter by adding <code>-- -r</code> to the <code>start-stop-daemon</code> line responsible for starting <code>rpc.mountd</code> and <code>rpc.nfsd</code>:

<pre>
start-stop-daemon --start --oknodo --quiet --exec /usr/sbin/rpc.nfsd -- -r
start-stop-daemon --start --oknodo --quiet --exec /usr/sbin/rpc.mountd -- -r
</pre>

After the modification and a nfs server restart (<code>/etc/init.d/nfs-user-server restart</code>) i was able to mount a nfs share. At first the nfs server seems to work fine but anytime i want to edit any text file (using nano or mcedit) i got strange errors on writing to the file and i never solved the problem nor detected why this happens. So i switched to unfs3 ...

<b>Note</b>: nfsmount from busybox not works with nfs-user-server in Debian Lenny, it write message "rpc failed: 2" when I try boot from nfs server. unfs3 works fine.
Such problem into Ubuntu: https://bugs.launchpad.net/ubuntu/+source/nfs-user-server/+bug/189593

==== unfs3 ====

<pre>
aptitude install unfs3
</pre>

Works fine until now. Note that both unfs3 and nfs-user-server do not support file locking!

== External links ==
* [http://nfs.sourceforge.net/ Linux NFS Overview, FAQ and HOWTO Documents]
* [http://www.tldp.org/LDP/nag/nag.html The Network Administrators' Guide by Olaf Kirch]
* [http://unfs3.sourceforge.net/ unfs3 homepage]
* [http://packages.qa.debian.org/n/nfs-user-server.html Overview of nfs-user-server source package]

[[Category: HOWTO]]
[[Category: Networking]]

OpenVZ Virtuozzo Containers Wiki - User contributions [en]

Bind mounts

NFS server inside container