Hey everyone! I'm trying to find a solution to a really confusing problem...

I have the following simple nginx docker compose configuration on my Fedora home server that I can run without issue on my uid 1000 user, lets call this user "userA".

services:
  nginx:
    container_name: nginx-alt
    image: docker.io/library/nginx
    restart: unless-stopped
    ports:
      - 8181:80

This exposes internal port 80 as 8181 and can be accessed in a lan in the expected matter.

However, for security reasons, I want to actually host this service eventually on a completely different user with less permissions. Let's call this user "userB" who has a very limited scope of the file system. This is to prevent potential escaping of the rootless container causing major file system havoc (i.e. reduce the scope of the user to a very limited network of containers.)

The problem is really simple: For some reason, when userB runs this service (uid 1001), the nginx service suddenly complains about privileges. As a result, I get a "Forbidden 403" error when hosting. Turning off selinux has no affect (so setenforce 0 does nothing, meaning I can rule out secure linux interruption.)

The errors look like the following:

nginx-alt  | 2026/09/04 20:03:34 [error] 25#25: *1 "/usr/share/nginx/html/index.html" is forbidden (13: Permission denied), client: xx.xx.x.x, server: localhost, request: "GET / HTTP/1.1", host: "xxx.xxx.xxx.xxx:8181"
nginx-alt  | 10.89.0.2 - - [04/Sep/2026:20:03:34 +0000] "GET / HTTP/1.1" 403 153 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:155.0) Gecko/20100101 Firefox/155.0" "-"

For what it's worth, both users should be relatively vanilla and all ports are appropriately exported. There shouldn't be anything, for example, that is making userA run as "privileged" over the other users and podman should be running rootless in both containers.

I did see a note on the nginx image about running in rootless that I might try, but it doesn't solve my bigger issue here which is the lack of consistency between the two users. Additionally, userns_mode: keep-ids only caused the container to fail to boot for other reason entirely.

There must be something fundamentally wrong with my configuration of my system. Has anyone had any experience running two podman containers on two different users simultaneously that can provide feedback?

Obviously, I'm not trying to run just an nginx server, but I found this to be the easiest configuration to reproduce.

When running podman ps I get the following error:

Error: configure storage: mkdir /home/myuser/.local/share/containers/storage/overlay/l: file exists

Any idea how I can ensure this error won't happen again? I'm not sure how it happened.

This might feel a bit heavy for some, but now with Systemd possibly going downhill by introducing ID verification at the operating system level, how do you guys plan on slowly moving your Podman setup away from Systemd? How do you plan on starting containers on bootup without Quadlets?

I have 4 containers setup for Immich:

immich
immich-database
immich-machine-learning
immich-redis

However my Immich container fails to start on boot. And I read in the error log that has to do with the immich-database not finishing starting.

[Unit]
Description=Immich Server
Requires=immich-redis.container immich-database.container
Wants=immich-machine-learning.container

[Container]
ContainerName=immich
AutoUpdate=registry
Network=immich.network
Network=caddy
Image=ghcr.io/immich-app/immich-server:release
Pull=newer
Volume=/mnt/raid/homecloud/immichmedia:/data:z
Volume=/etc/localtime:/etc/localtime:ro
PublishPort=2283:2283
AddDevice=/dev/dri
EnvironmentFile=%h/.immich-env

[Service]
TimeoutStartSec=1000

[Install]
WantedBy=default.target

cross-posted from: https://lemmy.ca/post/61837115

I've had the following error on F2FS, I've deleted the affected folder, and would keep getting the same error on F2FS.

I tried reformatting to EXT4, and am now still getting the same error. I checked if Modprobe could enable overlay, but I get the following error

sudo ls /lib/modules/$(uname -r)/kernel/fs/overlayfs/overlay.ko
ls: cannot access '/lib/modules/6.19.6-arch1-1/kernel/fs/overlayfs/overlay.ko': No such file or directory

sudo modprobe overlay

modprobe: FATAL: Module overlay not found in directory /lib/modules/6.19.6-arch1-1

However I have the following

/lib/modules/6.19.8-arch1-1/kernel/fs/overlayfs/overlay.ko.zst

And also go this error:

Error: configure storage: kernel does not support overlay fs: 'overlay' is not supported over extfs at "/home/dudess/.local/share/containers/storage/overlay": backing file system is unsupported for this graph driver

The following shows CONFIG_OVERLAY_FS=m which online it says it could be available but is not loaded.

zcat /proc/config.gz | grep OVERLAY_FS
CONFIG_OVERLAY_FS=m
CONFIG_OVERLAY_FS_REDIRECT_DIR=y
# CONFIG_OVERLAY_FS_REDIRECT_ALWAYS_FOLLOW is not set
CONFIG_OVERLAY_FS_INDEX=y
CONFIG_OVERLAY_FS_XINO_AUTO=y
CONFIG_OVERLAY_FS_METACOPY=y
# CONFIG_OVERLAY_FS_DEBUG is not set

And the following shows ext4 for the file system type.

mount | grep ext4
/dev/nvme0n1p2 on / type ext4 (rw,relatime)

With docker-compose, containers would start on boot. It was maybe because I had restart: always on.

Is there a way something similar with podman-compose?

I see mentions of creating custom systemd scripts to run podman-compose to start containers, but is there something already baked in podman-compose that I can use?

I'm getting the following error when trying to build Nextcloud AIO Docker container, but using the same images through Podman instead.

My OS is installed on F2FS

/home/user/.config/containers/storage.conf

[storage]
driver = "overlay"
runroot = "/run/user/1000"    
graphroot = "/home/cn/graph"
rootless_storage_path = "/home/cn/storage"

/etc/containers/storage.conf has

runroot = "/home/cn/tmpstr"
graphroot = "/home/cn/graph"
rootless_storage_path = "/home/cn/storage"

/home/cn/graph is being populated, but not /home/cn/tmpstr and /home/cn/storage

The following is part of the error message:

Message: Could not create container nextcloud-aio-collabora: {"cause":"file name too long","message":"container create: opening seccomp profile failed: open {\n "defaultAction": "SCMP_ACT_ERRNO",\n "defaultErrnoRet": 1,\n "archMap"___``___

Cross-posted from "Dedicated service user or not ?" by @mat@jlai.lu in !selfhosted@lemmy.world

Hi all !

As of today, I am running my services with rootless podman pods and containers. Each functional stack gets its dedicated user (user cloud runs a pod with nextcloud-fpm, nginx, postgresql...) with user mapping. Now, my thought were that if an attack can escape a container, it should be contained to a specific user.

Is it really meaningful ? With service users' home setup in /var/lib, it makes a lot of small stuff annoying and I wonder if the current setup is really worth it ?