The issue is around mount propagation. The /home/ directory is being recursively bound into the schroot tree. When the schroot tree is recursively unmounted and SCHROOT_DIR/home/foo is unmounted, that unmount event is being propagated to the original /home/foo mount point. To prevent that from happening, the recursively bound SCHROOT_DIR/home mount point needs to be recursively private. Using the example in comment #4, with eCryptfs instead of ext4, that would look like this:
foo@sec-vivid-amd64:~$ grep home/foo /proc/mounts /home/foo/.Private /home/foo ecryptfs rw,nosuid,nodev,relatime,ecryptfs_fnek_sig=176339c8321afc83,ecryptfs_sig=35e81f7d08221a22,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs 0 0 foo@sec-vivid-amd64:~$ sudo mount -R /home /tmp/home foo@sec-vivid-amd64:~$ sudo mount --make-rslave /tmp/home foo@sec-vivid-amd64:~$ grep home/foo /proc/mounts /home/foo/.Private /home/foo ecryptfs rw,nosuid,nodev,relatime,ecryptfs_fnek_sig=176339c8321afc83,ecryptfs_sig=35e81f7d08221a22,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs 0 0 /home/foo/.Private /tmp/home/foo ecryptfs rw,nosuid,nodev,relatime,ecryptfs_fnek_sig=176339c8321afc83,ecryptfs_sig=35e81f7d08221a22,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs 0 0 foo@sec-vivid-amd64:~$ sudo umount -R /tmp/home foo@sec-vivid-amd64:~$ grep home/foo /proc/mounts /home/foo/.Private /home/foo ecryptfs rw,nosuid,nodev,relatime,ecryptfs_fnek_sig=176339c8321afc83,ecryptfs_sig=35e81f7d08221a22,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs 0 0 Note that two separate mount commands are required. The -R and --make- rslave options cannot be specified in the same mount command. The mount(8) program will turn this into two mount(2) syscalls and strip the MS_REC flag off of the first mount(2) syscall, resulting in a non- recursive bind mount: mount("/home", "/tmp/home", 0x1880f30, MS_MGC_VAL|MS_BIND, NULL) = 0 mount("none", "/tmp/home", NULL, MS_REC|MS_SLAVE, NULL) = 0 This means that we can add a new line to the click/fstab file, specifying that the schroot's /home/ recursive bind mount point should be made recursively private. While I haven't had a chance to do extensive testing, the following change seems to fix this bug: $ diff -Nurp /etc/schroot/click/fstab.orig /etc/schroot/click/fstab --- /etc/schroot/click/fstab.orig 2015-03-12 15:23:37.631296891 -0500 +++ /etc/schroot/click/fstab 2015-03-12 15:24:09.183296891 -0500 @@ -8,5 +8,6 @@ /dev /dev none rw,bind 0 0 /dev/pts /dev/pts none rw,bind 0 0 /home /home none rw,rbind 0 0 +none /home none rslave 0 0 /tmp /tmp none rw,bind 0 0 /run/shm /run/shm none rw,bind 0 0 ** Changed in: click (Ubuntu) Status: New => Triaged -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to click in Ubuntu. https://bugs.launchpad.net/bugs/1427264 Title: using ecryptfs, creating frameworks fail to bind mount issues Status in click package in Ubuntu: Triaged Bug description: Using vivid creating framework fails for ecryptfs users, the issue is similar to bug #769595 The userdir is mounted in a way which makes unmounts fail "E: 10mount: umount: /var/lib/schroot/mount/click-ubuntu-sdk-14.10 -armhf-ec6aaf62-31e0-47e9-b2f8-73f0b038fb4d/home/user: target is busy E: 10mount: (In some cases useful info about processes that E: 10mount: use the device is found by lsof(8) or fuser(1).) " changing the fstab line to be "/home/user /home/user none rw,bind 0 0" workarounds the issue To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/click/+bug/1427264/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp