I ran into this, and everything works now after upgrading all systemd packages to 226-2 and rebooting.
Note that this bug is *completely* unrelated to having dbus installed in the container or having /dev/pts/0 in /etc/securetty, it happens before that is relevant. Note that systemd-container does not have a versioned `Depends:` on systemd, and `systemd` does not have a versioned `Suggests:` on systemd-container (if that even makes sense). I have not tested what happens when they are not upgraded in lockstep. With 225-1: * systemd-nspawn -b provides a login prompt (on /dev/console). * If container is started with systemd-nspawn -b, machinectl login fails (tries to use hosts's /dev/pts/0 instead of container's). * If container is started with machinectl start, machinectl login fails (tries to use hosts's /dev/pts/0 instead of container's). * If container is started with systemctl start, machinectl login fails (tries to use hosts's /dev/pts/0 instead of container's). With 226-2: * systemd-nspawn -b provides a login prompt (on /dev/console). * If container is started with systemd-nspawn -b, machinectl login fails (tries to use hosts's /dev/pts/0 instead of container's). * If container is started with machinectl start, machinectl login fails (tries to use hosts's /dev/pts/0 instead of container's). * If container is started with systemctl start, machinectl login fails (tries to use hosts's /dev/pts/0 instead of container's). Note that `machinectl shell` has the same results as `machinectl login` in the cases I have tested, which is not all of them. Note that the error message differed depending on whether /dev/pts/0 existed on the host or not. If you are running KDE, it usually appears graphically (to catch wall(1) notifications).
