On 06/05/2015 06:30 AM, Phil Susi wrote:
On 6/5/2015 9:23 AM, James Long wrote:
Hi Andreas,
My problem is actually with unshare(2), rather than unshare(1). Is
there an equivalent patch for unshare(2)?
I don't think you understood the upstream patch. The idea is that after
unshare(2), calls to mount(2) have the option causing the mount to show
up in other namespaces or not. You seem to have an expectation mismatch
in this regard. If you do not want it to show up in the other
namespace, then you need to mount --make-private.
In other words, this is not a bug in unshare ( 1 or 2 ).
Yes, I must be missing something here. I thought that 'mount
--make-rprivate' would restore the previous behavior (man page suggests
rprivate rather than private):
$ sudo unshare -m /bin/bash
# mount -t nfs -o ro,vers=3,tcp 10.4.5.101:/opt /mnt
# mount --make-rprivate /mnt
# df -Th
>snip<
10.4.5.101:/opt nfs 92G 17G 71G 20% /mnt
# exit
$ df -Th
>snip<
10.4.5.101:/opt nfs 92G 17G 71G 20% /mnt
So the mount is still visible to other processes, and doesn't exit with
the process, as it used to in wheezy. The same thing happens with
--make-private. What am I doing wrong?
Thanks,
Jim
--
James Long
Information Systems Manager
International Arctic Research Center
University of Alaska Fairbanks
jlong15 at alaska.edu
(907) 474-2440
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
