I would like to mount an encrypted image file using cryptsetup inside a systemd-nspawn container. However, I get this error message: [root@container ~]# echo $key | cryptsetup -d - open luks.img luks Cannot initialize device-mapper. Is dm_mod kernel module loaded? Cannot use device luks, name is invalid or still in use. The dm_mod kernel module is loaded on the host system, although things look a bit weird inside the container: [root@host ~]# grep dm_mod /proc/modules dm_mod 159744 2 dm_crypt, Live 0xffffffffc12c6000 [root@container ~]# grep dm_mod /proc/modules dm_mod 159744 2 dm_crypt, Live 0x0000000000000000 strace indicates that cryptsetup is unable to create /dev/mapper/control: [root@etrial ~]# echo $key | strace cryptsetup -d - open luks.img luks 2>&1 | grep mknod mknod("/dev/mapper/control", S_IFCHR|0600, makedev(0xa, 0xec)) = -1 EPERM (Operation not permitted) I am not too sure why this is happening. I am starting the container with the systemd-nspawn@.service template unit , which seems like it should allow access to the device mapper: # nspawn can set up LUKS encrypted loopback files, in which case it needs # access to /dev/mapper/control and the block devices /dev/mapper/*. DeviceAllow=/dev/mapper/control rw DeviceAllow=block-device-mapper rw Reading this comment on a related question about USB devices , I wondered whether the solution was to add a bind mount for /dev/mapper. However, cryptsetup gives me the same error message inside the container. When I strace it, it looks like there's still a permissions issue: # echo $key | strace cryptsetup open luks.img luks --key-file - 2>&1 | grep "/dev/mapper" stat("/dev/mapper/control", {st_mode=S_IFCHR|0600, st_rdev=makedev(0xa, 0xec), ...}) = 0 openat(AT_FDCWD, "/dev/mapper/control", O_RDWR) = -1 EACCES (Permission denied) # ls -la /dev/mapper total 0 drwxr-xr-x 2 nobody nobody 60 Dec 13 14:33 . drwxr-xr-x 8 root root 460 Dec 15 14:54 .. crw------- 1 nobody nobody 10, 236 Dec 13 14:33 control Apparently, this is happening because the template unit enables user namespacing, which I want anyway for security reasons. As explained in the documentation : >In most cases, using --private-users=pick is the recommended option as it enhances container security massively and operates fully automatically in most cases ... [this] is the default if the systemd-nspawn@.service template unit file is used ... > >Note that when [the --bind option] is used in combination with --private-users, the resulting mount points will be owned by the nobody user. That's because the mount and its files and directories continue to be owned by the relevant host users and groups, which do not exist in the container, and thus show up under the wildcard UID 65534 (nobody). If such bind mounts are created, it is recommended to make them read-only, using --bind-ro=. Presumably I won't be able to do anything with read-only permissions to /dev/mapper. So, is there any way I can get cryptsetup to work inside the container, so that my application can create and mount arbitrary encrypted volumes at runtime, without disabling user namespacing? ## Related questions * systemd-nspawn: file-system permissions for a bound folder relates to files rather than devices, and the only answer just says that "-U is mostly incompatible with rw --bind." * systemd-nspawn: how to allow access to all devices doesn't deal with user namespacing and there are no answers.

I'm trying to setup container that has access to the internet but have been unsuccessful so far. # sudo systemd-nspawn -nb -M debian-tree # systemctl enable --now systemd-networkd systemd-resolved # ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf # ip link 1: lo: mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: host0@if8: mtu 1500 qdisc noqueue state LOWERLAYERDOWN mode DEFAULT group default qlen 1000 link/ether 42:ca:d5:8c:af:60 brd ff:ff:ff:ff:ff:ff link-netnsid 0 # ping google.com ping: google.com: Temporary failure in name resolution On the host # ip link 1: lo: mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: wlp1s0: mtu 1500 qdisc mq state UP mode DORMANT group default qlen 1000 link/ether 7c:7a:91:ae:7d:47 brd ff:ff:ff:ff:ff:ff 8: ve-debian-tree@if2: mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether 92:f7:e1:4b:c6:6f brd ff:ff:ff:ff:ff:ff link-netnsid 0 Any ideas why it's not working?

