Ssl error 0200100d system library fopen permission denied fopen

nginx не читает ssl key

Внезапно всё сломалось и nginx выдаёт ошибку

делал su на юзера nginx, файл, как и ожидалось, можно открыть без проблем.

Всё работало без проблем. Единственное, на что грешу, какой-нибудь апдейт мог принести какую-нибудь selinux конфигурацию, я в этом ничего не понимаю. Больше мыслей нет. Делал даже chmod 777 на этот файл, всё равно ругается. Сертификат не просрочен.

Так selinux включен или нет?

Уверен, что nginx не сбрасывает сам себе дополнительные группы после запуска?

На случай с selinux, если ты уверен, что директория с ключом правильная, то можешь сделать

Ну и логи надо посмотреть, да.

Без понятия, наверное включен. Centos 6.6 стоит с автообновлениями. Ничего, связанного с SELinux я сам не делал, ни включал, ни выключал.

Уверен, что nginx не сбрасывает сам себе дополнительные группы после запуска?

Я не знаю, что значит «сбрасывать группы». Пользователя сбрасывает с root-а на nginx. У пользователя nginx есть группа sslkey. Впрочем с 777 правами всё точно так же не работает, поэтому дело скорее всего не в этом.

На случай с selinux, если ты уверен, что директория с ключом правильная, то можешь сделать

nginx стартует. Правда отвалились другие вещи, но это уже надо отдельно разбираться.

Спасибо за решение. Теперь вопрос — почему так случилось и что делать, чтобы в дальнейшем не случалось?

2014/10/31 22:32:13 [crit] 8135#0: *2 connect() to 127.0.0.1:20002 failed (13: Permission denied) while connecting to upstream, client: 81.4.110.134, server: mysite.com, request: «GET /jira HTTP/1.1», upstream: «http://127.0.0.1:20002/jira», host: «corp.f5-group.com»

блин, чего-то этот SELinux мне натворил, похоже. Надо будет его отключить к чертям собачьим.

В /etc/selinux/config поменял опцию на SELINUX=permissive , перезагрузился, всё заработало.

Теперь вопрос — почему так случилось и что делать, чтобы в дальнейшем не случалось?

Потому что администратор сгенерил ключ в своём хомяке, а затем сделал mv вместо cp и перенёс файл вместе со старым контекстом (admin_home_t), который для огороженных сетевых демонов зашквар.

setenforce 0 => проверяешь осталась ли проблема => setenforce 1 => чинишь контексты на своих портах и файлах. Но дело хозяйское, конечно. Кому-то и iptables проще отключить, чем голову ломать.

Мне всю жизнь хватало стандартных юниксовых прав, будет время — изучу этот selinux, пока он мне не нужен. Тут не только с файлами проблема, он ещё и к апачу не мог подключиться на локалхосте (nginx как reverse proxy настроен).

Источник

How to fix the error: Failed to start slapd TLS: error:0200100D:system library:fopen:Permission denied bss file.c

Contents

Purpose

Doing a zmcontrol restart or zmcontrol start you obtain the next error:

Resolution

This problem is related to the privileges, try to run the next command to fix the privileges: As root

Additional Content

• A Community thread about the error, in this case the fix was manually changing the permissions of some files to zimbra:zimbra, but is much better use the zmfixperms tool.

Try Zimbra Collaboration with a 60-day free trial.
Get it now »

Want to get involved?

You can contribute in the Community, Wiki, Code, or development of Zimlets.
Find out more. »

Other help Resources

Looking for a Video?

Visit our YouTube channel to get the latest webinars, technology news, product overviews, and so much more.
Go to the YouTube channel »

Источник

mosquitto v2.0.3 on Ubuntu can’t access certificates, despite seemingly correct permissions #1972

I’ve upgraded to v2.x and read that mosquitto no longer reads certs as root before dropping to a less privileged user, however, I can’t seem to get permissions right to work with this change.

I started with the certs all owned by root:www-data, and when that didn’t work I made my certs owned by mosquitto:www-data and still doesn’t work (mosquitto is also a member of the www-data group).

It seems like the app isn’t actually running as the mosquitto user, but it exits so fast I can’t watch what’s happening. Can anyone help? This seems like it should be easy, but just can’t get it working.

Here’s some output trying various owners/groups and still getting the same permission issues:

For reference, here’s my config file:

The text was updated successfully, but these errors were encountered:

Thanks for all the details. I’m not sure about the easyrsa case, but for the letsencrypt certificates, the whole path is inaccessible by anything but the root user, it isn’t just the certificates. This is intentional, and not something that you should try to weaken.

Instead, I would suggest using a certbot renewal hook to copy the certificates to somewhere that the Mosquitto user has access to, but no other users do.

I hope that helps.

I played around a bit more tonight and took your advice to copy the certs to an alternate location, however, that really didn’t solve the problem.

I found that the only way mosquitto will run is if the certs and the ca_certificates file permissions are set to 0700. If the files are 0600, it fails, with «permission denied». All the certs are owned by mosquitto:www-data

Why would execute permission be needed on any of the certs?

see startup output and permissions tried below:

Источник

Vesta Control Panel — Forum

I do not receive Gmail emails

I do not receive Gmail emails

Post by Nodsert » Mon Dec 16, 2013 11:04 am

I am having problems with the mail, and I get emails from domains like hotmail, yahoo and others but not the receipt of gmail.

The mail process works properly. What can be the problem?

A greeting and thanks

Re: I do not receive Gmail emails

Post by hrabbit » Mon Dec 16, 2013 12:53 pm

Might need to provide some maillogs outlining the specifics in order to get more help with that issue.
These are normally in /var/log/exim4/ (Sanitise before you post that info).

Re: I do not receive Gmail emails

Post by Nodsert » Mon Dec 16, 2013 1:03 pm

exim4 directory does not exist, is maillog log but there is no information describing the problem

Re: I do not receive Gmail emails

Post by Nodsert » Mon Dec 16, 2013 1:37 pm

I found the log, here I leave:

Re: I do not receive Gmail emails

Post by skid » Wed Dec 18, 2013 9:18 pm

Re: I do not receive Gmail emails

Post by JQuantum » Wed Mar 12, 2014 6:00 pm

Hi, I had this problem.

main.log kept giving a TLS error for google.

something like this. I was using a custom self-signed certificate to move away from the default vestacp one.

Change the permissions to 644 and it’s working now. finally.

Oh only needed to chmod 644 to the /etc/pki/tls/certs/exim.pem (or whatever the path to your .crt file). On second thought maybe it’s because the file is owned by root now (maybe it was owned by exim before).

EDIT: Just switched the permissions to 400 (chmod 400 ) and switched hte ownership to exim:exim and it is still working.

Re: I do not receive Gmail emails

Post by cabbagetree » Sun Jan 31, 2016 8:13 am

The gmail ports are not added to firwall and thus you need to do the following

You need to go to vesta Panel > Firewall

Update the / SMTP to 25,465,587,2525
Update the / POP3 to 110,995,465
Update the / IMAP to 143,465,993

Re: I do not receive Gmail emails

Post by mlopez » Fri Feb 22, 2019 8:26 pm

Hi, I had this problem.

main.log kept giving a TLS error for google.

something like this. I was using a custom self-signed certificate to move away from the default vestacp one.

Change the permissions to 644 and it’s working now. finally.

Oh only needed to chmod 644 to the /etc/pki/tls/certs/exim.pem (or whatever the path to your .crt file). On second thought maybe it’s because the file is owned by root now (maybe it was owned by exim before).

EDIT: Just switched the permissions to 400 (chmod 400 ) and switched hte ownership to exim:exim and it is still working.

Re: I do not receive Gmail emails

Post by Emohlyni » Wed Feb 27, 2019 2:12 am

Hi, I had this problem.

main.log kept giving a TLS error for google.

something like this. I was using a custom self-signed certificate to move away from the default vestacp one.

Change the permissions to 644 and it’s working now. finally.

Oh only needed to chmod 644 to the /etc/pki/tls/certs/exim.pem (or whatever the path to your .crt file). On second thought maybe it’s because the file is owned by root now (maybe it was owned by exim before).

EDIT: Just switched the permissions to 400 (chmod 400 ) and switched hte ownership to exim:exim and it is still working.

Источник

Ssl error 0200100d system library fopen permission denied fopen

I recently re-installed Ubuntu 11.04. Previously, I had openVPN client set up and it connected fine. After re-installing ubuntu, I am unable to connect to the VPN server.

I imported the configuration, keys, and certificates just fine. But when I use Network Manager to connect to the VPN, it says «VPN Connection Failed».

Checking my syslog, I see the following output:

Aug 3 11:57:11 BlackBox NetworkManager[1061]: Starting VPN service ‘openvpn’.
Aug 3 11:57:11 BlackBox NetworkManager[1061]: VPN service ‘openvpn’ started (org.freedesktop.NetworkManager.openvpn), PID 2820
Aug 3 11:57:11 BlackBox NetworkManager[1061]: VPN service ‘openvpn’ appeared; activating connections
Aug 3 11:57:11 BlackBox NetworkManager[1061]: VPN plugin state changed: 1
Aug 3 11:57:11 BlackBox NetworkManager[1061]: VPN plugin state changed: 3
Aug 3 11:57:11 BlackBox nm-openvpn[2823]: OpenVPN 2.1.3 x86_64-pc-linux-gnu [SSL] [LZO2] [EPOLL] [PKCS11] [MH] [PF_INET6] [eurephia] built on Mar 11 2011
Aug 3 11:57:11 BlackBox NetworkManager[1061]: VPN connection ‘018 us — WASH DC METRO’ (Connect) reply received.
Aug 3 11:57:11 BlackBox nm-openvpn[2823]: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Aug 3 11:57:11 BlackBox nm-openvpn[2823]: NOTE: the current —script-security setting may allow this configuration to call user-defined scripts
Aug 3 11:57:11 BlackBox nm-openvpn[2823]: Cannot load certificate file /media/Garbage/DropBomb/Documents/computer/Witopia/Daniel_Staples.crt: error:0200100D:system library:fopen: Permission denied: error:20074002:BIO routines:FILE_CTRL:system lib: error:140AD002:SSL routines:SSL_CTX_use_certificate_file:system lib
Aug 3 11:57:11 BlackBox nm-openvpn[2823]: Exiting
Aug 3 11:57:11 BlackBox NetworkManager[1061]: VPN plugin failed: 1
Aug 3 11:57:11 BlackBox NetworkManager[1061]: VPN plugin state changed: 6
Aug 3 11:57:11 BlackBox NetworkManager[1061]: VPN plugin state change reason: 0
Aug 3 11:57:11 BlackBox NetworkManager[1061]: error disconnecting VPN: Could not process the request because no VPN connection was active.
Aug 3 11:57:11 BlackBox NetworkManager[1061]: Policy set ‘Auto akpress’ (wlan0) as default for IPv4 routing and DNS.
Aug 3 11:57:17 BlackBox NetworkManager[1061]: VPN service ‘openvpn’ disappearedThe «Permission Denied» looks like the problematic part. I’m not sure what the permission problem is, my keys and certificates all have the correct permissions, as far as I can tell.

whatever user that openvpn is running at needs to have read perms for that file. so if the file is 600 or 700 it probably won’t work since openvpn usually runs as root.

Can you post the output of the following command?

Here is the output:

$ ll /media/Garbage/DropBomb/Documents/computer/Witopia/Daniel_Staples.crt
-rwxr—r— 1 danarky danarky 1539 2011-06-04 20:55 /media/Garbage/DropBomb/Documents/computer/Witopia/Daniel_Staples.crt*

you can do it from the server or client.

For example, my config file looks something like:

log-append servers/openvpn.log
verb 3

log-append is where it will write the log and it will just keep adding to the end of the log file. verb is the verbosity of the logging — the higher the number the more detail. 3 is a good number for the most common issues that keep a vpn from connecting.

Here’s another question — do you have your private key password protected? That may be your issue.

Unfortunately I do not manage the servers I am trying to connect to, so I cannot see their config files. However, I don’t see ‘log-append’ or ‘verb’ in any of the openvpn config files on my computer, so I’m not sure how to change the verbosity.

Also my keys are not password protected. The file permissions are -rwxr—r—, both owner and group are «danarky» (my username).

Maybe should I uninstall openvpn, remove any leftover config files, and re-install?

Источник

nginx не читает ssl key

Внезапно всё сломалось и nginx выдаёт ошибку

делал su на юзера nginx, файл, как и ожидалось, можно открыть без проблем.

