Droidspaces – Telegram
Run real Linux on Android natively with Droidspaces

As you can see, I converted my Galaxy S10 5G into a portable home server with its own isolated network stack.

Using an Ubuntu 24.04 LTS container in Droidspaces, I set up Jellyfin, Samba, Tailscale, OpenSSH Server, and Fail2Ban in one go - no trial and error.

This is essentially a 1:1 replacement for the whacky Docker/LXC setups on Android. It just works and runs natively with zero overhead.

Droidspaces containers are fully isolated from Android. They can’t detect that they are running on an Android device and cannot see Android processes, mounts, network interfaces, or other devices on your local network - making it a secure environment for running services. This is not chroot or proot.

I access the container through Tailscale. Only ports 445 and 8096 are forwarded, allowing access to the Samba share and Jellyfin server from other devices on my home network via <phone-ip>:<port>.

Project: https://github.com/ravindu644/Droidspaces-OSS
🗿9👏51🔥1🤩1
Fixed Docker/Podman/LXC on Droidspaces containers when running on older kernels!! 🥳

No seccomp shield needed from now on..! 😇
🗿32
Droidspaces v5.6.0 has been released!

https://github.com/ravindu644/Droidspaces-OSS/releases/tag/v5.6.0

Note: After installing this release, if you are using an old kernel like 4.14.113 (this issue is specific to this kernel version), and systemd appears to hang, systemctl commands do not work, or your phone becomes unresponsive, you are affected by the grab_super() VFS deadlock bug.

Strangely, this issue does not occur on 4.9 kernels and only manifests on 4.14.113, which affects most devices, particularly Samsung devices released between 2019 and 2020.

Previously, to fix this, all clone() and unshare() syscalls had to be blocked to prevent systemd from creating sandboxes, which resolved the deadlock and allowed systemd to boot. However, this came at the cost of losing the ability to run Docker, Podman, or LXC inside a Droidspaces container on any kernel below 5.x.

In this release, that hard-coded block has been completely removed. Users can now enable the "Deadlock Shield" only if needed, directly from the container configuration menu.

As a result, users already running an upstream kernel such as 4.14.356 can now run Docker inside Droidspaces, while affected users can still enable the Deadlock Shield manually.

Also, this release focuses on fixing critical vulnerabilities in the project related to common exploits, further hardening security, and fixing a critical security hole where a device's block devices were exposed under /sys/block, even in non `--hw-access` mode.