Nextcloud with Letsencrypt using OMV and docker-compose - Q&A

Zitat von ToKind

Hi everyone,

in case you want to connect for syncing your Nextcloud with a local LAN connection as well as out of your local LAN ( via duckDNS,spDYN,etc.), the following config adjusting works for me.

To enable a local connection, you have to forward the exposed Docker port 443 (80 if needed) to your wished port - here 444. The Nextcloud config needs little adjustment as well. Add your OMV IP with respective Nextcloud Docker port to the trusted_domain array.

Code

trusted_domains' => 
  array (
    0 => 'your.domain-Nextcloud.com', //here should be your DuckDNS/DNSprovier Domain
    1 => '192.168.2.3:444', //here should be the IP of your OMV with respective Nextcloud docker port forwarding
),

Furthermore, when you follow the provided instructions on how to setup the linuxserver/letsencrypt, you have to add following lines to your Nextcloud config:

Code

# make sure that your dns has a cname set for nextcloud
# assuming this container is called "letsencrypt", edit your nextcloud container's config
# located at /config/www/nextcloud/config/config.php and add the following lines before the ");":
#  'trusted_proxies' => ['letsencrypt'],
#  'overwrite.cli.url' => 'https://nextcloud.your-domain.com/',
#  'overwritehost' => 'nextcloud.your-domain.com',
#  'overwriteprotocol' => 'https',

Here you have to change the 'overwrite.cli.url entry and delet or mark as comment overwritehost in the Nextcloud config:

Code

'overwrite.cli.url' => 'https', //instead of 'https://nextcloud.your-domain.com/'
'overwritehost' => 'nextcloud.your-domain.com', <- delete this line or marks as a comment

Restart your Nextcloud Docker.

Now you should be able to open Nextcloud with your local IP as well with your own domain. But be aware, if you log in locally and share a folder/file, the created link will be with your local IP and therefore not accessible from outside of your network. You can either replace the IP from the created link with your domain

Code

locally created shared link: 
https://192.168.2.3:444/s/jkyY6jP2dnzDdEF
replace the IP with your domain to make link accessible for public:
https://your.domain-Nextcloud.com/s/jkyY6jP2dnzDdEF

or you have to login with your domain on Nextcloud and create the share link from there.

Alles anzeigen

I'm trying to figure this out for a couple of weeks now. It is still not working, though. Could you please share your whole (anonymised) config.cfg? Thanks a lot!

Zitat von Morlan

tThere are already some errors. 80-81 means that you opened a range of ports.

Also I need some more detailed infos. Can you show a screenshot of the options window when press edit of the http-server and https-server?

Did you follow the guide regards the port assignments of the docker containers?

Thanks, I guess I misunderstood how to assign the ports. See attached screenshots for my current setup.

Good news: the previous error messages are gone. The bad news: it's still not working...I get an 'unable to connect' message when I try to connect to 'https://nextcloud.my.duckdns.org'. I also tried with http. That is the address I should use, right?

Looking at docker logs letsencrypt -f, I get error messages for nginx: [emerg] "proxy_max_temp_file_size" directive invalid value in /config/nginx/proxy-confs/nextcloud.subdomain.conf:33. If I check that file, it says proxy_max_temp_file_size 2048m;, which does not look very wrong if I compare to the nginx docs.

Logs for docker logs nextcloud -f give PHP Fatal error: Uncaught Error: Call to a member function getLogger() on null in /config/www/nextcloud/cron.php:162. That does not seem to be causing my problem, but I might be wrong.

Where do I go from here? If it's any use, I've posted my docker-compose.yml here, and my config.php here.

Zitat von macom

Yes (you might add him to ssh and sudo group; depends on 3a/3b)

I needed to add docker1 to the docker group to be able to work with docker. Is that an indication that something is wrong with my installation?

Change it to proxy_max_temp_file_size 1024m;

Zitat von Morlan

Change it to proxy_max_temp_file_size 1024m;

Done. Going forward step by step...Previous error messages gone. Can anyone explain what was the problem here?

But still not working properly...Now when I go to https://nextcloud.my.duckdns.org, I receive

Internal Server Error

The server encountered an internal error and was unable to complete your request.
Please contact the server administrator if this error reappears multiple times, please include the technical details below in your report.
More details can be found in the webserver log.

In the letsencrypt logs, I see nginx: [alert] detected a LuaJIT version which is not OpenResty's; many optimizations will be disabled and performance will be compromised (see https://github.com/openresty/luajit2 for OpenResty's LuaJIT or, even better, consider using the OpenResty releases from https://openresty.org/en/download.html), but at the end of the log it says server ready. Not sure if the LuaJIT error has anything to do with my server error.

The nextcloud logs say PHP Fatal error: Uncaught Error: Call to a member function getLogger() on null in /config/www/nextcloud/cron.php:162

Stack trace:

#0 {main}

thrown in /config/www/nextcloud/cron.php on line 162.

Any suggestions?

The LuaJIT error can be ignored.

So the problem has probaly something to do with your mentioned error message in the nextcloud logs. Does access to Nextcloud still work over the local ip?

Zitat von Morlan

The LuaJIT error can be ignored.

I know that this can be ignored, but curious what this error means?

Zitat von Morlan

The LuaJIT error can be ignored.

So the problem has probaly something to do with your mentioned error message in the nextcloud logs. Does access to Nextcloud still work over the local ip?

I was never able to access nextcloud in any way, locally or over the internet.

To be sure: I should open the local ip of my raspberry pi on port 444 (I configured port sharing for 443 to 444), right ? That doesnt work, nor port 443.

Then there are probably more problems with your Nextcloud container.

Can you show your docker-compose.yml?

Zitat von Morlan

Then there are probably more problems with your Nextcloud container.

Can you show your docker-compose.yml?

My docker-compose file is here, my config file for nextcloud is here. Thanks for all your effort trying to solve this.

I have a question regarding [How-To] onlyoffice in nextcloud docker. This is an excellent guide, but does not have a Q&A, and one cannot reply to the original guide.

I followed the guide and all went as expected other than that the system doesn't work. When browse to nextcloud.mysite.com/onlyoffice it simply redirects to nextcloud.mysite.com (the standard nextcloud default page). I suspect this has something to do with the nginx config files, but I can't work out what. I am, incidently, using a subdomain for nextcloud... I use cloud.mysite.com for nextcloud. The nginx config file in the guide appears to be appropriate for subdirectory rather than subdomain. Any thoughts? Maybe we need a separate thread for a Q&A related to this How-To.

- Andrew

UPDATE:

The OnlyOffice docker image is not compatible with ARM-based single board computers. So, this will not work on Raspberry Pi, Odroid, etc. Maybe this could be added to the original guide.

What happens if you use https://mysite.com/onlyoffice?

------------------------------------------------------------------------------------------------------

Zitat von mtthsdzwn

My docker-compose file is here, my config file for nextcloud is here. Thanks for all your effort trying to solve this.

Is the config.php copied directly ? Because some of the trailing , are missing e.g.

  'overwritehost' => 'nextcloud.my.duckdns.org'
or
    1 => 'nextcloud.my.duckdns.org'

Otherwise your configs look good to me.

https://mysite.com/onlyoffice won't work because mysite.com hosts a commercially-provided website, and I use a subdomain cloud.mysite.com to redirect traffic to a local server for NextCloud. If I browse using the IP address of the PC running OMV https://192.168.xxx.xxx/onlyoffice I get ERR_CONNECTION_REFUSED.

I also had a look at the log from the onlyoffice docker container and It contains:

standard_init_linux.go:211: exec user process caused "exec format error"

Thanks for your suggestion and help... and the help you've provided to so many others too.

Zitat von Kritta

What is the best (correct, or preferred) method for renewing the letsencrypt cert under this setup?

Zitat von Morlan

Should be done automatically

Hello everyone, I successfully have installed NextCloud, MariaDB and LetsEncrypt via your great guide here, almost 3 months ago, using my subdomain (instead of domain/folder/ set-up) with duckdns.org.

But it's time to get Let's Encrypt renewed and I still have a deadline in 7 days; it is still expiring. Not sure how it is supposed to be done automatically, nor do I know how many days in advance this is supposed to happen...

So per the guide, modem/router redirects 80/443 to ports 81 and 444 to OMV & container(s), whist keeping port 80 (internal network) for http access and the actual OMV WebUI.

But when I login to the container docker exec -it letsencrypt /bin/bash and run certbot renew I get the following error (replaced my subdomain with XXXXX):

