You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We are using an old Docker buildpack without problems. I am in the process of upgrading to the latest version. I run the docker buildpack in the Google Cloud (Container optimized VM). This means, I do a docker buid... and the resulting image is used in the VM. It's a fairly simple and straightforward setup.
So I have not changed anything to the docker buildpack and I have Mendix up & running succesfully. However, some /xas/ requests fail due to a nginx 500 error.
After looking into the logs I found these kind of logs: "open() "/var/lib/nginx/tmp/client_body/0000000003" failed (13: Permission denied)". So some requests exceed a certain size and nginx uses TMP files for this. These files cannot be created. Looking into the directory permissions of these folders in the docker container I discovered the following:
Directory /var/lib/nginx/tmp is set to 1001:root
Everything within /var/lib/nginx/tmp/* is set to nginx:root
1001 is the user as specified in the Docker buildpack, but appareantly nginx still runs under the user 'nginx'. When I change the ownership (chown) of everything in /var/lib/nginx/tmp/* to user 1001, it still is not working. However, when I change the owner ship of /var/lib/nginx/* to user nginx, the problem is solved.
So I can add a line to my Dockerfile to do "chown -R nginx /var/lib/nginx". That's what I will do for now as it seems to fix all the problems. But I think something must be changed within the Dockerfile (of CF buildpack) to fix this by default.
Any ideas on this and on my temporary fix?
--
Ps. I also noticed that the nginx.conf file that is used for the buildpack (https://github.com/mendix/cf-mendix-buildpack/blob/master/etc/nginx/conf/nginx.conf.j2) does not have a line to specify the nginx USER which usually is on top of the nginx.conf file. That's probably why it's still run as nginx. Which maybe is intended this way, but obviously causes problems with the permissions.
The text was updated successfully, but these errors were encountered:
Hi,
We are using an old Docker buildpack without problems. I am in the process of upgrading to the latest version. I run the docker buildpack in the Google Cloud (Container optimized VM). This means, I do a docker buid... and the resulting image is used in the VM. It's a fairly simple and straightforward setup.
So I have not changed anything to the docker buildpack and I have Mendix up & running succesfully. However, some /xas/ requests fail due to a nginx 500 error.
After looking into the logs I found these kind of logs: "open() "/var/lib/nginx/tmp/client_body/0000000003" failed (13: Permission denied)". So some requests exceed a certain size and nginx uses TMP files for this. These files cannot be created. Looking into the directory permissions of these folders in the docker container I discovered the following:
1001 is the user as specified in the Docker buildpack, but appareantly nginx still runs under the user 'nginx'. When I change the ownership (chown) of everything in /var/lib/nginx/tmp/* to user 1001, it still is not working. However, when I change the owner ship of /var/lib/nginx/* to user nginx, the problem is solved.
So I can add a line to my Dockerfile to do "chown -R nginx /var/lib/nginx". That's what I will do for now as it seems to fix all the problems. But I think something must be changed within the Dockerfile (of CF buildpack) to fix this by default.
Any ideas on this and on my temporary fix?
--
Ps. I also noticed that the nginx.conf file that is used for the buildpack (https://github.com/mendix/cf-mendix-buildpack/blob/master/etc/nginx/conf/nginx.conf.j2) does not have a line to specify the nginx USER which usually is on top of the nginx.conf file. That's probably why it's still run as nginx. Which maybe is intended this way, but obviously causes problems with the permissions.
The text was updated successfully, but these errors were encountered: