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.

[Vaskyy]

I just installed with Proxmox Helper Script.
Stopped container.
Added lxc id mapping with bind mount to .conf file.

mp0: /data/ncp,mp=/ncp
lxc.idmap: u 0 100000 33
lxc.idmap: g 0 100000 33
lxc.idmap: u 33 33 1
lxc.idmap: g 33 33 1
lxc.idmap: u 34 100034 65502
lxc.idmap: g 34 100034 65502

Restarted container. Cannot access or change anything anymore.
I also tried to change ownership with only mounted container fs. Also didnt help.

pct mount 117

find /var/lib/lxc/117/rootfs -uid 100033 -type f -exec chown -h 33 {} +
find /var/lib/lxc/117/rootfs -uid 100033 -type d -exec chown -h 33 {} +
find /var/lib/lxc/117/rootfs -uid 100033 -type l -exec chown -h 33 {} +

find /var/lib/lxc/117/rootfs -gid 100033 -type f -exec chgrp -h 33 {} +
find /var/lib/lxc/117/rootfs -gid 100033 -type d -exec chgrp -h 33 {} +
find /var/lib/lxc/117/rootfs -gid 100033 -type l -exec chgrp -h 33 {} +

pct unmount 117

The Id mapping breaks NCP completly, and i cannot repair it anymore.
Only can reinstall, and start over again without id mapping.

[Arouraios]

@Vaskyy But... why?
What you did has nothing to do with the proxmox lxc template, the issue I had concerned only the redis user and only the lxc template and it happened without any kind of modified uid mapping.
According to your comment your nextcloudpi might have worked before you modified the user mapping and was broken after you ran those find chown's. Also afaik the helper scripts use a clean debian (or whatever os you choose) lxc template. Thus I'm pretty sure it's a different issue.
Please let this one year old issue rest in peace, it's likely not even relevant anymore.

PS: I'm purely speculating here, but mapping the www-data user on the host to the www-data user of the container sounds like you're asking for trouble with AppArmor / SELinux or however isolation is enforced in addition to namespaces. I really don't know much about that, so this could not be the issue at all, but if I were you I'd map a different uid and tell php to use that one instead.

[Vaskyy]

Why? Bc it seems to be an permissions issue..
I saw in my log also that redis-server wasnt able to run or smth similar.
And as u might already expect, im not very familiar with all that.
Im following tutorials and if they fail i try to troubleshoot and try to get as much help as i can, since there are SO MANY different reasons of what to do and what not to..

Also the problems started not with chown command, it started with just the user mapping WITHOUT even changing anything.
I only added the lxc mapping to the ID.conf file and restarted the LXC, which instantly resulted in the ncp-web ui being inacessible.
AFTER that i tried again, and read about changing the permissions with mounted container.

I guess ur right with the SELinux permissions or whatever is happening there.
I did user mapping before in different other containers (pelican game server, jellyfin media server), to pass trough a share from host to guest, and the guest being able to write on that.

As far as i understand thats what lxc user id mapping is for!?

And from my understanding the ncp documentation, the www-data user MUST be the one owning the data, otherwise i get trouble with ncp aswell.. ?

I dont have any php or coding experiences. As i said. i follow tuts. If they dont work. I try to fix with my very limited knowledge.

[Arouraios]

@Vaskyy Ah, dang, I think I found your issue. Gimme an ls -al /data/ncp, I bet that folder or its contents are not owned by uid 33.
Anyway, not sure how I missed the fact you rebooted between mapping id's and changing ownership. Doesn't change much tho, ncp not working as uid 33 with all the files being owned by uid 100033 makes sense.

Lastly, even if you had the same symptom (permission issues) that doesn't change the fact your cause is different. I am currently downloading the lxc template again to check if the original lxc bug has been fixed. If so I will close this issue and if you still need help with your ncp I suggest you open a new issue and provide some logs ('redis-server wasn't able to run or smth similar' is not sufficient to determine why your installation is broken).

PS: Ignore what I said earlier about running ncp with a different user, that'll only lead to confusion on an otherwise default setup. However I would still not map any lxc user to a host user that is already in use. Also, whether or not you even need to map a user depends entirely on your setup. There is nothing wrong with creating a folder on the host, chowning it to 100033 and mounting it into the container.
PPS: Vodafone fix your peering, 150kb/s to github is atrocious

[Arouraios]

Issue not present with NextcloudPi_LXC_x86_v1.56.0 and PVE 9.1.1