root@b4166551941a:/# certbot renew
Saving debug log to /var/log/letsencrypt/letsencrypt.log
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/XXXXX.duckdns.org.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Cert is due for renewal, auto-renewing...
Plugins selected: Authenticator standalone, Installer None
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for XXXXX.duckdns.org
Cleaning up challenges
Attempting to renew cert (XXXXX.duckdns.org) from /etc/letsencrypt/renewal/XXXXX.duckdns.org.conf produced an unexpected error: Problem binding to port 80: Could not bind to IPv4 or IPv6. Skipping.
All renewal attempts failed. The following certs could not be renewed:  /etc/letsencrypt/live/XXXXX.duckdns.org/fullchain.pem (failure)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
All renewal attempts failed. The following certs could not be renewed:  /etc/letsencrypt/live/XXXXX.duckdns.org/fullchain.pem (failure)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

I made sure my modem/router has again open port 80->81 (due to many attacks lately, fail2ban went nuts) whilst already using 443->444 to OMV as usual; I can access NextCloud from outside without problems.

I was hoping to avoid deleting the "letsencrypt" container and re-create it, via some separate docker-compose file as I am afraid this may screw up my NextCloud working setup

Can I kindly also ask macom or Morlan for your valuable experience/knowledge? Any help from anyone faced this, is very welcome.

Here are the files I think you may need:

For /appdata/letsencrypt/nginx/proxy-confs/ I copied nextcloud.subdomain.conf.sample as nextcloud.subdomain.conf and changed the subdomain parameter server_name nextcloud.*; to mine: server_name XXXXX.*; of course.

server {
    listen 443 ssl;
    listen [::]:443 ssl;

    server_name XXXXX.*;

    include /config/nginx/ssl.conf;

    client_max_body_size 0;

    location / {
        include /config/nginx/proxy.conf;
        resolver 127.0.0.11 valid=30s;
        set $upstream_nextcloud nextcloud;
        proxy_max_temp_file_size 2048m;
        proxy_pass https://$upstream_nextcloud:443;
    }
}

Then for config.php for NextCloud:

<?php
$CONFIG = array (
  'memcache.local' => '\\OC\\Memcache\\APCu',
  'datadirectory' => '/data',
  'instanceid' => 'XXXXX',
  'passwordsalt' => 'XXXXX',
  'secret' => 'XXXXX',
  'dbtype' => 'mysql',
  'version' => '18.0.4.2',
  'dbname' => 'nextcloud',
  'dbhost' => 'nextclouddb',
  'dbport' => '',
  'dbtableprefix' => 'oc_',
  'mysql.utf8mb4' => true,
  'dbuser' => 'XXXXX',
  'dbpassword' => 'XXXXX',
  'installed' => true,
  'trusted_proxies' => 
  array (
    0 => 'letsencrypt',
  ),
  'trusted_domains' => 
  array (
    0 => 'XXXXX.duckdns.org',
    1 => '192.168.1.200',
  ),
  'overwrite.cli.url' => 'https://XXXXX.duckdns.org/',
  'overwritehost' => 'XXXXX.duckdns.org',
  'overwriteprotocol' => 'https',
  'maintenance' => false,
  'theme' => '',
  'loglevel' => 2,
);

Finally, the part of docker-compose.yml used for Let's Encrypt where ports are redirected (without changing default ports on the NextCloud section):

version: "2"
services:
  nextcloud:
    image: linuxserver/nextcloud
    container_name: nextcloud
    environment:
      - PUID=1000
      - PGID=100
      - HOME=/home/dockeruser
      - TZ=Europe/Paris
    volumes:
      - /appdata/nextcloud/config:/config
    depends_on:
      - mariadb
#    ports:
#      - "450:443"
    restart: unless-stopped
  mariadb:
    image: linuxserver/mariadb
    container_name: nextclouddb
    environment:
      - PUID=1000
      - PGID=100
      - HOME=/home/dockeruser
      - TZ=Europe/Paris
      - MYSQL_ROOT_PASSWORD=XXXXX
    ports:
      - "3306:3306"
    volumes:
      - /appdata/nextclouddb:/config
    restart: unless-stopped
  letsencrypt:
    image: linuxserver/letsencrypt
    container_name: letsencrypt
    cap_add:
      - NET_ADMIN
    environment:
      - PUID=1000
      - PGID=100
      - HOME=/home/dockeruser
      - TZ=Europe/Paris
      - URL=duckdns.org
      - SUBDOMAINS=XXXXX
      - ONLY_SUBDOMAINS=true
      - VALIDATION=http
      - EMAIL=YYYYY@YYYYY
    volumes:
      - /appdata/letsencrypt:/config
    ports:
      - "444:443"
      - "81:80"
    restart: unless-stopped

Thank you everyone in advance.

On the first glance it looks like a port forwarding problem.

