NCPI 1.54.0 x86 LXC image: redis does not start due to faulty ownership

[Arouraios]

When using a clean NextcloudPi v1.54.0 x86 LXC image on an up to date proxmox, nextcloud activation gets stuck on "not yet initialized, trying again in a few seconds".
Journalctl shows errors for redis-server.service not being able to start, most notably it says it cannot access /etc/redis/redis.conf. Unfortunately I have not copied these journalctl outputs, I might reproduce the error later on and attach all the logs and errors.
ls -ld /etc/redis outputs ownership of user postfix, group prometheus. Similarly /var/log/redis and /var/lib/redis are both owned by postfix.

Solution:

chown -R redis:redis /etc/redis/
chown -R redis:adm /var/log/redis/
chown -R redis:redis /var/lib/redis/
systemctl restart redis-server.service
(or reboot to be sure)

I think I also had to add the www-data user to the redis group (usermod -aG redis www-data), but I might be mixing some things up (in the last couple of days I've done more nextcloud installations than I can count).
This only happens on v1.54.0 of NextcloudPi, v1.53.3 activates without issue.
After fixing ownership nextcloud appears to be working without issues. Well kinda, eth0 isn't up after reboot, but a simple ip link set up eth0 fixes that. And I've had this issue with other containers as well, it could very well be caused by the proxmox community kernel acting up, that's why I haven't opened a NCPI issue report about it.

Considering this issue does not appear when using the install script I assume it's a new problem with the build process for the container.

I have not appended the output of ncp-report since it lists my workplaces public v4 under trusted domains. If necessary I could censor it but I don't think the output is necessary at all since it's an unmodified lxc image.

[theCalcaholic]

Hi, I've finally had a closer look into this and it seems to be a bug with Proxmox's id mapping for unprivileged lxc containers. The LXC image itself has proper ownership for these directories, but the user ids in proxmox are off by one inside the container.

If this issue persists with the latest proxmox (I can't update mine atm, due to a long-running backup-migration process), I'll create an upstream issue.