connect() failed (111: Connection refused) while connecting to upstream, client: x.x.x.x, server: , request: "GET /status.php HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "nc.xxxx.com" about helm HOT 9 CLOSED

GlusterFS has the same problem with rsync. Take a look at how to improve rsync performance with GlusterFS here. Also, I recommend changing the initial values for livenessProbe. initialDelaySeconds and readinessProbe.initialDelaySeconds to, at least, 60.

from helm.

I am using NFS with the mountOptions including "async" and my deployment fails like mentioned here and in #10
If I start my deployment with replicaCount: 1 and upgrade it later to 3 it works seamlessly.

from helm.

I am currently not using the helm chart nor the previous setup anymore, so can't tell, sorry

from helm.

No problem! I am going to close this for now, as this issue is a bit stale, but if you choose to use the helm chart again in the future, please feel free to open another issue if you run into any problems.

This goes for anyone else in this thread as well: If you're still having trouble, please feel free to open a new github issue with your current values.yaml and the issue you're seeing and we'll take a look.

Thank you!

from helm.

I had the same problem and it's related to #10. If you're using an NFS volume you have to add async to the mountOptions of storageClass. Also, in the /etc/exports file, the path should have async option too.

from helm.

I don't use NFS but GlusterFS by means of kadalu

from helm.

I'm also faced with this problem. Problem reproduced then i'm trying to specify helm ... --set nginx.enabled=true option. I'm not using NFS, but my pvc based on Openstack Volume. Tried to disable liveness and readiness checks - nothing, this doesn't help at all, i see that container repeatedly fails.

from helm.

I'm also faced with this problem. Problem reproduced then i'm trying to specify helm ... --set nginx.enabled=true option. I'm not using NFS, but my pvc based on Openstack Volume. Tried to disable liveness and readiness checks - nothing, this doesn't help at all, i see that container repeatedly fails.

My mistake, fixed by changing persistence.accessMode value and --set image.tag=fpm for helm

from helm.

This is a very long time delay, but do you still have this issue with the current version of the helm chart?

Since then, we've added a bit of documentation around using nginx here:
https://github.com/nextcloud/helm/tree/master/charts/nextcloud#using-nginx

And we've updated the nginx.conf a bit here:
https://github.com/nextcloud/helm/blob/master/charts/nextcloud/templates/nginx-config.yaml

I was initially getting this issue myself, and I solved it with a few different things. One of the things that helped me was:

  nextcloud:
    configs:
      proxy.config.php: |-
        <?php
        $CONFIG = array (
          'trusted_proxies' => array(
            0 => '127.0.0.1',
            1 => '10.0.0.0/8',
            2 => '192.168.42.50',
            3 => '192.168.42.1'
          ),
          'forwarded_for_headers' => array('HTTP_X_FORWARDED_FOR'),
        );

In the above example, 192.168.42.50 is my pihole, which serves DHCP, and 192.168.42.1 is my router, so you'd want to change those values to your own. I've been meaning to create a PR to make this easier to configure, but haven't gotten a chance yet.

There's also some more nginx documentation here, that may be helpful:
https://docs.nextcloud.com/server/19/admin_manual/installation/nginx.html#nextcloud-in-the-webroot-of-nginx

Let me know if you still have questions though!

As for the NFS issue mentioned further down, it looks like some fixes have been mentioned in #10 that could use some docs if anyone is up for drawing up a PR :)

from helm.