I would like to use adb inside an systemd-nspawn container. Unfortunately I cannot access the phone inside the container (connected via USB). pi@debian-buster-64:~ $ export ADB_TRACE=usb pi@debian-buster-64:~ $ adb devices List of devices attached * daemon not running; starting now at tcp:5037 * daemon started successfully pi@debian-buster-64:~ $ Here is the container setup /etc/systemd/nspawn/debian-buster-64.nspawn: [Exec] PrivateUsers=no Capability=CAP_NET_ADMIN [Files] Bind=/home Bind=/run/user:/run/host-user/ BindReadOnly=/etc/resolv.conf [Network] Private=no VirtualEthernet=no Here is the output from lsusb from inside the container: pi@debian-buster-64:~ $ lsusb Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 009: ID 045e:07b2 Microsoft Corp. 2.4GHz Transceiver v8.0 used by mouse Wireless Desktop 900 Bus 001 Device 010: ID 18d1:4ee7 Google Inc. Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Output of lsusb is identical to the output on the host and the phone (Google Inc.) is visible. I want to use adb inside the container because the container is 64bit (host is only 32bit). Unfortunately, adb on 32bit has limitations. Access with adb works on the host (with said 32bit limitations). Any ideas how to get this working inside the container?

I'm trying to understand how systemd-nspawn manages internet access and port-forwarding for containers. I set up an nspawn container with --network-veth and a port forwarding with --port=80. Both host and container run systemd-networkd. Everything works perfectly: the container can access the internet, and incoming traffic to port 80 gets forwarded to the container. I'd like to understand and inspect how systemd manages this. I was (naively?) expecting to find related rules in iptables, but if I run iptables -t ... -S all tables look empty, both in the host and the container. I also ran the same command with nsenter to enter the network namespace of the veth, but I still see no rules. So, does systemd not use Netfilter for NAT/Masquerading? If not, what does it use?

My container changes its ip address extremely often, almost every boot. I tried giving it a static ip address so my script knows how to ssh into it but nothing I did seemed to work. So I tried looking into the host side. No luck either. After doing the below (and rebooting my system). I tried booting with -b -D path -n. When I do I get 0 connectivity. systemctl list-units --type=service show systemd-networkd.service as loaded active running. I'm not sure what could be wrong. The container is alpine and the host is arch cp /usr/lib/systemd/network/80-container-host0.network /etc/systemd/network/

I would like to create a nspawn container connected to the network via macvlan and dhcp. All documentation I have found were very instructive but did not offer a step by step procedure for this setup. What I did so far was to create the container (debian base) using debootstrap including systemd-container: debootstrap --arch=armhf --include=systemd-container stretch /var/lib/machines/raspbian-09 http://archive.raspbian.org/raspbian **Native host network** running: systemd-nspawn -b -M raspbian-09 or machinectl raspbian-09 with the unit file /etc/systemd/nspawn/raspbian-09.nspawn containing: [Exec] Boot=true PrivateUsers=no [Network] Private=no VirtualEthernet=no In both cases, the network connection is fine. **Macvlan** For the macvlan, I either run the command: systemd-nspawn -b -M raspbian-09 --network-macvlan=eth0 or machinectl raspbian-09 with the unit file /etc/systemd/nspawn/raspbian-09.nspawn containing: [Exec] Boot=true PrivateUsers=no [Network] MACVLAN=eth0 In both cases, the connection to the network does not work. Within the container, I can see that an interface mv-eth0 is created: # networkctl IDX LINK TYPE OPERATIONAL SETUP 1 lo loopback carrier unmanaged 2 mv-eth0 ether degraded configuring however, there is no ipv4 address: # ip a mv-eth0: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff link-netnsid 0 inet6 xxxx::xxxx:xxxx:xxxx:xxxx/64 scope link valid_lft forever preferred_lft forever What other configurations on the host and container should be made?

I am running Debian container on systemd-nspawn (host machine is Ubuntu 24.04) and inside container I installed Electron app. I can run this app with GUI (i. e. when I run it, on my host machine is opened a window, running this app), but app from this container does not have access to speakers, microphone and camera. So how to configure the container to use host's Pipewire for sound? My container has only root user. I installed PulseAudion (and also Pipewire) on container, but in /run/user/0 there is no pulse or pipewire directory.

