Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm trying to setup a jail to enable building a NanoBSD image. It's actually a jail on top of a NanoBSD install.

The problem I have is that I'm unable to mount the md device in order to do the 'build image' part. Is it simply not possible to mount an md device inside a jail, or is there some other knob I need to twiddle?

On the host




# nothing

Inside the jail

[root@build /usr/obj/nanobsd.PROLIANT_MICROSERVER]# sysctl security.jail 0 0 64 256 256
security.jail.param.children.max: 0
security.jail.param.children.cur: 0
security.jail.param.enforce_statfs: 0
security.jail.param.securelevel: 0
security.jail.param.path: 1024 256
security.jail.param.parent: 0
security.jail.param.jid: 0
security.jail.enforce_statfs: 1
security.jail.mount_allowed: 1
security.jail.chflags_allowed: 1
security.jail.allow_raw_sockets: 0
security.jail.sysvipc_allowed: 0
security.jail.socket_unixiproute_only: 1
security.jail.set_hostname_allowed: 0
security.jail.jail_max_af_ips: 255
security.jail.jailed: 1

[root@build /usr/obj/nanobsd.PROLIANT_MICROSERVER]# mdconfig -l
md2 md0 md1 

md0 and md1 are the ramdisks of the host.

bsdlabel looks sensible

[root@build /usr/obj/nanobsd.PROLIANT_MICROSERVER]# bsdlabel /dev/md2s1
# /dev/md2s1:
8 partitions:
#        size   offset    fstype   [fsize bsize bps/cpg]
  a:  1012016       16    4.2BSD        0     0     0 
  c:  1012032        0    unused        0     0         # "raw" part, don't edit

newfs runs ok

[root@build /usr/obj/nanobsd.PROLIANT_MICROSERVER]# newfs -U /dev/md2s1a
/dev/md2s1a: 494.1MB (1012016 sectors) block size 16384, fragment size 2048
    using 4 cylinder groups of 123.55MB, 7907 blks, 15872 inodes.
    with soft updates
super-block backups (for fsck -b #) at:
 160, 253184, 506208, 759232

mount fails

[root@build /usr/obj/nanobsd.PROLIANT_MICROSERVER]# mount /dev/md2s1a _.mnt/
mount: /dev/md2s1a : Operation not permitted


One of my colleagues pointed out

There are some file systems types that can't be securely mounted within a jail no matter what, like UFS, MSDOFS, EXTFS, XFS, REISERFS, NTFS, etc. because the user mounting it has access to raw storage and can corrupt it in a way that it will panic entire system.


So it seems that the standard won't run inside a jail while it uses the md device to build the image. One potential solution I'll try is to chroot from the host into the build jail, rather than jexec a shell.

share|improve this question
What about running mount with ktrace? – SaveTheRbtz Nov 25 '11 at 8:28
@SaveTheRbtz ah, good idea. I'll try that tonight. ktrace mount /dev/md2s1a _.mnt/ I'm guessing – ptomli Nov 25 '11 at 9:02
@ptomil, did you have any luck? I'm interested in tackling something similar, and hoping to learn from your scars. – Royce Williams Dec 11 '11 at 6:30
@RoyceWilliams I was somewhat successful, in that it's possible to do the build in a chroot environment. It's not possible to do it inside a jail. – ptomli Dec 12 '11 at 6:49

As you said, chroot is the way to go.

You don't want to achieve security, just build and change the root so that your installation scripts behave correctly. That's what chroot is for.

On some systems there isn't a chroot binary, but it's kind of easy to code a simple script that will achieve what everything you want (and hey, you can reuse it later!).

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.