Всё работало без проблем. Единственное, на что грешу, какой-нибудь апдейт мог принести какую-нибудь selinux конфигурацию, я в этом ничего не понимаю. Больше мыслей нет. Делал даже chmod 777 на этот файл, всё равно ругается. Сертификат не просрочен.

Так selinux включен или нет?

Уверен, что nginx не сбрасывает сам себе дополнительные группы после запуска?

На случай с selinux, если ты уверен, что директория с ключом правильная, то можешь сделать

Ну и логи надо посмотреть, да.

Без понятия, наверное включен. Centos 6.6 стоит с автообновлениями. Ничего, связанного с SELinux я сам не делал, ни включал, ни выключал.

Уверен, что nginx не сбрасывает сам себе дополнительные группы после запуска?

Я не знаю, что значит «сбрасывать группы». Пользователя сбрасывает с root-а на nginx. У пользователя nginx есть группа sslkey. Впрочем с 777 правами всё точно так же не работает, поэтому дело скорее всего не в этом.

На случай с selinux, если ты уверен, что директория с ключом правильная, то можешь сделать

nginx стартует. Правда отвалились другие вещи, но это уже надо отдельно разбираться.

Спасибо за решение. Теперь вопрос — почему так случилось и что делать, чтобы в дальнейшем не случалось?

2014/10/31 22:32:13 [crit] 8135#0: *2 connect() to 127.0.0.1:20002 failed (13: Permission denied) while connecting to upstream, client: 81.4.110.134, server: mysite.com, request: «GET /jira HTTP/1.1», upstream: «http://127.0.0.1:20002/jira», host: «corp.f5-group.com»

блин, чего-то этот SELinux мне натворил, похоже. Надо будет его отключить к чертям собачьим.

В /etc/selinux/config поменял опцию на SELINUX=permissive , перезагрузился, всё заработало.

Теперь вопрос — почему так случилось и что делать, чтобы в дальнейшем не случалось?

Потому что администратор сгенерил ключ в своём хомяке, а затем сделал mv вместо cp и перенёс файл вместе со старым контекстом (admin_home_t), который для огороженных сетевых демонов зашквар.

setenforce 0 => проверяешь осталась ли проблема => setenforce 1 => чинишь контексты на своих портах и файлах. Но дело хозяйское, конечно. Кому-то и iptables проще отключить, чем голову ломать.

Мне всю жизнь хватало стандартных юниксовых прав, будет время — изучу этот selinux, пока он мне не нужен. Тут не только с файлами проблема, он ещё и к апачу не мог подключиться на локалхосте (nginx как reverse proxy настроен).

Источник

nginx won’t reload: SSL_CTX_use_certificate_chain_file failed

I was trying to increase client_max_body_size limits in my nginx.conf file, but after executing service nginx restart , the system returned an error:

I have no idea what might be the issue. Can somebody please help me? Thank you!

Some solutions suggest to check sestatus -v — but all I get is sestatus: command not found

I’m on Ubuntu 12.04.5 LTS.

1 Answer 1

The most important part of the error message is fopen:Permission denied error:. It means that nginx server (which is usually running as nginx user) can’t access certificate file in /etc/letsencrypt/live/mywebsiteaddress.com/fullchain.pem

As you already tested permissions of the file (its 0777), it probably means that nginx can’t enter the directories on path.

You should check permissions on /etc/letsencrypt/live/mywebsiteaddress.com/ , /etc/letsencrypt/live/ and /etc/letsencrypt/ to verify that nginx can enter the directories (check this answer for details).

If the directories don’t have user nor group set to nginx, you can add the enter directory permission to others with

If some of directories on the path are owned by nginx group (which probably should be), you should add enter directory permission to group with

Other reasons which can generate permission defined are SELinux (but this is unprobable in Ubuntu 12 and you already checked it), chroot, and many others but these are also unprobable (and you would probably mention using some special configuration).

Источник

nginx config using variable in ssl_certificate path throws permissions error

The nginx configuration server block:

This is using the variable $ssl_server_name in the certificate directives which is supported since nginx 1.15.9. Relevant part of the nginx docs.

The configuration passes nginx -t and loads without issues, but page does not load in browser, and there is a permissions denied error opening the cert in error.log even though nginx is running as root:

When I replace $ssl_server_name with the domain name in the nginx configuration then there is no permissions error reading the very same cert file, and the page loads in the browser.

Why does using the variable in the cert path not work?

I updated the archive folder group to www-data, still seing the permissions error:

Added group read and execute permissions to archive folder, still seing the permissions error:

Tried becoming www-data using sudo but got an error:

I also updated the permissions on the symlinked path live folder, still seing the permissions error:

Listing the permissions of all dirs in path including symlinks:

Tried temporarily changing the shell for www-data user, became www-data using sudo and tested reading the cert was possible, but the permission error is still happening:

Tried exporting the certs to another folder:

Then decided to check again as the www-data user because last time I checked it was when the certs were in the letsencrypt folder, also this time I remembered to check both cert and key:

Once I addd the group read permission for www-data to the privkey.pem, the browser was able to load the page. 🙂

Thanks to all that commented on this question.

1 Answer 1

OK, thanks for feedback in comment. Let me share two ideas — not directly solution on what you have mentioned but possible workarounds.

prepare instead of linking

I am using in some specific case certbot (I guess the same as you) and haproxy . I have cron job running certbot with certonly and in case the cert is issued it is concatenating cert and key (one file is preferred) and copy out to location where haproxy expect it in configuration. The haproxy is restarted afterwards. In case you will not solve it and need to have it working may be try to «prepare» the cert for nginx somewhere instead of linking to the «original» location.

Источник

mosquitto v2.0.3 on Ubuntu can’t access certificates, despite seemingly correct permissions #1972

Comments

numericOverflow commented Dec 21, 2020

I’ve upgraded to v2.x and read that mosquitto no longer reads certs as root before dropping to a less privileged user, however, I can’t seem to get permissions right to work with this change.

I started with the certs all owned by root:www-data, and when that didn’t work I made my certs owned by mosquitto:www-data and still doesn’t work (mosquitto is also a member of the www-data group).

It seems like the app isn’t actually running as the mosquitto user, but it exits so fast I can’t watch what’s happening. Can anyone help? This seems like it should be easy, but just can’t get it working.

Here’s some output trying various owners/groups and still getting the same permission issues:

For reference, here’s my config file:

The text was updated successfully, but these errors were encountered:

ralight commented Dec 21, 2020

Thanks for all the details. I’m not sure about the easyrsa case, but for the letsencrypt certificates, the whole path is inaccessible by anything but the root user, it isn’t just the certificates. This is intentional, and not something that you should try to weaken.

Instead, I would suggest using a certbot renewal hook to copy the certificates to somewhere that the Mosquitto user has access to, but no other users do.

I hope that helps.

numericOverflow commented Dec 22, 2020

I played around a bit more tonight and took your advice to copy the certs to an alternate location, however, that really didn’t solve the problem.

I found that the only way mosquitto will run is if the certs and the ca_certificates file permissions are set to 0700. If the files are 0600, it fails, with «permission denied». All the certs are owned by mosquitto:www-data

Why would execute permission be needed on any of the certs?

see startup output and permissions tried below:

Источник

raddb/certs/bootstrap creates server-unreadable key files in absence of make #2223

Comments

mzabaluev commented May 4, 2018 •

Issue type

• Defect — Crash or memory corruption.
• Defect — Non compliance with a standards document, or incorrect API usage.
• Defect — Unexpected behaviour (obvious or verified by project member).
• Feature request.

Defect/Feature description

How to reproduce issue

Run the bootstrap script in an environment that does not have make (e.g. a container).

With Docker, this should be reproducible by building an image from this Dockerfile:

Then try to run radiusd in the same environment.

Output of [radiusd|freeradius] -X showing issue occurring

Probable cause

The bootstrap script sets umask 027 before generating the files. When there is a workable make to delegate the work to, the Makefile actions take care to set usable permissions.

The text was updated successfully, but these errors were encountered:

mzabaluev commented May 4, 2018

Actually, the umask is correct, it’s likely the newly tightened openssl tool behavior.

alandekok commented May 4, 2018

What permissions does OpenSSL set?

mzabaluev commented May 4, 2018

What permissions does OpenSSL set?

In Fedora 28, it appears to set 0600 for private keys and similar, and 0640 for public certificates.

alandekok commented May 7, 2018

OK, the issue is that for security, the config files are owned by root , but readable by the radiusd user. OpenSSL also wants to be secure, so it makes the «secret» data readable only by the current user.

The short solution is to just chmod them after the files have been created.

We can fix the scripts on our end, but there’s likely work to do on the RedHat packages, too. Please also file a bug report with them and reference this one.

alandekok commented May 7, 2018

See also commit 29add13, which fixed this. At this point, there’s nothing more to do on our end.

Fedora has to update it’s docker images to not be broken.

dozo2 commented Jul 10, 2019

HI ! please help me i ‘ve this in my freeradius output

tls: Failed reading certificate file «/etc/freeradius/3.0/certs/server@gmail.com-cert.pem»
tls: error:0200100D:system library:fopen:Permission denied
tls: error:20074002:BIO routines:file_ctrl:system lib
tls: error:140DC002:SSL routines:use_certificate_chain_file:system lib
rlm_eap_tls: Failed initializing SSL context
rlm_eap (EAP): Failed to initialise rlm_eap_tls
/etc/freeradius/3.0/mods-enabled/eap[14]: Instantiation failed for module «eap»

mcnewton commented Jul 10, 2019

@dozo2 questions belong on the freeradius-users mailing list. Your certificate file permissions are set incorrectly, as the error says.

Footer

© 2023 GitHub, Inc.

You can’t perform that action at this time.

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.

Источник

Helm Chart Version: 2.13.0
Nginx Ingress Controller Version: v0.35.0
Kubernetes Version: v1.15.12
Docker Version: v18.09.9

Controller was deployed about 300d ago w/o any interruption, and, then, suddenly, the deployment/pod started failing with the initial error described.

It is able to partially start with runAsUser set to 0 (root); however, it eventually fails trying to chown a tmp file.

I0726 20:14:08.897721       7 main.go:105] SSL fake certificate created /etc/ingress-controller/ssl/default-fake-certificate.pem
I0726 20:14:08.905766       7 ssl.go:528] loading tls certificate from certificate path /usr/local/certificates/cert and key path /usr/local/certificates/key
I0726 20:14:08.946139       7 nginx.go:263] Starting NGINX Ingress controller
...
Error: exit status 1
nginx: the configuration file /tmp/nginx-cfg213950217 syntax is ok
2021/07/26 20:14:16 [emerg] 55#55: chown("/tmp/client-body", 101) failed (1: Operation not permitted)
nginx: [emerg] chown("/tmp/client-body", 101) failed (1: Operation not permitted)
nginx: configuration file /tmp/nginx-cfg213950217 test failed

/etc/nginx # stat /tmp/client-body
  File: /tmp/client-body
  Size: 4096      	Blocks: 8          IO Block: 4096   directory
Device: 300020h/3145760d	Inode: 12389077    Links: 2
Access: (0700/drwx------)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2021-07-26 20:18:27.000000000
Modify: 2021-07-26 20:17:42.000000000
Change: 2021-07-26 20:17:42.000000000

If I add the CHOWN capability to the securityContext, exec into the pod, and then perform a chown -R 101:101 /etc/ingress-controller, things start flowing temporarily, but, then, it fails loading again shortly thereafter:

I0727 15:39:53.689868       7 status.go:275] updating Ingress ... status from [{10.1.0.61 }] to []
I0727 15:39:55.891559       7 nginx.go:388] Stopping admission controller
I0727 15:39:55.891637       7 nginx.go:396] Stopping NGINX process
E0727 15:39:55.891675       7 nginx.go:329] http: Server closed
2021/07/27 15:39:55 [emerg] 73#73: cannot load certificate "/etc/ingress-controller/ssl/default-fake-certificate.pem": BIO_new_file() failed (SSL: error:0200100D:system library:fopen:Permission denied:fopen('/etc/ingress-controller/ssl/default-fake-certificate.pem','r') error:2006D002:BIO routines:BIO_new_file:system lib)

To further workaround this, I added SETGID and SETUID capabilities to the securityContext as well.

        securityContext:
          allowPrivilegeEscalation: true
          capabilities:
            add:
            - NET_BIND_SERVICE
            - CHOWN
            - SETGID
            - SETUID
            drop:
            - ALL
          runAsUser: 0

The deployment is finally «fixed». Any other combination results in the initial failure still. What caused this deployment to go haywire?

Last edited: Mar 5, 2011