How do I run a listening program (specifically unoconv as a listener) inside a container using systemd-nspawn, so that it can run in the background (without a console) and be reached by other processes? For example in a perfect world it would be as easy as this: # something like this to start the container and program in background systemd-nspawn -D --background # something like this to connect to container and execute command systemd-run --machine The furthest I've got so far is using Taming systemd-nspawn for running containers , which gets the container running in the background with machinectl. However, sudo systemd-run --machine ls fails with the error: Failed to create bus connection: Permission denied. My question is two-fold. One, can you solve this error? Or two (preferably) can you give me a simpler way to start and connect to a container and run commands? (I'm running Ubuntu Xenial on a secure machine with no internet access)

I'm playing with containerizing various parts of my server infrastructure and one of the services I would like to run in container is ntp daemon. I'm using systemd-nspawn (systemd 233) as a hypervisor as well as init process inside of the containers. ntpd version is 4.2.8p10. Every time I try to start ntpd inside of a container it crashes with cap_set_proc() operation not permitted error: 21 Oct 11:10:23 ntpd: ntpd 4.2.8p10@1.3728 Fri Oct 20 23:28:39 UTC 2017 (1): Starting 21 Oct 11:10:23 ntpd: Command line: ntpd -g -n -u ntp:ntp 21 Oct 11:10:23 ntpd: Cannot set RLIMIT_MEMLOCK: Operation not permitted 21 Oct 11:10:23 ntpd: proto: precision = 0.335 usec (-21) 21 Oct 11:10:23 ntpd: Listen normally on 0 v4wildcard 0.0.0.0:123 21 Oct 11:10:23 ntpd: Listen normally on 1 lo 127.0.0.1:123 21 Oct 11:10:23 ntpd: Listening on routing socket on fd #18 for interface updates 21 Oct 11:10:23 ntpd: mlockall(): Cannot allocate memory 21 Oct 11:10:23 ntpd: start_kern_loop: ntp_loopfilter.c line 1119: ntp_adjtime: Operation not permitted 21 Oct 11:10:23 ntpd: set_freq: ntp_loopfilter.c line 1082: ntp_adjtime: Operation not permitted 21 Oct 11:10:23 ntpd: cap_set_proc() failed to drop root privs: Operation not permitted What I have tried so far: 1. Building ntpd without capabilities enabled - it starts properly, but still has same ntp_adjtime syscall permission issues. 2. Running systemd-nspawn with --private-users=0 and without --private-users at all. 3. Playing with capabilities for systemd-nspawn itself (mainly CAP_SYS_TIME and CAP_NET_BIND_SERVICE) 4. Playing with capabilities for ntpd inside of the container. All this gave no positive results and I wonder what am I missing. Any ideas will be greatly appreciated.

Tried No internet connection in chroot environment solution without succeess (copying resolv.conf) machinectl login helloworld uname -a Linux cas12-Yoga-7-14ITL5 6.8.0-40-generic #40~22.04.3-Ubuntu SMP PREEMPT_DYNAMIC Tue Jul 30 17:30:19 UTC 2 x86_64 GNU/Linux ping 8.8.8.8: ping: connect: Network is unreachable

I've tried hit 3 times ctrl+], ctrl+shift+], ctrl+c but it still shows login prompt. Tried this answer without success How to exit existing systemd-nspawn in boot mode? How to send it to background?

making first experiments with systemd-nspawn. I would like to set up a container to run a single application with isolation. So far my command line is sudo systemd-nspawn -M mycontainer -x -U --user=me --as-pid2 plus some bind mounts. So far so good. I also would like to have network isolation, since my application does not need to exchange data with the outside, but just to expose a single port to my own host. It is unclear to me how to reach this goal: -p does not seem to work with ports on the loopback interface, so I think I need a veth. However, starting the container without -b, I cannot have networkd to configure my interface for me, nor I can configure it otherwise, because I am starting the container with an unprivileged user. Any clue? Am I misinterpreting what I should be doing?

