nextcloud
NCPI 1.54.0 x86 LXC image: redis does not start due to faulty ownership
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.
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.
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.
@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.