Posts by jackster

    Good to know that I'm not the only one who has had this happen :)


    I'll try adding the ":amd64-latest" -tag to the image and see if that makes a difference, thanks for the tip!


    EDIT: adding the tag seems to have done the trick, Portainer now only pulled the requested image and nothing else. Maybe a mention of this should be added to the Nextcloud installation guide at [How-To] Nextcloud with Letsencrypt using OMV and docker-compose since others have had this issue as well?

    For some reason my Nextcloud stack when deployed tries to basically pull all available images from ghcr.io/linuxserver/nextcloud until it fails due to running out of disk space. Here are some of the images it pulled as an example (I'm not on an ARM cpu):


    Code
    sha256:f346c7a6d867c5a0efb16b30f79174... Unused ghcr.io/linuxserver/nextcloud:arm64v8-21.0.0-ls124 384.5 MB 2021-02-25 22:01:40
    sha256:cfdcfabf18da6564986ed8aa2b44f5... Unused ghcr.io/linuxserver/nextcloud:arm32v7-21.0.0-ls124 334.7 MB 2021-02-25 21:58:44
    sha256:fb6a9727905a29d2985fbe798ed15e... Unused ghcr.io/linuxserver/nextcloud:21.0.0-ls124ghcr.io/linuxserver/nextcloud:amd64-21.0.0-ls124 395.4 MB 2021-02-25 21:58:14
    sha256:833fc473deb034860bdb04895e3016... Unused ghcr.io/linuxserver/nextcloud:arm64v8-21.0.0-ls123 387.7 MB 2021-02-22 15:34:56
    sha256:5266b2eb3602603d10aa2ec54f8d9a... Unused ghcr.io/linuxserver/nextcloud:arm32v7-21.0.0-ls123 336.9 MB 2021-02-22 15:24:13


    I've deployed the stack in Portainer using the instructions found here [How-To] Nextcloud with Letsencrypt using OMV and docker-compose .


    And here is my docker-compose.yml:



    The deployment does eventually finish successfully after the disk has been filled and I can recover by doing a docker system prune --all but it would be nice to know what causes this and how I can prevent it in the future? Should I define a specific image name in "image: ghcr.io/linuxserver/nextcloud" ?

    I couldn't increase the free space preceding because the OS partition was there... Or at least I couldn't figure out how to do it in GParted without messing up my existing data partitions.


    In any case I have now done the resizing so that I deleted the existing swap partition and recreated it at the end of the drive, and it worked except that OMV is of course currently not using the new swap partition. How do I tell OMV to use it? The 'File Systems' section does not even allow me to mount it:

    I have recently done a fresh install of OMV5 on a small SSD with an OS partition + another partition for storage (used for docker appdata "and stuff").


    I have now successfully cloned the small SSD into a larger one and I want to resize the storage partition to take up all of the unallocated space. The problem is that OMV created the swap partition after the storage partition, and therefore in order to resize the storage partition in GParted I have to first delete the current swap partition... I have 8Gb of RAM in my system and I'd like to have a swap partition in the future as well, I can easily leave 8Gb of space at the end of the drive for the swap in GParted.


    The question is how do I tell the OMV install to start using that new 8Gb partition as swap?

    Eh I noticed just now that my OMV OS drive was 100% full, which was probably causing the issue with accessing the database. And yes I used "passwordedited" as password.


    /var/lib/docker/overlay2 was for some reason taking in excess of 27 gigabytes even though this is a fresh OMV install and so far I have only installed the Nextcloud and Swag containers. I have no idea why it was taking up so much space.


    In any case, I did a docker system prune --all which cleared all the extra stuff, after which I stopped and removed the running containers and deleted the appdata -folder.


    ...and that finally did the trick, now I was able to finish the Nextcloud install :). Thank you for the assistance!

    Here is my docker-compose:


    And here is what I enter in the Nextcloud welcome screen:


    I have just done a fresh install of OMV5 and I am in the process of setting up Nextcloud via Docker. I have followed this guide https://forum.openmediavault.o…g-omv-and-docker-compose/and I have the containers set up and working. The problems began when I opened Nextcloud for the first time and tried to configure the database:


    Code
    Error while trying to create admin user: Failed to connect to the database: An exception occurred in the driver: SQLSTATE[HY000] [1045] Access denied for user 'root'@'nextcloud.nextcloud_default' (using password: YES)


    Now I did the initial install with these settings in docker-compose.yml:


    Code
    environment:
    - PUID=1001 #change PUID if needed
    - PGID=100 #change PGID if needed
    - MYSQL_ROOT_PASSWORD=mypasshere


    But it did not work. I then tried to run mysql -u root -p inside the container as per these instructions RE: Nextcloud with Letsencrypt using OMV and docker-compose - Q&A but it just kept saying "ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES)" even though the password was most definitely correct. I verified the password in the container settings and it was correct.


    I googled some more and found this thread RE: Nextcloud with Letsencrypt using OMV and docker-compose - Q&A which has a post saying to set up mariadb with these parameters:


    Code
    - MYSQL_DATABASE=nextcloud
    - MYSQL_USER=nextcloud
    - MYSQL_PASSWORD=secretpassword


    So I changed those in docker-compose.yml, (in order to rule out locale issues I tested this with just secretpassword) ran docker-compose up -d but I am still having the same problem with the Nextcloud setup and I still can't access the database via CLI.:


    Code
    root@39142896bec1:/# mysql -u nextcloud -p
    Enter password: (TRIED PUTTING SECRETPASSWORD HERE)
    ERROR 1045 (28000): Access denied for user 'nextcloud'@'localhost' (using password: YES)


    This is not making any sense, it seems that for some reason the user settings for mariadb are being ignored and I therefore can't access the database. There are no errors in the nextclouddb container logs and the config looks ok:



    What on earth could be the problem? :D

    Did you read the other post? You can manually update your repos and add the new signing key if you insist on staying on OMV 4.x. Why do you need to stay on the unsupported version?


    There are upgrade scripts - Upgrade Scripts for non-interactive major release upgrades (2->3, 3->4, 4->5)

    Thanks, I did read the post but I didn't find/understand the necessary information needed to update my repos. I followed the link at https://wiki.omv-extras.org/ to OMV-Extras.org Plugin and tried the steps mentioned there but it did not work, and I saw nowhere what I should update my repos to or how to actually do it.


    In any case I agree it's best to the upgrade route. I have been putting it off because installing OMV4 was quite a lot of work with a lot of issues and I'm afraid I'll have the same problems again. Oh well, I guess I'll just have to bite the bullet and try the script :)

    Since last night I have been getting these emails from my OMV installation (4.1.36-1) and I get the same errors in the webGUI Update Management:


    Code
    E: The repository 'https://dl.bintray.com/openmediavault-plugin-developers/arrakis stretch Release' does no longer have a Release file.
    E: The repository 'https://dl.bintray.com/openmediavault-plugin-developers/arrakis-plex stretch Release' does no longer have a Release file.
    E: The repository 'https://dl.bintray.com/openmediavault-plugin-developers/arrakis-docker stretch Release' does no longer have a Release file.


    Now the issue obviously is that the repo no longer has the requested Release files. Is there another repo I can use to fix this and which file(s) do I need to update? Thank you in advance :)

    Ok so I figured a reinstall would be easier and faster than trying to troubleshoot the issue and I did the reinstall by following this guide found here on OMV forums: HOWTO-PiHole.pdf


    However, it did not help. The pihole container is still restarting with 254 second intervals. This is a snippet of what I can see in the Container log:


    Code
    ::: Testing pihole-FTL DNS: FTL started!
    ::: Testing lighttpd config: Syntax OK
    ::: All config checks passed, cleared for startup ...
    ::: Docker start setup complete
    [✗] DNS resolution is currently unavailable

    Hmm I took a peek inside pihole-FTL.log just now and it seems that there is a recurring issue where "FTL" crashes with 254 second intervals?


    Code
    [2020-09-21 10:37:05.662 534M] Shutting down...
    [2020-09-21 10:37:05.662 534M] !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    [2020-09-21 10:37:05.662 534M] ----------------------------> FTL crashed! <----------------------------
    [2020-09-21 10:37:05.662 534M] !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    [2020-09-21 10:37:05.662 534M] Please report a bug at https://github.com/pi-hole/FTL/issues
    [2020-09-21 10:37:05.662 534M] and include in your report already the following details:
    [2020-09-21 10:37:05.662 534M] FTL has been running for 254 seconds

    I installed Pi-Hole a year ago or so via Docker and it has been working fine, but for some reason I am no longer able to access the webGUI of Pi-Hole. I don't know when the problem began because I haven't opened the GUI in a while but it did work before.


    When I try to open 192.168.0.3/admin I get this error:

    Code
    This site can’t be reached
    192.168.0.3 refused to connect.
    ERR_CONNECTION_REFUSED


    And if I log in to the Pi-Hole container and list the open ports there is indeed no open http port:

    Code
    lsof -i -P -n | grep LISTEN
    pihole-FT 528 root 5u IPv4 27823662 0t0 TCP *:53 (LISTEN)
    pihole-FT 528 root 7u IPv6 27823664 0t0 TCP *:53 (LISTEN)
    pihole-FT 528 root 10u IPv4 27822681 0t0 TCP 127.0.0.1:4711 (LISTEN)


    Where exactly did you have this wrong directory path configured? 'Volumes and bind mounts' in the docker container config? Mine is set to "/srv/dev-disk-by-label-*******/appdata/nextcloud/config" which should be correct, right?

    FYI: now that Nextcloud version 17.0.2 is available I again ran into the same problem with using the GUI updater:


    Image of webGUI fail



    Receiving the same error wasn't so surprising but it would be nice to figure out how to fix it once and for all. Fortunately I was able to initiate the upgrade via CLI although I got stuck in maintenance mode until I manually disabled it with 'sudo -u abc php occ maintenance:mode --off'. After that I was able to upgrade to 17.0.2.



    Image of CLI installer

    Ok so I tried troubleshooting the issue further and I think it has to do something with the webGUI updater searching for the NC install in the wrong folder and not with the permissions being wrong. The upgrade process fails immediately with the message 'File not found' after I press the update -button and there is no record of the upgrade actually starting in the updater log. If it would have found the files then the next step would have been the write permissions check and it never got that far.


    Anywho, I did now manage to upgrade my NC to 17.0.1 by running the installer from the container shell with the command: sudo -u abc php /config/www/nextcloud/updater/updater.phar

    Everything went smoothly with the CLI install and it immediately found all the files. Why the GUI updater looked for the files in some other location I don't know. Remains to be seen if I'll still have the same issue when a newer version than 17.0.1 will be available.


    In order to diagnose the issue further I logged in to the NC container shell and searched for all *.log -files, but none of these had any helpful information:


    /var/log/nginx/error.log
    /data/updater.log
    /data/audit.log
    /data/nextcloud.log
    /config/log/php/error.log
    /config/log/nginx/error.log
    /config/log/nginx/access.log


    Not even updater.log, which at least I at first assumed would contain something useful, has anything relevant...


    So I guess I'll try deleting the NC container again and also delete the image and then reinstall. It won't solve the actual problem with the "File not found" error but at least then I should get the newest version.


    EDIT: How exactly do I delete the old NC image? I tried again killing the container in the Docker GUI after which I deleted the "Repository" in the GUI and then re-installed with docker-compose up -d but I again got version 16.0.4. I followed the install and the installer said that it was pulling the image and I witnessed it downloading a ~130Mb file but I am still getting the same old 16.0.4 ?(