I have a systemd-nspawn container in which I am trying to change the kernel parameter for msgmnb. When I try to change the kernel parameter by directly writing to the /proc filesystem or using sysctl inside the systemd-nspawn container, I get an error that the /proc file system is read only. [From the arch wiki I see this relevant documentation](https://wiki.archlinux.org/title/systemd-nspawn#:~:text=systemd%2Dnspawn%20limits%20access%20to,nodes%20may%20not%20be%20created.)

systemd-nspawn limits access to various kernel interfaces in the container to read-only, such as /sys, /proc/sys or /sys/fs/selinux. Network interfaces and the system clock may not be changed from within the container. Device nodes may not be created. The host system cannot be rebooted and kernel modules may not be loaded from within the container.

I thought the container would inherit some properties of /proc from the host, including the kernel parameter value for msgmnb, but this does not appear to be the case as the host and container have different values for msgmnb. The kernel parameter value in the container:

cat /proc/sys/kernel/msgmnb
16384

Writing to the proc filesystem inside the container

$ bash -c 'echo 2621440 > /proc/sys/kernel/msgmnb'
bash: /proc/sys/kernel/msgmnb: Read-only file system

For completeness, I also tried sysctl in the container:

# sysctl -w kernel.msgmnb=2621440
sysctl: setting key "kernel.msgmnb": Read-only file system

I thought this value would be inherited from the host system. I set the value on the host, rebooted and re-created my container. The container (even new ones) maintains the value of 16384.

# On the host
$ cat /proc/sys/kernel/msgmnb
2621440

I've also tried using unprivileged the -U flag when booting the systemd-nspawn container but I get the same results. I've also tried to editted /etc/sysctl.conf in the container tree to include this line before booting the container:

kernel.msgmnb=2621440

I also looked into https://man7.org/linux/man-pages/man7/capabilities.7.html and noticed CAP_SYS_RESOURCE which has a line that reads:

CAP_SYS_RESOURCE
...
raise msg_qbytes limit for a System V message queue
                 above the limit in /proc/sys/kernel/msgmnb (see
                 msgop(2) and msgctl(2));

Using sudo systemd-nspawn --capability=CAP_SYS_RESOURCE -D /path/to/container, and then inside the container, when I use msgctl with IPC_SET and pass msqid_ds->msg_qbytes with a value that is higher than what is in /proc/sys/kernel/msgmnb, the syscall returns an error code. It seemed like passing the CAP_SYS_RESOURCE should work here? Nothing I've tried here has changed the value for msgmnb in the container. I can't seem to find documentation on how to achieve my goal. I'd appreciate any help - thank you! EDIT: Trying to determine if the process calling msgctl has the capability. Here is what I found:

$ cat /proc/6211/status | grep -i Cap
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
CapBnd: 00000000fdecafff
CapAmb: 0000000000000000
$ capsh --decode=00000000fdecafff
0x00000000fdecafff=cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_raw,cap_ipc_owner,cap_sys_chroot,cap_sys_ptrace,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_tty_config,cap_mknod,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap

I have a nspawn container:

root@nomad-02:~# machinectl list
MACHINE CLASS     SERVICE        OS     VERSION ADDRESSES
debian  container systemd-nspawn debian 11      192.168.88.171…

1 machines listed.

systemd-resolved.service is started on the host (and in the container as well):

root@nomad-02:~# systemctl status systemd-resolved.service
● systemd-resolved.service - Network Name Resolution
     Loaded: loaded (/lib/systemd/system/systemd-resolved.service; enabled; vendor preset: enabled)
     Active: active (running) since Tue 2022-01-25 22:16:34 UTC; 12h ago
       Docs: man:systemd-resolved.service(8)
             man:org.freedesktop.resolve1(5)
             https://www.freedesktop.org/wiki/Software/systemd/writing-network-configuration-managers 
             https://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients 
   Main PID: 232128 (systemd-resolve)
     Status: "Processing requests..."
      Tasks: 1 (limit: 1132)
     Memory: 5.3M
        CPU: 153ms
     CGroup: /system.slice/systemd-resolved.service
             └─232128 /lib/systemd/systemd-resolved

Jan 25 22:16:34 nomad-02 systemd: Starting Network Name Resolution...
Jan 25 22:16:34 nomad-02 systemd-resolved: Positive Trust Anchors:
Jan 25 22:16:34 nomad-02 systemd-resolved: . IN DS 20326 8 2 e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d
Jan 25 22:16:34 nomad-02 systemd-resolved: Negative trust anchors: 10.in-addr.arpa 16.172.in-addr.arpa 17.172.in-addr.arpa 18.172.in-addr.arpa 19.172.in-addr.arpa 20.172.in-addr.arpa 21.172.in-addr.arpa 22.172.in-addr.arpa 23.172.>
Jan 25 22:16:34 nomad-02 systemd-resolved: Using system hostname 'nomad-02'.
Jan 25 22:16:34 nomad-02 systemd: Started Network Name Resolution.

The container has a vnet:

root@nomad-02:~# resolvectl status
Global
         Protocols: +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: foreign

...

Link 439 (ve-debian)
Current Scopes: LLMNR/IPv4 LLMNR/IPv6
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

I would like to know if it is possible to reach the container from within the host using its hostname. What I tried is:

dig @127.0.0.53 debian

which does not work. I can not find any documentation on how to do it. Is it possible to do it? Thanks in advance.

I have a nspawn service that needs to take a WireGuard interface from the host. ###### fw0.nspawn

[Network]
Interface=wg0

According to nspawn man page, I will also need this systemd drop-in.

[Unit]
Wants=sys-subsystem-net-devices-wg0.device
After=sys-subsystem-net-devices-wg0.device

The WireGuard interface needs to be added and configured before moving to the container namespace. I do not use wg-quick in here because I don't want the interface to UP at the host.

ip link add wg0 type wireguard
wg setconf wg0 /root/wg0.conf

The problem is how to abstract out the above two commands using systemd service and dependency, instead of putting it into ExecStartPre and ExecStopPost. The caveat is that normally the WG interface will be removed from the host when the nspawn container start, and it will move back to the host when the container stops. But if the container fails to start, the WG interface will be disappeared, and I will need to ip link add again.

I have a JBOSS Installer which when run manually it will prompt for input and below is the sample of the execution is as below [sp@sp baseInstaller]$ ./advStart.sh config Buildfile: /home/sp/jboss/sp/baseInstaller/build.xml init: config: [groovy] coa.install.props properties [groovy] [groovy] ? indicates a response is required from you [groovy] [value] is the current value [groovy] to keep current value just press [groovy] or type new value and press [groovy] {value,value..} shows the allowed values [groovy] installer version 6.0.3.4 [groovy] [groovy] Jboss Server Config Options (changeable after initial config) [groovy] ------------------------------------------------------------- [groovy] ? host [sp.resource.com] resource.com [groovy] ip=10.50.55.90 [groovy] host changed to resource.com [groovy] ? bind to host only or all ports (all has security implications) [groovy] [host] [groovy] {host,all,custom} all [groovy] bind to host only or all ports (all has security implications) changed to all [groovy] ? min memory 64 I tried to frame an expect script to automate this process and below is my script [sp@sp baseInstaller]$ cat saba.sh #!/usr/bin/expect # Accessing command line arguments set arg1 [lindex $argv 0] set arg2 [lindex $argv 1] # Printing the arguments puts "Argument 1: $arg1" puts "Argument 2: $arg2" cd /home/sp/jboss/sp/baseInstaller spawn ./advStart.sh config # Expect the prompt for the argument with a timeout of 10 seconds expect { "? host [sp.resource.com]" { # Send the host value send "$arg1\r" exp_continue } "? bind to host only or all ports (all has security implications)" { # Send the argument value send "$arg2\r" } timeout { puts "Error: Timed out while waiting for the prompt." exit 1 } eof } -timeout 10 # Wait for the script to finish wait Now while executing this script, it is getting struck in the below place and not proceeding further. Can you please help me about this? [sp@sp baseInstaller]$ expect saba.sh resource.com all Argument 1: resource.com Argument 2: all spawn ./advStart.sh config Buildfile: /home/sp/jboss/sp/baseInstaller/build.xml init: config: [groovy] coa.install.props properties [groovy] [groovy] ? indicates a response is required from you [groovy] [value] is the current value [groovy] to keep current value just press [groovy] or type new value and press [groovy] {value,value..} shows the allowed values

I'm trying to lock down a container using systemd-nspawn, so that *only* the specific syscalls I whitelist are allowed. Per the documentation , there's a pretty lax filter in place by default, consisting of a large whitelist of hundreds of different system calls. There's a unit option SystemCallFilter=, which claims to allow you to blacklist or whitelist specific calls. I tried it out, putting a single syscall on there and expecting complete failure:

[Exec]
...
# We use way more syscalls than this! This whitelist should fail, but it doesn't because it's not a real whitelist.
SystemCallFilter=open,write,close
...

Instead, the program runs just fine. I can get it to fail if I explicitly disallow a syscall I know is in use:

[Exec]
...
# This actually fails, because open's been explicitly blacklisted.
SystemCallFilter=~open,~write
...

Also, because the blacklist takes precedence over the "whitelist," I can't just disable everything and then turn back on only the ones I need; the whitelist is just ignored:

[Exec]
...
# Doesn't work, as ~@default takes precedence over the allowlist so *nothing* is allowed
SystemCallFilter=~@default
# full list is much longer and generated automatically from a docker seccomp .json
SystemCallFilter=open,write,close,...

Is there a way to achieve the functionality I want? I really don't want to maintain a blacklist of all of the hundreds of syscalls on the default allowlist, which seems like the only way to do it currently.

I've created a systemd-nspawn container in which /dev/fb1 from the host is bound as /dev/fb0. I've set PrivateUsers=off in the .nspawn config file, and the file ownership and permissions of /dev/fb0 in the container appear to be the same as /dev/fb1 on the host. Running cat /dev/urandom >/dev/fb1 on the host works as expected ('no space left on device' error), but if I boot the container, and log in to it as root (with machinectl) cat /dev/urandom >/dev/fb0 fails with 'Operation not permitted'. I also tried to write to it using dd -if /dev/urandom -of /dev/fb0, and that gave the error 'dd: failed to open '/dev/fb0': Operation not permitted'. I've tested other commands that would require root access, such as chmod and chown, and my root user in the container is able to run those. If I bind /dev/fb1 as itself (i.e. just Bind=/dev/fb1), then the write operation *is* permitted. Does anyone know why I can't open the file for writes from within the container? This is the .nspawn config:

[Exec]
Capability=CAP_SYS_ADMIN
PrivateUsers=off

[Files]
Bind=/dev/fb1:/dev/fb0
Bind=/srv

This is the systemd-nspawn service override file for the container:

[Service]
DeviceAllow=/dev/fb0 rw
DeviceAllow=char-input rw
DeviceAllow=char-drm rw

(I'm sure some of this config is unnecessary -- I've just been chucking in everything I can think of to solve my problem.)

I am using systemd-nspawn to boot a linux container and load its lxsession in a VNC-style nested X server. (Xephyr) I have created a script to do this. One of the main problems with the script is the need to login to the container's console before the GUI is initiated via /etc/profile. Here's my question: I'm looking for a way to autostart graphical applications, without first requiring the user to manually login. I've tried: - Getting the console to autologin using lightdm . This does not work since lightdm always fails to start. - Finding an autostart method that can run lxsession in the foreground. I only know of /etc/rc.local. It kind of works, but the environmental variables are all messed up, and there's a dialog box that says "No session for PID XXX" - Having the script type in the username and password. Bad idea since many of the containers use a password other than the default "raspberry".

Been trying to understand and play around with systemd-nspawn because I'd like to run a Debian Testing install for myself without enabling the testing repos on my main Debian stable system. I wrote this shell script to help set up Debootstrap process: #!/bin/sh dirpath="$1" if [ -z "$dirpath" ]; then dirpath="debian-testing-devel" elif ! [ -d "$dirpath" ]; then mkdir -p "$dirpath" fi echo "NOTICE: You must run debootstrap as a root user! Requesting sudo privilage..." sudo debootstrap --include="dbus,systemd-container" testing "$dirpath" "https://deb.debian.org/debian " echo "Debootstrap has finished!" echo "You may log in to your system by using: systemd-nspawn -D ${dirpath} -U --machine debian-testing-devel" echo "Make sure to set a secure root password!" Something like that, basically. I named it "debian-testing-devel". Then I quickly learned that machinectl can only access things in "/var/lib/machines/", so I moved my created directory there. Anyway... Then I logged in with systemd-nspawn -D /var/lib/machines/debian-testing-devel/ -U --machine debian-testing-devel, and set up my password, and had to add "pts/0" and "pts/1" to "/etc/securetty" so I could login as root. When I tried to login with machinectl login debian-testing-devel, I got "Failed to get login PTY: Protocol error" So I logged into the container with systemd-nspawn again, found out that the package install was broken for some reason with dbus, so I ran apt -f install, which seemed to fix it... kinda. Another source Online claimed that I had to also install systemd in the container itself, not just DBus, to get rid of the protocol error, so I tried that! And finally, when I try to run machinectl login debian-testing-devel again, I still get stuck at "Failed to get login PTY: ..." this time it says, Failed to get login PTY: Failed to activate service 'org.freedesktop.systemd1': timed out (service_start_timeout=25000ms). So I'm really not sure what to do next. Trying to search for this problem Online isn't bringing up too many results, and I'm not sure what's going on. It's been getting a little frustrating to try to learn this stuff and get it working when... nothing I try to do seems to work... Any help is appreciated!