Does your letsencrypt.log in /config/log/letsencrypt/ also give this error when you restart the container with docker restart letsencrypt?

Hi Morlan thank you for replying to me, appreciate it. I looked for /config/log/letsencrypt/letsencrypt.log in my main OMV system partition, there is none. Did you mean inside the letsencrypt container after I log in with docker exec -it letsencrypt /bin/bash ?

If yes, then that log is empty (zero bytes). I did restart the docker before accessing it via shell. I paste the contents of zcat letsencrypt.log.2.gz

<------------------------------------------------->
cronjob running on Sat May 2 02:08:00 CEST 2020
Running certbot renew
Saving debug log to /var/log/letsencrypt/letsencrypt.log

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/XXXXX.duckdns.org.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Cert is due for renewal, auto-renewing...
Non-interactive renewal: random delay of 228.37735723322996 seconds
Plugins selected: Authenticator standalone, Installer None
Running pre-hook command: if ps aux | grep [n]ginx: > /dev/null; then s6-svc -d /var/run/s6/services/nginx; fi
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for XXXXX.duckdns.org
Waiting for verification...
Challenge failed for domain XXXXX.duckdns.org
http-01 challenge for XXXXX.duckdns.org
Cleaning up challenges
Attempting to renew cert (XXXXX.duckdns.org) from /etc/letsencrypt/renewal/XXXXX.duckdns.org.conf produced an unexpected error: Some challenges have failed.. Skipping.
All renewal attempts failed. The following certs could not be renewed:
  /etc/letsencrypt/live/XXXXX.duckdns.org/fullchain.pem (failure)

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

All renewal attempts failed. The following certs could not be renewed:
  /etc/letsencrypt/live/XXXXX.duckdns.org/fullchain.pem (failure)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Running post-hook command: if ps aux | grep 's6-supervise nginx' | grep -v grep > /dev/null; then s6-svc -u /var/run/s6/services/nginx; fi;     cd /config/keys/letsencrypt &&     openssl pkcs12 -export -out privkey.pfx -inkey privkey.pem -in cert.pem -certfile chain.pem -passout pass: &&     sleep 1 &&     cat privkey.pem fullchain.pem > priv-fullchain-bundle.pem
1 renew failure(s), 0 parse failure(s)
IMPORTANT NOTES:
 - The following errors were reported by the server:

   Domain: XXXXX.duckdns.org
   Type:   connection
   Detail: Fetching
   http://XXXXX.duckdns.org/.well-known/acme-challenge/f2pLDNrbgh2i_JSzP7B3VwErhPyayrJxHn36W8zSS-o:
   Timeout during connect (likely firewall problem)

   To fix these errors, please make sure that your domain name was
   entered correctly and the DNS A/AAAA record(s) for that domain
   contain(s) the right IP address. Additionally, please check that
   your computer has a publicly routable IP address and that no
   firewalls are preventing the server from communicating with the
   client. If you're using the webroot plugin, you should also verify
   that you are serving files from the webroot path you provided.

As you can see there's no explicit mention of the problem... Seems the same as if I force to certbot renew.

Otherwise, the contents of /var/log/letsencrypt/letsencrypt.log inside the container are much different, as I can see.

Thanks.

Sorry my directions were misleading. I meant the log inside the container.

Also did you triple-check that your port 80 forwarding is correct?

What is the output when you enter the container and then type ./app/le-renew.sh

Thanks Morlan I am puzzled now.

First of all, the redirections worked great all this time, so you would expect (per docker-compose.yml too) to be:

Router from internet 80:443 pushed to 81:444 to OMV (static IP) respectively. Still work great so far.

However, running what you asked prompted to success now? Have a look at the log:

~# docker exec -it letsencrypt /bin/bash
/# ./app/le-renew.sh
<------------------------------------------------->

<------------------------------------------------->
cronjob running on Sun May 10 18:05:55 CEST 2020
Running certbot renew
Saving debug log to /var/log/letsencrypt/letsencrypt.log

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/XXXXX.duckdns.org.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Cert is due for renewal, auto-renewing...
Plugins selected: Authenticator standalone, Installer None
Running pre-hook command: if ps aux | grep [n]ginx: > /dev/null; then s6-svc -d /var/run/s6/services/nginx; fi
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for XXXXX.duckdns.org

Waiting for verification...
Cleaning up challenges
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
new certificate deployed without reload, fullchain is
/etc/letsencrypt/live/XXXXX.duckdns.org/fullchain.pem
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Congratulations, all renewals succeeded. The following certs have been renewed:
  /etc/letsencrypt/live/XXXXX.duckdns.org/fullchain.pem (success)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Running post-hook command: if ps aux | grep 's6-supervise nginx' | grep -v grep > /dev/null; then s6-svc -u /var/run/s6/services/nginx; fi;     cd /config/keys/letsencrypt &&     openssl pkcs12 -export -out privkey.pfx -inkey privkey.pem -in cert.pem -certfile chain.pem -passout pass: &&     sleep 1 &&     cat privkey.pem fullchain.pem > priv-fullchain-bundle.pem

/# certbot certificates

Saving debug log to /var/log/letsencrypt/letsencrypt.log
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Found the following certs:
  Certificate Name: XXXXX.duckdns.org
    Domains: XXXXX.duckdns.org
    Expiry Date: 2020-08-08 15:06:03+00:00 (VALID: 89 days)
    Certificate Path: /etc/letsencrypt/live/XXXXX.duckdns.org/fullchain.pem
    Private Key Path: /etc/letsencrypt/live/XXXXX.duckdns.org/privkey.pem
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

What do you make out of this? Why would ./app/le-renew.sh from within the container work but not certbot renew or the cron ?

How can I validate the cron running in this letsencrypt container? Perhaps there's some syntax or other error on some file, inside the container?

UPDATE: What would you make out of this, Morlan ?

/# more  ./app/le-renew.sh

#!/usr/bin/with-contenv bash
. /config/donoteditthisfile.conf

echo "<------------------------------------------------->"
echo
echo "<------------------------------------------------->"
echo "cronjob running on "$(date)
echo "Running certbot renew"
if [ "$ORIGVALIDATION" = "dns" ] || [ "$ORIGVALIDATION" = "duckdns" ]; then
  certbot -n renew \
    --post-hook "if ps aux | grep [n]ginx: > /dev/null; then s6-svc -h /var/run/s6/services/nginx; fi; \
    cd /config/keys/letsencrypt && \
    openssl pkcs12 -export -out privkey.pfx -inkey privkey.pem -in cert.pem -certfile chain.pem -passout pass: && \
    sleep 1 && \
    cat privkey.pem fullchain.pem > priv-fullchain-bundle.pem"
else
  certbot -n renew \
    --pre-hook "if ps aux | grep [n]ginx: > /dev/null; then s6-svc -d /var/run/s6/services/nginx; fi" \
    --post-hook "if ps aux | grep 's6-supervise nginx' | grep -v grep > /dev/null; then s6-svc -u /var/run/s6/services/nginx; fi; \
    cd /config/keys/letsencrypt && \
    openssl pkcs12 -export -out privkey.pfx -inkey privkey.pem -in cert.pem -certfile chain.pem -passout pass: && \
    sleep 1 && \
    cat privkey.pem fullchain.pem > priv-fullchain-bundle.pem"
fi

/# crontab -l

# do daily/weekly/monthly maintenance
# min   hour    day     month   weekday command
*/15    *       *       *       *       run-parts /etc/periodic/15min
0       *       *       *       *       run-parts /etc/periodic/hourly
0       2       *       *       *       run-parts /etc/periodic/daily
0       3       *       *       6       run-parts /etc/periodic/weekly
0       5       1       *       *       run-parts /etc/periodic/monthly
# renew letsencrypt certs
8       2       *       *       *       /app/le-renew.sh >> /config/log/letsencrypt/letsencrypt.log 2>&1

Thanks!

Well I think certbot renew needs the extra parameter which are provided by the script. That the script failed when run by the cron-job might be due to the fact that you closed port 80 in between (or is this incorrect?).

Indeed, I keep port 80 on my modem/router closed due to multiple attacks, as there is no real need: neither the mobile app nor the MacOS client connect to NextCloud on simple http. I opened it just earlier today.

Side note: Also I point out that the need to go sub-domain setup (with duckdns.org) rather than /nextcloud/ folder is because of the computer (macOS) client that asks a URL during installation and connection of the account(s).

So this means that cron runs each day... OK then I will need to redo the renewal manually via your tip of running ./app/le-renew.sh from within the container OR leave port 80 open for 24h and let the cron re-run successfully, I guess..!

But this also means that this tip/post on the previous page to just run certbot renew in a Docker installation, will most likely fail for some people, better run ./app/le-renew.sh instead, no?

Thank you very much for your time and input, Morlan. I hope others will profit from this and can confirm this too!