Permission error w/ sockets inside CT since migration to PVE 4.1

You need to check the output of dpkg to see if the kernel package is 4.2.6-28, because 4.2.6-26 also displays the same uname. And of course reboot.

Code:
dpkg -l | grep kernel
Of course there is always the possibility that these socket problems are actually unrelated problems requiring a different solution.
 
@datenimperator I did a small hack for now in my gitlab instance like this:

Code:
while true
do
     inotifywait -e create /var/opt/gitlab/gitlab-rails/sockets /var/opt/gitlab/redis /var/opt/gitlab/gitlab-workhorse
     chmod 777 /var/opt/gitlab/gitlab-rails/sockets/gitlab.socket
     chmod 777 /var/opt/gitlab/redis/redis.socket
     chmod 777 /var/opt/gitlab/gitlab-workhorse/socket
done

It's a hack, but at least it make the gitlab instance running temporarly until a real fix is found...
 
  • Like
Reactions: datenimperator
Okay guys, I think I got to the bottom of this socket permissions thing.

What is happening that apparently openVZ didn't support the posix acls in the filesystem or the backup restore inserts posix acls. No matter how they got there, the filesystem now has posix acls enabled.

I tested this with php-fpm on the centos 7 template. If you make a socket config and explicitly tell it to create a mode 666 socket in a /var directory, it still creates a mode 644 socket. And this is just because the default group,other acl in the /var says r-x. Apparently php-fpm doesn't even check what the actually created mode is, which surprises me, but there you have it. Maybe it just sets the umask and assumes that will all work out for the good.

If you create the socket in the /run directory then it has the right mode mask, because it has no posix acl.

You can kill the default posic acl on the directory where you create the socket with:
Code:
setfacl -k /path/to/socketdir
 
So this permissions problem cannot only affect sockets, but also other files. It will be less harmful with normal files because files are usually written to by their owners, and created 644 anyway, but still you have to watch out for it.

The problem I mentioned about postfix is actually a different problem.
 
What is happening that apparently openVZ didn't support the posix acls in the filesystem or the backup restore inserts posix acls. No matter how they got there, the filesystem now has posix acls enabled.

Interesting findings, but how to deal with them? Neither the host nor the container seem to have ACL enabled on their respective file systems. I've restored ~20 OpenVZ containers and each of them now has (probably weird) ACL set all over the place. Should I deleted them all? In fact, can I?

edit: So how many files have ACL now? Here's the gitlab host that I've been referring to:

root@host:~# getfacl -R -s -p / | sed -n 's/^# file: //p' | wc -l
18471


Ouch. 18471 files/directories with ACLs…
 
Last edited:
If you are using ZFS storage, then you can use the method that user bank mentioned earlier in this thread to deactivate posix acls.

Or you can do, ( If you really don't need them :-) ):
Code:
find / -xdev -type d -exec setfacl -k {} \;

Or
Code:
setfacl -b -R /
 
Last edited:
I seem to have the same problem with the Unix socket of MySQL (running kernel 4.2.6-34).
Manual "chmod 777" fixes it until the next restart of the service or the container.
Is the mentioned patch supposed to fix the issue only for postfix?
 
Same here. Host is Proxmox 4.1 with all pve-non-subscription updates installed, rebooted today.

I installed a CentOS6 container with mysql-server and it's creating the unix socket with permissions 0755 which prevents any other (httpd) user from using the socket on that container.
On the same host I have another Ubuntu 14.04 container which has no problems creating the mysqld socket with 0777

How can I fix that issue?
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!