Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I've run into an odd problem regarding mount namespaces on Linux. I have two systems, both X86_64 running kernel 3.2.3-2 under Fedora 16. I am attempting to mount a tmpfs filesystem in a child namespace created using the unshare command:

unshare -m /bin/bash

From the man page:

   mount namespace
          mounting and unmounting filesystems will not affect rest of  the
          system (CLONE_NEWNS flag),

On one system, this works as expected. That is, if I start with this:

# ls /mnt
file1 file2 file3

And then mount a tmpfs filesystem over /mnt in a child namespace:

# PS1="child# ' unshare -m /bin/bash
child# mount -t tmpfs tmpfs /mnt

The contents of /mnt are masked in the child namespace:

child# ls /mnt
child#

But continue to be visible in the parent:

# ls /mnt
file1 file2 file3

On the second system, the exact same sequence of commands will result in a mount that is visible in the parent namespace as well as in the child namespace. In other words, it appears that the unshare command is not actually resulting in a separate mount namespace.

I am not aware of any substantial differences between the two systems. One is running a desktop environment, the other is not. SELinux is disabled on both systems.

I'm looking for any suggestions as to what could be causing this difference in behavior.

share|improve this question
add comment

3 Answers

up vote 3 down vote accepted

Check to see if the sandbox service is running.

systemctl status sandbox.service

If so, turn it off, reboot, and try again. This worked for me.

share|improve this answer
    
You, sir, win the prize. It looks as if simply running mount --make-rprivate / will undo the effects of /etc/rc.s/init.d/sandbox. Now I need to figure out if the sandbox script is necessary given that I'm not using pam_namespace... –  larsks Feb 7 '12 at 22:52
add comment

@John got the answer, but I wanted to provide some additional documentation here to reflect why the behavior of the two systems was different.

The sandbox script (/etc/rc.d/init.d/sandbox) recursively set the shared flag on all mounts on the system by running:

mount --make-rshared /

The comments in the sandbox script read:

description: sandbox, xguest and other apps that want to use pam_namespace require this script be run at boot. This service script does not actually run any service but sets up: / to be shared by any app that starts a separate namespace If you do not use sandbox, xguest or pam_namespace you can turn this service off.

Because the tools referenced here are all GUI applications, the sandbox script is only enabled for runlevel 5. Of the two systems I am working with, one is a desktop -- hence it starts up in runlevel 5 and gets the sandbox script by default -- while the other is a headless server booting to runlevel 3.

share|improve this answer
add comment

I've been seeing the same issue. Try a

mount --make-private /mnt 

before the

mount -t tmpfs tmpfs /mnt

Also look at the source of the seunshare command to see how they do it.

share|improve this answer
    
In order for the mount --make-private /mnt command to complete, I need to run mount -o bind /mnt /mnt first (since /mnt is not a mountpoint otherwise). This gets me something that works as intended, but still leaves me at a loss as to why one system works and the other doesn't. This is also unfortunate because it requires the parent namespace to know in advance any mounts that will be performed by the child namespace, which would seem to defeat some of the advantages of mount namespaces. –  larsks Feb 7 '12 at 18:54
1  
I added bug 788221 to Fedora in the hopes with someone more familiar with the internals will comment on things. –  larsks Feb 7 '12 at 19:15
add comment

Your Answer

 
discard

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.