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

    • Offizieller Beitrag
    Zitat von Nefertiti

    docker info | grep Root

    Docker Root Dir: /var/lib/docker

    That's the problem.


    It can be fixed, just pay attention


    1 Stop the docker service

    Code
    systemctl stop docker

    1a. If you don't have container data you want to save (basically you will have to rebuild all containers)... then just run the command rm -R /var/lib/docker and skip to step 4 .. otherwise proceed to step 2 if you want to save your current containers.


    2 To save your current docker setups, we need to move that docker folder somewhere (I'm assuming one of your data drives). This isn't really a folder to put under other directories you use or want to share over SMB or otherwise, as docker locks it down pretty hard and you'll probably just end up screwing up permissions on it.


    My suggestion.. assuming you the UUID you gave earlier for your appdata folder is a pretty big drive...


    Code
    mv /var/lib/docker /srv/dev-disk-by-uuid-37d059e6-8189-404a-967b-53afec96bf4f/

    That will make your new docker path

    /srv/dev-disk-by-uuid-37d059e6-8189-404a-967b-53afec96bf4f/docker


    3. In the OMV webUI, go to omv-extras and then click the docker tab.

    4. You'll see the "docker storage path" which right now is var lib docker. Paste that complete path where you moved the docker folder there. If you didn't move it and opted to start over, then just use the same path, and the docker folder will be created.

    5. Click Save

    6. Go back to the terminal and restart docker

    Code
    systemctl start docker

    Your dockers should now be moved off the OS drive... and if you execute that docker info command again, it will show your new path.

    I am aware of it but

    if I move docker out of var lib actually I got no problem doing it, but of course it changes the etc/docker /daemon.json to the new location


    Code


    Code
    "data-root": "/srv/dev-disk-by-uuid-37d059e6-8189-404a-967b-53afec96bf4f/docker"

    but as soon I put back the Nvidia one


    Code


    the docker got back to var/lib this guy tried also but without success https://forums.developer.nvidi…ng-docker-to-ssd/166630/4

    any idea?

    • Offizieller Beitrag

    Ah that's right.. i forgot about that. I wonder if a symlink would work?

    lemme think on that

    This is the method you should stick with: (you really like to complicate things, don't you? :P )

    Zitat von Nefertiti

    if not no big deal I would stay with the other version



    If you insist on this:

    • Offizieller Beitrag
    Zitat von Nefertiti

    OK but to get back to the nextcloud php stack

    so I am not able to move the data outside on an other disk?

    if not no big deal I would stay with the other version

    Code
     volumes:
      - nextcloud:/var/www/html

    I don't see why you couldn't. Where is the data stored?

    Nefertiti my last post regarding your problems:


    Use a bind mount in fstab to move /var/lib/docker to some other place like I do on this system (last line):


    Read about named volumes and mounted host path in the docker docs https://docs.docker.com/compos…/compose-file-v2/#volumes



    To the others knowlegable: Why do you open the https port on the nextcloud contianer when swag is doing the ssl encryption and is forwarding network traffic as http to the nextcloud container?

    If you got help in the forum and want to give something back to the project click here (omv) or here (scroll down) (plugins) and write up your solution for others.

    Gefällt mir 1
    Zitat von Zoki

    Why do you open the https port on the nextcloud contianer when swag is doing the ssl encryption and is forwarding network traffic as http to the nextcloud container?

    The pre-made subdomain.confs are already that way, we just use them:

    reverse-proxy-confs/nextcloud.subdomain.conf.sample at master · linuxserver/reverse-proxy-confs (github.com)

    Code
        location / {
        include /config/nginx/proxy.conf;
        include /config/nginx/resolver.conf;
        set $upstream_app nextcloud;
        set $upstream_port 443;
        set $upstream_proto https;
        proxy_pass $upstream_proto://$upstream_app:$upstream_port;

        proxy_max_temp_file_size 2048m;
    }
    • Offizieller Beitrag

    That's an interesting way of handling that... (the bind mount).


    As for the nextcloud container.. at least for me... going to nextclouds ip:port, requires https (then you have to accept the security risk to get to the login). If you don't add in the https port under the container, you won't get there... or at least that is the problem I've had in the past.


    Once I've routed nextcloud through swag however and it's all working, I go back and comment those ports out on my nextcloud stack... then remove them from the config.php of nextcloud so the only way to the container is through swag.

    Zitat von Soma

    This is the method you should stick with: (you really like to complicate things, don't you? :P )



    If you insist on this:

    This is why I insist because I think this is what I have done but the result is still in var

    Zitat von Nefertiti

    This is why I insist because I think this is what I have done but the result is still in var

    Sorry, you're on your own to sort that one.

    You already have NC running with https connection from in and out Internet.


    The only method I care about is that one, don't need to learn a different one. ;)

    Zitat von Soma

    Sorry, you're on your own to sort that one.

    You already have NC running with https connection from in and out Internet.


    The only method I care about is that one, don't need to learn a different one. ;)

    Ok you are right:thumbup::) you have been a tremendous help to get me on a working nextcloud<3 i am not gonna tinker it any longer:)

    Zitat von Nefertiti

    This is why I insist because I think this is what I have done but the result is still in var

    You are mixing up named volumes an mounted host paths.

    What you are showing us is only a screenshot which tells there are two named volumes in /var/lib/docker/volumes. These have been created some time when you started a stack / docker-compose.yml file. It does not tell me if they are in use by any container.


    Named volumes are not destroyed, when you shut down a stack.


    Learn about named volumes (allways paced in the docker/volumes directory, no matter what you do) and monted host path. (gave you the link above)


    In portainer, click on the volume name to see the volume details and look at the section Containers using volume.

    or from the cli docker inspect nextcloud -f "{{ json .Mounts }}" Replace nextcloud with the name of your nextoud container.


    Case closed

    If you got help in the forum and want to give something back to the project click here (omv) or here (scroll down) (plugins) and write up your solution for others.

    • Offizieller Beitrag

    Re: /var/lib/docker: here is another (among many) example; that at the top of every Guide, How-To, and Tip there should be emblazoned in bold red letters the sentence:


    Before embarking on your OMV journey change your Docker storage path from the default location of /var/lib/docker to somewhere on a data drive, such as /srv/dev-disk-by…/docker.

    • Offizieller Beitrag
    Zitat von Agricola

    Re: /var/lib/docker: here is another (among many) example; that at the top of every Guide, How-To, and Tip there should be emblazoned in bold red letters the sentence:


    Before embarking on your OMV journey change your Docker storage path from the default location of /var/lib/docker to somewhere on a data drive, such as /srv/dev-disk-by…/docker.

    Way way way back in the day.. when you installed the docker plugin, it actually had a drop down on where to install containers (the drop down to a shared folder, which is presumably on a data drive).. This caused some other issues because back then folders were hard linked under /sharedfolders. This unfortunately caused issues with creating /deleting folders in the webUI. As I recall, You could stop docker at the command line, add/remove folders at will, then restart docker, and all was well.. but that was cumbersome. If docker was running, add/removing shared folders was not happening as you'd get a long error..


    To resolve this, aaron dropped the drop down (he he) and put the path there, where a user could put a custom path. This fixed the above issue w/ the webUI locking you out from adding/removing folders in the webUI if docker was running.


    Since OMV has went almost exclusively to recommending absolute paths... it would seem this issue is now moot. It's still probably better to leave it as is. The problem is TDL, dbtech and even many of the guides here on the forum, miss this critical issue. As we've all seen with some of the larger containers (Plex, Emby, Jellyfin especially)... that will fill a small OS drive very very quickly... then the problems start.

    • Offizieller Beitrag
    Zitat von Nefertiti

    KM0201 or Zoki can you explain this bind mount stuff in fstab or in my case how to get docker at

    /srv/dev-disk-by-uuid-37d059e6-8189-404a-967b-53afec96bf4f/docker be effective?

    Let me test something real quick.

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden