- Plesk Onyx for Linux
Plesk is not accessible with the following error:
PLESK_INFO: [LockManagerException] Can't open or create shared memory by shm.name: "/run/lock/lmlib/SharedLockManagerStorage0.2.3"; shm.start_size: "8388608"; error "Permission denied"
One of the following errors might appear in
CONFIG_TEXT: ERR  Lock Manager error: '[LockManagerException] Can't open or create shared memory by shm.name: "/run/lock/lmlib/SharedLockManagerStorage0.2.3"; shm.start_size: "8388608"; error "Permission denied"'.
CONFIG_TEXT: ERR  Lock Manager error: '[LockManagerException] Can't open or create shared memory by shm.name: "/run/lock/lmlib/SharedLockManagerStorage0.2.4"; shm.start_size: "8388608"; error "No such file or directory"'.
The permissions from
/run/lock/lmlibfile differs from the following:
# stat /run/lock/lmlib
Access: (0770/drwxrwx---) Uid: ( 0/ root) Gid: ( 0/ lock-manager)
Ownership changes back to incorrect after a server reboot.
/run/lock/lmlibis missing from the server.
The virtual server is purchased from an infrastructure provider (e.g. Strato) who uses OpenVZ operating system as a virtualization solution.
Incorrect permissions are set on directories required for Plesk operation on boot.
To create directories and set permissions Plesk uses standard OS methods. Directory
/run/lock/lmlib is created using
system-tmpfiles.d, the component of systemd init system, that creates directories in
/run locations. These locations and the content stored in them are recreated on a server reboot.
There are two 3rd-party bugs which may cause such behavior:
- There is a known bug in systemd package 229-4ubuntu21.9
Patched kernel for VZ was released for this bug but this issue may reoccur on OpenVZ6.
Incorrect ownership on ‘/’ directory in the system https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1811580
Contact your infrastructure provider to make sure that the solution for the first cause is applied.
Resolution for infrastructure owners/providers
Make sure that the following OpenVZ kernel or newer is installed, if OpenVZ is used:
CONFIG_TEXT: 042stab134.7 kernel:
In order to fix the issue, OpenVZ Node kernel must be updated.
Note: The below steps may be done by Plesk professional Services team on a paid basis as an administration service.
In order to work around the issue on Plesk instance side, create a scheduled task that will restore directory structure on reboot:
Log into the server via SSH as a root user.
Create a new Cron task to run after reboot:
# echo '@reboot root mkdir -p /run/lock/lmlib && chown root:lock-manager /run/lock/lmlib && chmod -R 0770 /run/lock/lmlib' > /etc/cron.d/00-restore-lmlib
Reboot the server:
For that situation, it is required to connect to the server in the recovery mode. In the example below, recovery mode of Strato server is described (where original file system is mounted into
Connect to the server in recovery mode
Note: For example, Strato recovery mode can be enabled as follows: How to use RecoveryManager to access the data on your hard drive (Linux server)
Enter the actual container's file system:
# chroot /repair
Note: As an example, location
/repair, typical for Strato is used in this step. The location may differ. To find out the proper location contact the hosting provider.
Create a new reboot-target Cron task:
# echo '@reboot root mkdir -p /run/lock/lmlib; chown root:lock-manager /run/lock/lmlib; chmod -R 0770 /run/lock/lmlib; mkdir -p /var/run/sshd; chmod 0755 /var/run/sshd; /etc/init.d/ssh restart' > /etc/cron.d/00-restore-runfiles
Exit the mounted container's environment:
Reboot the server:
In case after the reboot Plesk is accessible, but SSH is not working, log into Plesk and navigate to Tools & Settings > Scheduled Tasks.
Then add the following command to the 'Command' field:
CONFIG_TEXT: mkdir /var/run/sshd && chmod 0755 /var/run/sshd && /etc/init.d/ssh restart
Press 'Run Now' button: