That's exactly what's going on here. The systemd service launcher is doing the same thing as unshare(1); calling unshare(2). However, by "default" after you `

That's exactly what's going on here. The systemd service launcher is doing the same thing as unshare(1); calling unshare(2). However, by "default" after you `unshare --mount`/`unshare(CLONE_NEWNS)`, changes made to existing mounts can propagate to the parent namespace, so then you need to do something like `mount --make-rslave /` to complete the isolation. As I understand the bug, the problem is in systemd's version of the `mount --make-rslave /` step, which (for a reason unknown to me) tries to stat (as root) the mountpoint first, and if the mountpoint is on a remote FS that might fail, and systemd isn't correctly handling that.