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

    • Offizieller Beitrag

    Skullchuck


    To solve the Portainer issue you can follow these steps. https://wiki.omv-extras.org/do…openmediavault-compose_67


    As for the quick setup guide you followed, I assume you read the beginning of the guide and the conditions for using it. If you are doing this installation on an already configured server, this guide will serve as a reference but you should follow this: https://wiki.omv-extras.org/doku.php?id=omv6:docker_in_omv

  • Thanks for the quick responses.


    KM0201

    Zitat

    You never set a proper data directory for portainer is my guess.

    Unfortunately, that's my guess, as well :(


    Zitat


    Do you still have your old version of portainer installed? (Even if it is not working)

    How would I find this out? I cannot see it anymore in the OMV plugins. Portainer GUI is not reachable anymore (this is how I noticed it at all). A docker container ls does not list portainer or any of the containers that I had before the installation of openmediavault-compose. Btw I'm on 6.9.12-2 (Shaitan).


    chente

    Zitat


    To solve the Portainer issue you can follow these steps. https://wiki.omv-extras.org/do…openmediavault-compose_67

    I can't, because as I wrote above, the portainer data directory either never existed or is gone now.


    Zitat

    As for the quick setup guide you followed, I assume you read the beginning of the guide and the conditions for using it. If you are doing this installation on an already configured server, this guide will serve as a reference but you should follow this: https://wiki.omv-extras.org/doku.php?id=omv6:docker_in_omv

    I'm not sure how this should help? The NPM and the failban containers are up and running. NPM is having a Letsencrypt issue though, as I described above. This is the one I cannot solve ?(


    So from my perspective I can either try to "go backward" (reviving Portainer somehow) or to "go forward" (solving the NPM/Letsencrypt issue). And both directions seem blocked...

    • Offizieller Beitrag

    I can't, because as I wrote above, the portainer data directory either never existed or is gone now.

    If you had Portainer running there was a data folder. I don't know if you have subsequently done anything that could have deleted that folder. If you have deleted that folder it will be difficult to recover Portainer. I would go ahead with configuring containers in the plugin and forgetting about Portainer.

    I'm not sure how this should help? The NPM and the failban containers are up and running. NPM is having a Letsencrypt issue though, as I described above. This is the one I cannot solve

    It's hard to know what's going wrong without seeing your server. That's why I suggested following that guide and basically checking folder paths and permissions, it is the most common failure.

    Nextcloud AIO works with NPM and let's encrypt, I can attest to that.

    • Offizieller Beitrag

    OK, he had we'll say... "a series of unfortunate events"


    Where he stands now...

    Docker is back up and running with his old configs and containers, so portainer, plex, swag, etc.. are good.

    NC is running, but he's getting some errors. Initially it was because he was still on like version 25. So we upgraded to 26, now he's getting some new errors. Unfortunately I'm out of time and am going to be busy probably until at least Wed night.. So if he wants to give you guys a chance to tackle this and post the errors he has, that's where he is, otherwise, I'm gonna hook up again with him probably Wed or Thur night and see if we can't figure out what is wrong with NC. and then clean up a few other things.

    For now, I'd probably suggest he stay on Portainer till the NC issue is sorted out (as he's several versions behind anyway),

  • Thanks again KM0201 for all the great support :thumbup:

    This is the current error message of the nextcloud container:


    And the mariadb container keeps writing:


    Code
    240123 12:06:28 mysqld_safe Logging to '/config/databases/b3506031d05d.err'.
    240123 12:06:28 mysqld_safe Starting mariadbd daemon with databases from /config/databases

    Any ideas?

  • config/databases/b3506031d05d.err says:


    and repeats this every second.


    What I'm asking myself is how is this

    Code
    Can't create/write to file '/var/tmp/ibXXXXXX' (Errcode: 13 "Permission denied")

    even possible? That's a directory within the container, right? How can it not have permissions inside the container?


    I can go inside the container and execute chmod 777 /var/tmp and the container will start successfully (at least until the next deployment). But NC keeps showing me 404 :(

    Einmal editiert, zuletzt von Skullchuck () aus folgendem Grund: Added info

  • So after bare-metal restart, the mariadb container is starting successfully. All containers (nextcloud, mariadb, swag & redis) are now running fine according to the container logs, but the front end still gives me 404. What am I missing?

  • So there was no way to update this container properly. Nobody knows why :|

    I deployed a new stack in portainer with the containers nextcloud1, nextclouddb1 and redis1. Nextcloud was running locally on port 451 and with the help of KM0201 we managed to transfer the user data from the old data directory to the new one.


    Next step was to make it reachable from the internet again by using swag (generally, following this guide). As I already had a nextcloud stack and a Swag stack, I applied the following steps:

    • In my router I forwarded port 80 external to 82 internal and 443 external to 444 internal (it was 443 to 443 before)
    • In the swag stack for the swag container I added under environment
      - DOCKER_MODS=linuxserver/mods:swag-dashboard and under ports: - 444:443- 82:80 - 81:81 and redeployed the stack
    • checked that in /etc/appdata/swag/nginx/proxy-confs there is an nextcloud.subdomain.conf (without .sample). It was like this already and I didn't change anything
    • adapted /etc/appdata/nextcloud1/config/www/nextcloud/config/config.php
    • Uncommented the ##network modes in the nextcloud1 stack and redeployed

    Situation now: domain gives ERR_CONNECTION_REFUSED from inside the network, 502 from outside. https://192.168.0.101:451/, which worked before, also gives ERR_CONNECTION_REFUSED and overwrites the IP with my domain. https://<MY_DOMAIN>.duckdns.org/ shows the SWAG park page, but with invalid certificate.

    Also, by accident, I started the old nextcloud stack once. Nextcloud didn't come up, but mariadb and redis. Hope that didn't break anything. I removed them immediately after realizing.

    Somehow I've got the feeling that I would need to assign port 444 to 451 somewhere inside of swag. I already tried to set

    ports:

    - 444:451

    (instead of 444:443) in the swag stack, but it didn't change anything.


    You can find the config that I changed and the complete portainer stacks attached.


    I hope I just have a silly mistake somewhere and someone here can spot it and point me towards it. I will be offline from now on till at least Sunday night. Maybe someone has some spare time over the weekend? Thanks :)

    • Offizieller Beitrag

    Can you post:


    1. We didn't get to routing it through swag before I went to bed, but can you provide a screenshot of your router port forward settings (i thought on the last one you left it at default 443/80... that swag compose shows otherwise). EDIT: Nevermind, I see you addressed this.


    2. nextcloud.subdomain.conf

  • 1.

    Yes we left it on 443 but I adapted it to the guide because I thought there must be a reason for these ports.


    2.

    This could be it, it's still on 443. But I don't have time to try now...

    • Offizieller Beitrag

    No, the reason it's no longer working is it's forwarding through your domain again from the looks of it, and your domain is not set correctly.


    Note line 16. you have an extra / in there after "nextcloud"


    Code
    'overwrite.cli.url' => 'https://nextcloud/.<ANONYMIZED>.duckdns.org',

    change that to

    Code
    'overwrite.cli.url' => 'https://nextcloud.<ANONYMIZED>.duckdns.org',

    and restart the container. If it still doesn't work, to regain local acess... change that line to:


    Code
    'overwrite.cli.url' => 'https://192.168.0.101:451',

    and restart the container.


    That will restore local access.

    • Offizieller Beitrag

    Line 29. Change that to nextcloud1


    Then save and restart swag.


    We can easily change the names and what not back to nextcloud.. i just didn't want to nuke your old nextcloud install until I knew we had all your data imported into the new install (still not sure why the old one wouldn't upgrade at all)... so the easy button fix was to just add a "1" to everything.


    If you've got all your data imported into the new nextcloud install, you can delete the old NC containers and the old stack you had.

  • Zitat

    Note line 16. you have an extra / in there after "nextcloud"

    This wasn't real – something went wrong when I replaced the domain by <ANONYMIZED>. The line actually already looks like this:

    Code
     'overwrite.cli.url' => 'https://nextcloud.<ANONYMIZED>.duckdns.org',


    In nextcloud.subdomain.conf I changed "set $upstream_app nextcloud;" to set $upstream_app nextcloud1; and restarted both the nextcloud1 and the swag container. The result was that NC is available again under https://192.168.0.101:451/ (but insecure and not replacing the URL), but not under the domain.


    Also, I noticed that the old NC config.php was much more comprehensive, so I added a few sections from the old to the new config (redis config, trusted_proxies and mail config). Now it looks like this:


    The result is still the same, unfortunately.

    • Offizieller Beitrag

    I noticed something in the pic you posted yesterday from (what looks like) Windows. Your NC data folder has a red dash on it. I assume this means it's not writable. Are you sure you aren't having a permission issue with the container being able to write to the data folder? I noticed from your pic, you put it inside a Nextcloud folder, along w/ your config folder. I've had permissions issues in the past doing this, thus why I don't generally do that.


    I'll try to be around Thursday, this week has been nuts.

  • KM0201 pic... Windows.... not sure if you confuse me with someone else?


    These are the permissions of the data folder:


    Code
    drwxrwx--- 8 docker1 users 4096 25. Jan 13:48 data

    If these were wrong, it wouldn't have worked locally before.


    Interestingly, now opening https://192.168.0.101:451/ leads to ERR_CONNECTION_REFUSED again with overwriting the URL. It might be a belated reaction to the new config.php, but actually I'm not aware of changing anything since then... very very strange.

  • Current status:


    This table shows what I changed (config, before, after) and the result (remaining columns)

    configbeforeafter

    domain

    https://192.168.0.101:451/

    domain on phone

    from the internet

    nextcloud.subdomain.conf set $upstream_app nextcloud; set $upstream_app nextcloud1; does not work works, insecure - -
    Tuesday morning initial state does not work does not work works for a while!? -
    /etc/appdata/nextcloud1/config/www/nextcloud/config/config.php 'overwrite.cli.url' => 'https://nextcloud.<ANONYMIZED>.duckdns.org', overwrite.cli.url' => '192.168.0.101:451', does not work does not work works for a while!? -
    hosts 192.168.0.101 nextcloud.<ANONYMIZED>.duckdns.org commented out works for a while!? - works for a while!? works for a while!?


    Some remarks:

    • "-" means I didn't test it
    • I don't know why the "Tuesday morning initial state" is different from before. There's an automated swag restart during the night, maybe this changed something...
    • "works for a while" is the current state --> I have access for 1-3 minutes, then I get ERR_CONNECTION_REFUSED again (WTF!?)
    • "hosts" means the local Windows hosts file on my PC. I had an entry there to prevent routing my local traffic to my ISP and back
  • Zitat
    • "works for a while" is the current state --> I have access for 1-3 minutes, then I get ERR_CONNECTION_REFUSED again (WTF!?)

    Ok this behaviour was apparently caused by the desktop & mobile clients trying to connect to NC with the "old" credentials (I chose the same user name and password, but there seems to be a difference anyway). NC or maybe Fail2Ban probably just blocked the connection from my IP after a while.


    Now the access works locally & from the internet! :love: Finally after almost 2 weeks nightmare....

    It's very interesting though that I set overwrite.cli.url' => '192.168.0.101:451', BUT the access via domain works, also from the internet. NC with Swag remains a mystery for me.


    I just restored my calendar app using https://help.nextcloud.com/t/c…ks-as-ics-vcf-files/11978 and the procedure was a bit different for me:


    1. I stopped all "new" containers related to NC

    2. Commented out everything from the old stack apart from the mariadb section and added the following lines to it:

    Code
       ports:
          - 3306:3306

    3. Deployed the stack

    4. Followed https://codeberg.org/BernieO/c…ncloud-nextcloud-instance

    5. In the /usr/local/bin/nextcloud_dummy/config/config.php I had to set:

    Code
    'dbhost' => '192.168.0.101',  # replace by your local IP
    'dbport' => '3306',

    The container name, "localhost" or "127.0.0.1" did NOT work! Took me a while to figure this out.

    6. Then the script would work and I could download the backup file to my PC via SMB and upload it to the new calendar (old container stopped, new containers started again) via the web GUI


    This might be useful for anyone having to restore calendars and contacts from the Nextcloud database.

  • Hello.


    Succeed to set up a Nextcloud behind Swag/Nginx but I want to use the Swag container/Service for another container : Vaultwarden on vaultwarden.domain.com (http://www.domain.com = Nextcloud).


    I want to use port 8089 with Vaultwarden as port 80 is already used by nextcloud but I don't want to access https://vaultwarden.domain.com:8089, just subdomain/domain directly. Is it possible ?


    I modified a compose.yml file found here : https://linuxiac.com/how-to-in…sword-manager-with-docker to add an "external true" and the name of the network which gives :



    I also used a proxy conf named vaultwarden.subdomain.conf from https://github.com/linuxserver…den.subdomain.conf.sample and modified it :



    Restarted Swag/Nginx and get no error, launched vaultwarden with no error in log.

    Network inspection of nextcloud-swag_default shows vaultwarden container is connected.


    But in the end, https://vaultwarden.domain.com gives nothing.

    I set up a CNAME "vaultwarden.domain.com IN CNAME domain.com" before trying the whole thing.


    Did I miss something ?

  • Ok, solved my problem but for information, he re is a method to use already configured and running SWAG container/network to use it as a reverse proxy for another container.


    I'll describe for subdomain install for a vaultwarden container running on https://vaultwarden.domain.com.


    First, create the CNAME for the subdomain, pointing it to your main domain in your DNS provider (domain hosting provider for me : OVH).

    Wait for 1 to 24 hour (you can ping vaultwarden.domain.com on command line to see if it is resolved to domain.com public IP).

    Mine is "vaultwarden IN CNAME domain.com." if you modify in text mode (do not forget final point).


    You must modify SWAG container (through .yml file, in tutorial, it is the yml file which also set up nextcloud) to load 2 mods and mount the docker.sock volume.


    Here is the result (modifications added in red) :

    Some options are slightly different (I use a wildcard certificat so won't have to regen each time I'll add a container to use this way AND I prefer DNS method, with OVH as a provider, more info on SWAG page directly).


    Restart the container.


    Now for vaultwarden :


    First :read this to understand vaultwarden options put in the YML file : https://linuxiac.com/how-to-in…word-manager-with-docker/


    When subdomain is reachable, you need to create your container, using docker-compose.yml, taken from above page :


    That's all.

    Launch vaultwarden container after the swag container restart and you can access https://vaultwarden.domain.com and create an account.


    I think that for future container you want to connect to the proxy, you just have to add/change the network name to be the swag one + set it true at the end of the file + label swag=enable.


    No more proxy conf.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!