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

    • Offizieller Beitrag

    I have at this point removed the .conf and edited the .php.file, but when I enter mysubdomain.duckdns.org I reach the OMV admin login page. I reach the swag park page only when I got to https://myomvip:444.


    My edited .php:


    Right... you'll always reach the park page from your local IP.. that's irrelevant. That doesn't really say anything other than the container is running, the fact you can't get to it securely from outside your network says there's a problem. Editing the .conf file is not going to help at this point as swag isn't getting a secure connection for some reason.


    Question... Go to your duckdns page and look at your IP address pointed at your URL


    Now check your server's IP address with the following command and make sure they are the same (if you signed up for duckdns behind a VPN, it's possible these are not matching, which is a problem)


    Code
    wget http://ipecho.net/plain -O - -q ; echo
    • Offizieller Beitrag

    The duckdns and server ip address, after checking with the code you provided in an ssh session, match.


    I suspected that the problem is with my port forwarding or my isp (verizon) blocking access, but if that was the case I would not have received a certificate. I can reach the swag park page at https://myomvip:444, but I cannot figure out why https://mysubdomain.duckdns.org is not working.

    Again, getting the swag park page with your IP address, is irrelevant. That really is just saying the container is running. Yah, if verizon was blocking this, you wouldn't get a key. Did you check if you can get to https://www.mysubdomain.duckdns.org


    Just in case, delete your swag config folder, and restart the swag container and watch the log and see if you get the success message


    If you're getting a key, then I have no idea what could be wrong. I'll go through those instructions again in the morning and see if something has changed.

    • Offizieller Beitrag

    Ok. I will restart and watch the swag log.


    https://www.mysubdomain.duckdns.org results in the forbidden message.


    If the instructions still work it is probably my isp. Thanks.

    If it is your ISP, then you shouldn't get a key, pure and simple.


    Like I said, delete your swag config folder and restart the container, and see if you get the success message that it's pulling a key

  • I confirmed that i am receiving a key, but am still unable to reach https://www.mysubdomain.duckdns.org. Given that you have confirmed that the instructions still work, I cannot figure out where I am going wrong.

    • Offizieller Beitrag

    Now this is interesting, and I have no idea how this is happening... as you can see below, I got a key (note I'm doing this on an OMV 6 virtual machine test I have, but that's irrelevant to this discussion)


    my current IP address for the virtual machine (192.168.1.151)

    Code
    2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
        link/ether 08:00:27:7d:8e:9b brd ff:ff:ff:ff:ff:ff
        inet 192.168.1.151/24 brd 192.168.1.255 scope global dynamic enp0s3
           valid_lft 5798sec preferred_lft 5798sec

    my current router setup (166 is my physical server)

    I can however, get to the swag page, it's just not secured...



    More in the next post.

    • Offizieller Beitrag

    I adjusted my router settings...



    Restarted the swag container and park page works normally.. (note, I switched to Chrome as Firefox decided it wanted to update and I wanted to get this done, but the point still stands)...



    I then finished the walkthrough..



    I'm now convinced it is your port settings (I still have no idea how the hell I got a key in this instance)... can you post a pic of your router settings.

    • Offizieller Beitrag

    Thanks KM0201. I cannot see where I am going wrong. I have fiddled with my router settings, but it has not helped. The current settings are posted below:


    That just makes no sense.


    Check your private messages. I sent you a message.

  • I have narrowed my issue down to something blocking me from accessing swag on my home network. I can access the swag park page when I enter htttps://www.mysubdomain.duckdns.org from outside my network. I just can't figure out what is blocking access from my home network.


    Thanks KM0201 for your tutorial and all of your kind assistance in helping me troubleshoot the issue.

  • Morning All,


    I was just going threw my portainer just to make sure everything is running correctly when i saw this


    has anyone done a guide on how to install this? i've back a few pages on this thread but could see anything.

    Normally if its in red it's bad!!!


    Machine 1 - Dell OptiPlex 790 - Core i5-2400 3.10GHz - 16GB RAM - OMV5

    Machine 2 - Raspberry PI4 - ARMv7 - 2GB - OMV5

    • Offizieller Beitrag

    I just wait and hope that it will upgrade automagically. The message is there for several month. "Soon" is relative ;)

    But I think there is a guide from Soma

  • macom, Thank you I will wait a few more month and see if it updates it self.

    Normally if its in red it's bad!!!


    Machine 1 - Dell OptiPlex 790 - Core i5-2400 3.10GHz - 16GB RAM - OMV5

    Machine 2 - Raspberry PI4 - ARMv7 - 2GB - OMV5

    • Offizieller Beitrag

    macom, Thank you I will wait a few more month and see if it updates it self.

    If you read the docs..


    https://docs.linuxserver.io/images/docker-mariadb


    After making sure everything important was backed up I changed the image tag in my stack, and redeployed.


    I checked the mariadb log, and the message is gone..


    Then I checked the container to see what image it was using...



    So it seems mariadb is now running on the alpine image (and I also checked nextcloud and all my files, etc.. are still there)


    But when I bash into the container...

    Code
    ken@openmediavault:~$ docker exec -it nextclouddb bash
    root@d477e9da9376:/# alpine -v
    bash: alpine: command not found
    root@d477e9da9376:/# uname -a
    Linux d477e9da9376 5.10.0-0.bpo.7-amd64 #1 SMP Debian 5.10.40-1~bpo10+1 (2021-06-04) x86_64 GNU/Linux
    root@d477e9da9376:/# exit
    exit
    ken@openmediavault:~$ 

    So what does all this mean? I have no idea...lol. It appears from Portainer, it's running the alpine image... However when I bash into the container, it seems to suggest it is running a Debian based image

  • has anyone done a guide on how to install this? i've back a few pages on this thread but could see anything.

    This will only affect you if you're running 32Bit armhf (raspberry pi for eg.).


    But if you are, you should have noticed it on the Nextcloud "Settings/Administration/Overview" page:

    There was a "Yellow Flag" before the v20 update (if I remember right) that NC wouldn't work with mariaDB <= 10.2.


    The version used by "linuxserver/mariadb:latest" is still the mariabionic (Ubuntu based) and even though it says "110.4.xxx", it's in reality, version "10.1.4.xxxx".

    That is why, on armhf, there was the need to change the DB to a different version.


    To change the version, (as KM0201 said), you only need to add the TAG ":alpine" to the image (as in "linuxserver/mariadb:alpine")

    NOT before you have made a backup of your DB.


    If you're on amd64, aarch64 or i386, disregard this because it won't affect anything, it's just a warning on the log.

    But I think there is a guide from Soma

    It was by Morlan on page #27 :

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


    But at that time, there was no alpine version from linuxserver so the solution was to change to the webhippie DB (not needed now).

    • Offizieller Beitrag

    So it's not an issue for amd64 (guess I didn't need to do that anyway)... my question is ... I clearly changed the image, and it's still showing it is Debian based. I did the same thing on a virtual install, w/ a completely new mariadb install, and it also still showed it was a Debian install, instead of an alpine install.

  • my question is ... I clearly changed the image, and it's still showing it is Debian based. I did the same thing on a virtual install, w/ a completely new mariadb install, and it also still showed it was a Debian install, instead of an alpine install.

    Well, that is a good question. One I really don't have an answer since I don't know....

    All it matters (at that time, I was running armhf and change the DB to webhippie) is it worked and I was able to update NC to v20 (or v21) and there was no more "yellow flag".

    After linuxserver released the "alpine" version, I swapped the DB from webhippie to linuxserver's and kept the TAG on the YML.


    After migrating to aarch64, I just kept using it, :)

    But your question made me check what does it show and I confirm, it shows the same kernel and version of the host:

    docker mariaDBLinux b172c62b184c 5.10.17-v8+ #1421 SMP PREEMPT Thu May 27 14:01:37 BST 2021 aarch64 GNU/Linux

    aarch64 Host Linux tacho 5.10.17-v8+ #1421 SMP PREEMPT Thu May 27 14:01:37 BST 2021 aarch64


    So, maybe the "alpine version" is somewhere "hidden" (?!?) on the dockerfile???

Jetzt mitmachen!

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