All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sukadev Bhattiprolu <sukadev-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
To: nfs-ganesha-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Cc: Containers
	<containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>,
	sukadev-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org
Subject: nfs-ganesha with Linux containers
Date: Tue, 12 Feb 2013 23:47:47 -0800	[thread overview]
Message-ID: <20130213074747.GA19635@us.ibm.com> (raw)



I have nfs-ganesha [1.5.1] with FSAL_VFS running on Linux 3.7.0-rc8 on
an x86_64 RHEL6.2 system (the "host"). I can export the filesystems and
mount from another system.

I am trying to use nfs-Ganesha from within a Linux container on the same
system.

My container setup:

	On the REHL6.2 host, I have a directory, /export/vm1-root.

	The root of my linux container is bind mounted to that directory 
	So a file '/export/vm1-root/foobar' is known to the container as
	'/foobar' and other files/directories in '/export' are not visible
	from the container.

	[ie it is as if the processes inside the containers have run 'chroot'
	into /export/vm1-root and can't escape out of this]. 

I am now trying to export a directory, '/vm1gfs0' from within the container
to the external world. (on the host, this directory is /export/vm1-root/vm1gfs).

I have nfs-ganesha* rpms installed and /etc/ganesha/vfs.ganesha.exports.conf
properly configured to export '/vm1gfs0' from within the container. 

When I try to start the vfs-ganesha service from within the container:

	$ /etc/init.d/nfs-ganesha-vfs start

I get the following errors in the log file:


------
12/02/2013 15:01:20 epoch=1360710080 : elm3a241-vm1 : vfs.ganesha.nfsd-1015[main
] :COMMON_InitClientContext :FSAL: FULLDEBUG: FSAL_InitClientContext returns (ER
R_FSAL_NO_ERROR, No error, 0)
12/02/2013 15:01:20 epoch=1360710080 : elm3a241-vm1 : vfs.ganesha.nfsd-1015[main
] :VFSFSAL_BuildExportContext :FSAL: CRITICAL ERROR: No mount entry matches '/ex
port/vm1gfs0' in /etc/mtab
12/02/2013 15:01:20 epoch=1360710080 : elm3a241-vm1 : vfs.ganesha.nfsd-1015[main
] :VFSFSAL_BuildExportContext :FSAL: DEBUG: FSAL_BuildExportContext returns (ERR
_FSAL_NOENT, No such file or directory, 0)
12/02/2013 15:01:20 epoch=1360710080 : elm3a241-vm1 : vfs.ganesha.nfsd-1015[main
] :nfs_export_create_root_entry :NFS STARTUP: CRITICAL ERROR: Couldn't build exp
ort context for /vm1gfs0
12/02/2013 15:01:20 epoch=1360710080 : elm3a241-vm1 : vfs.ganesha.nfsd-1015[main
] :nfs_Init :NFS STARTUP: FATAL ERROR: Error initializing Cache Inode root entri
es

--------

Inside the linux container, there is no entry in /etc/mtab for the
container's root filesystem. 

Is nfs-Ganesha trying to find the path all the way back to the root of the 
filesystem (which the linux container is unable to get to) ?

Faking an mtab entry with:

	$ mount -o bind / /

gives a slightly different error:

---------

12/02/2013 15:42:05 epoch=1360712525 : elm3a241-vm1 : vfs.ganesha.nfsd-1113[main
] :COMMON_GetClientContext :FSAL: FULLDEBUG: FSAL_GetClientContext returns (ERR_
FSAL_NO_ERROR, No error, 0)
12/02/2013 15:42:05 epoch=1360712525 : elm3a241-vm1 : vfs.ganesha.nfsd-1113[main
] :fsal_internal_Path2Handle :FSAL: FULLDEBUG: Lookup handle for /vm1gfs0
12/02/2013 15:42:05 epoch=1360712525 : elm3a241-vm1 : vfs.ganesha.nfsd-1113[main
] :VFSFSAL_lookupPath :FSAL: DEBUG: FSAL_lookupPath returns (ERR_FSAL_NOENT, No
such file or directory, 2)
12/02/2013 15:42:05 epoch=1360712525 : elm3a241-vm1 : vfs.ganesha.nfsd-1113[main
] :nfs_export_create_root_entry :NFS STARTUP: CRITICAL ERROR: Couldn't access th
e root of the exported namespace, ExportId=77 Path=/vm1gfs0 FSAL_ERROR=(2
,2)
12/02/2013 15:42:05 epoch=1360712525 : elm3a241-vm1 : vfs.ganesha.nfsd-1113[main
] :nfs_Init :NFS STARTUP: FATAL ERROR: Error initializing Cache Inode root entri
es

---------

If a physical disk is mounted inside the container, say:

	$ mount /dev/sdb1 /mnt1

will we be able export /mnt1 from within the container or does nfs-Ganesha
still need to find the actual root fs ?

In effect, can a process chroot into a directory and export a subdir using
nfs-ganesha ?

Sukadev

             reply	other threads:[~2013-02-13  7:47 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-13  7:47 Sukadev Bhattiprolu [this message]
     [not found] ` <20130213074747.GA19635-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2013-02-13 19:14   ` nfs-ganesha with Linux containers Eric W. Biederman
     [not found]     ` <87liasuiu7.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2013-02-13 19:50       ` Sukadev Bhattiprolu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130213074747.GA19635@us.ibm.com \
    --to=sukadev-23vcf4htsmix0ybbhkvfkdbpr1lh4cv8@public.gmane.org \
    --cc=containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
    --cc=nfs-ganesha-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.