Problem with Plesk on LXC Container
- Thread starter sysbitnet
- Start date
I have exaclty the same issue. This seems to be caused by the setting „unprivileged container“. Enabled features: nesting and create device nodes.
But many users have successfully installed Plesk on an unprivileged container without these issues. Can somebody give a hint how to achieve that? Switching to „priviledged“ container is not what I prefer..
But many users have successfully installed Plesk on an unprivileged container without these issues. Can somebody give a hint how to achieve that? Switching to „priviledged“ container is not what I prefer..
After long testing I think this problem is so long here, and only when it is installed on Container. When installing Plesk on VM type does not get any error.
I get the same error and problem as before but for the community, I uploaded a screenshot, for the future if someone gets the same error.
So a little more analysis and someone of explanation from my side can be like.
Container Isolation:
Containers are designed to provide isolated environments. They do this, in part, by limiting the container's ability to interact with certain system-level resources. This can include restrictions on modifying device files in /dev.
Ownership and Permissions in Containers:
The ownership of these device files as nobody:nogroup in LXC container is likely a security and isolation feature of LXC. It prevents containerized applications from inadvertently or maliciously affecting these critical system files, which could impact both the container and the host system.
Managing Changes in Containers:
If need to change the ownership or permissions of these files within the LXC container, it's typically done via container configuration settings rather than direct manipulation within the container. This is because changes within the container can be restricted or overridden by the container management system.
Potential Implications of Changes:
Attempting to forcibly change the ownership of these device files within the LXC container might not be advisable. It could lead to unexpected behavior or stability issues within the container. The configuration set by LXC is usually optimized for both functionality and security.
Consulting Documentation and Support:
For specific needs or configurations, consult the LXC documentation or relevant support forums. If there is a specific requirement for these device files to have root:root ownership within the container, there might be a recommended method for achieving this within the scope of LXC's configuration capabilities.
In summary, the difference in ownership of /dev/null, /dev/random, and /dev/urandom between the standard Debian / Ubuntu or Almalinux / RockyLinux server and the LXC container is due to the differing nature and security models of standalone systems versus containerized environments. Changes to these files within the container should be handled cautiously and ideally through LXC's configuration mechanisms.
But the problem that Plesk has i hope can be fixed because after testing all versions that is available and Plesk support, i get the same error on fresh Plesk installation. On image what i attach you can see, and where is the problem.
As i said i testing on all support OS in this moment what you see on the official Plesk https://docs.plesk.com/release-notes/obsidian/software-requirements/
And if you scroll down you can see
I get the same error and problem as before but for the community, I uploaded a screenshot, for the future if someone gets the same error.
So a little more analysis and someone of explanation from my side can be like.
Container Isolation:
Containers are designed to provide isolated environments. They do this, in part, by limiting the container's ability to interact with certain system-level resources. This can include restrictions on modifying device files in /dev.
Ownership and Permissions in Containers:
The ownership of these device files as nobody:nogroup in LXC container is likely a security and isolation feature of LXC. It prevents containerized applications from inadvertently or maliciously affecting these critical system files, which could impact both the container and the host system.
Managing Changes in Containers:
If need to change the ownership or permissions of these files within the LXC container, it's typically done via container configuration settings rather than direct manipulation within the container. This is because changes within the container can be restricted or overridden by the container management system.
Potential Implications of Changes:
Attempting to forcibly change the ownership of these device files within the LXC container might not be advisable. It could lead to unexpected behavior or stability issues within the container. The configuration set by LXC is usually optimized for both functionality and security.
Consulting Documentation and Support:
For specific needs or configurations, consult the LXC documentation or relevant support forums. If there is a specific requirement for these device files to have root:root ownership within the container, there might be a recommended method for achieving this within the scope of LXC's configuration capabilities.
In summary, the difference in ownership of /dev/null, /dev/random, and /dev/urandom between the standard Debian / Ubuntu or Almalinux / RockyLinux server and the LXC container is due to the differing nature and security models of standalone systems versus containerized environments. Changes to these files within the container should be handled cautiously and ideally through LXC's configuration mechanisms.
But the problem that Plesk has i hope can be fixed because after testing all versions that is available and Plesk support, i get the same error on fresh Plesk installation. On image what i attach you can see, and where is the problem.
As i said i testing on all support OS in this moment what you see on the official Plesk https://docs.plesk.com/release-notes/obsidian/software-requirements/
And if you scroll down you can see
Supported virtualization
The following virtualization platforms are supported:- VMware
- XEN
- Virtuozzo 7
- OpenVZ
- KVM
- Hyper-V
- LXC (Docker)
Attachments
Last edited:
I work for an ISP and explored this for our hosting. I switched all our shared hosting servers from dedicated hardware to a PVE cluster with privileged Linux containers a couple of years ago, with unprivileged having these problems. I landed back here after testing the latest Plesk again and it still having mostly the same problems - albeit much less now, it seems only a couple of things are caught up on the nobody:nobody devices.
I have recently noticed an increase in odd "permission denied" failure cases. Turns out, a lot of them are related to app_armor and unprivileged containers. I think, there might have been changes to the kernel that tighten security where that previously wasn't the case. Once you know what the root cause is, there usually is a way to work around it. This might involve enabling/disabling app_armor profiles, or it might require switching to privileged containers. Although, honestly, even when things look really confusing, I have so far always been able to make everything work with unprivileged containers.