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.
Also interestingly this issue did not appear when runnig the ncpi-proxmox-script by tteck. Have you already remedied this issue in v.1.54.2? In that case I think it would be smart to either remove the v1.54.0 x86 lxc image from the github release or at the very least mention this as a known issue.
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.
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:
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.
Also interestingly this issue did not appear when runnig the ncpi-proxmox-script by tteck. Have you already remedied this issue in v.1.54.2? In that case I think it would be smart to either remove the v1.54.0 x86 lxc image from the github release or at the very least mention this as a known issue.
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.