Help with permissions and Docker

  • Hello!


    I have a problem that might be a symptom of another problem, so please bear with my rambling question...


    My RPi4 is running omv 6 (I can't remember if it's a clean install or if I upgraded from 5 at any point), and I have Nextcloud (together with nginx and some other images) running on docker. I can't really remember what guide I used to install and setup (dbtech's video guides mostly), but it's been working well (as far as I can tell) for months now.


    Now there's an update for Nextcloud, and I would like to upgrade to it. Other containers I successfully "recreate" in portainer, which pulls the latest image. When I try to do the same with the Nextcloud app (nextcloud_app_1) I get the error "Failure pull access denied for sha256, repository does not exist or may require 'docker login': denied: requested access to the resource is denied", and the same happens with Nextcloud's database (nextcloud_db_1).


    I would like to try docker-compose pull, but when I login via ssh I cannot access the drive (and the subsequent share) that Docker is installed on, despite setting file and folder permissions to allow that in as many ways as I could think of, without them giving me errors. File permissions make my head hurt, and I can't say that I understand them in any meaningful way when it comes to troubleshooting, so there might be something really simple that I'm missing. My other drives I can cd to without issues, but the one with Docker on gives me "Permission denied".


    Everything looks healthy enough in the omv gui and in portainer, as far as I can see, but obviously something isn't working as it should and I can't really think of anything else to try, and googling hasn't lead me to find anything helpful.

  • Different container have different methods to update. The linuxserver/nextlcoud image uses in-app update. That means you start the update from within Nexclouds web GUI.

    Not as simple as that. To update on the NC GUI, you need to first update the image from linuxserver to match the new version.


    For eg, your NC is on v23.0.1 and it warns you that there is an update to v23.0.2

    First you need to check if linuxserver already has an image for v23.0.2 available and update/redeploy the container.

    Or, for those running watchtower or ouroboros, check on Portainer if the image is already matched to the new version.


    Then go again to NC GUI and run the updater (either via GUI or via CLI with update.phar)


    Just FYI.

  • the error message indicates, that you either have a wrong image name or your free number of pulls are exhausted.


    You can try from the cli


    docker pull <your full image name here>


    The image name can be found in portainer

    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

    I've never personally had an issue w/ the webUI updater in NC, but another user reported having issues w/ it the other day... As you said as long as your image is up to date it seems to work fine (I use the "latest" tag and watchtower, so mine are always updated.



    If that's the issue for the OP, SSH your server and execute the following command..


    docker exec -it nextcloud updater.phar


    (this assumes your nextcloud container is named nextcloud.. adjust as necessary)

  • I've never personally had an issue w/ the webUI updater in NC, but another user reported having issues w/ it the other day... As you said as long as your image is up to date it seems to work fine (I use the "latest" tag and watchtower, so mine are always updated

    If it's only one minor (X.X.1) version behind, maybe no harm will happen, but if it's a Major (22.X.X) version, then a lot has changed (mainly, the apps versions that are used on the image, the alpine base in this case) that will prolly give troubles.


    And even worst when people let pass 2 Major versions:

    Say you have v21.x.x and it's on v23 now.

    First step will always be update the container image and then, do the update on NC.

    And since NC won't do a 2 Major versions update, it will first go to v22 and then to v23


    Advantage of Linuxserver is that it is well explained in their github:

    GitHub - linuxserver/docker-nextcloud

    Zitat

    Docker image update and recreation of container alone won't update nextcloud version.

    In order to update nextcloud version, you have two options, firstly make sure you are using the latest docker image,then either

    1. Perform the in app gui update.
    2. Use the CLI version by running docker exec -it nextcloud updater.phar (Both of these are described here)

    Note: Both occ and updater.phar can be run without prepending with sudo -u abc php or sudo -u www-data php

    If you are not customizing our default nginx configuration you will need to remove the file:

    Code
    /config/nginx/site-confs/default

    Then restart the container to replace it with the latest one.

    • Offizieller Beitrag

    And even worst when people let pass 2 Major versions:

    Say you have v21.x.x and it's on v23 now.

    First step will always be update the container image and then, do the update on NC.

    And since NC won't do a 2 Major versions update, it will first go to v22 and then to v23

    Yeah, those are probably the same folks using OMV 2.0 and can't understand why stuff isn't working anymore.. :) People not running regular updates is a huge pet peeve of mine. It takes literally no time.

  • Thank you all for taking the time to reply!


    Regarding the updating of nextcloud (maybe not relevant in this forum, I apologize in that case):

    Cicking the update now-button in the gui just returns me to the dashboard page, and after a bit of googling I found this post leading me to this part of the nextcloud docker github page stating that upgrading is done by pulling the new image.


    It's somewhat of a moot point for me right now, though, because I seem to have messed something up when fiddling around with permissions (and being really stupid and mixing up chmod and chown, among other dumb stuff) and now nginx isn't working and I'm thinking that a fresh install actually might be faster and more fun than untangling the mess I've made of this.


    Something that's been happening that I would love to get some thoughts on, before marking the thread as solved, is that it turns out that the drive (/srv/dev-disk-by-[stuff]) that has my Docker share has different permissions than the other drives I have connected (/srv/dev-disk-by[other stuff x2]).

    ls -ld /srv/dev-disk-by-[other stuff x2] (my other two drives)

    gives me

    drwxrwxrwx 4 root root 4096

    but

    ls -ld /srv/dev-disk-by-[stuff] (the drive that houses docker)

    returns

    drwx--x--- 20 root root 4096


    I've changed the permissions to 777

    sudo su (because sudo chmod doesn't seem to do anything)

    chmod 777 /srv/dev-disk-by-[stuff]

    but the permissions turn back to 710 after a while and I don't know why...

    Subfolders have varied permissions that seem to reflect acl settings done in omv gui.

    • Offizieller Beitrag

    docker locks down the permissions of the container folder fairly harshly. Whenever the service restarts, it resets the permissions on that folder.


    What is the output of

    Code
    docker info | grep Root
    • Offizieller Beitrag

    Ah, ok!

    The output is

    Docker Root Dir: /srv/dev-disk-by-[stuff] (my edit to keep it consistent with my post above)

    WARNING: No memory limit supportWARNING: No swap limit support

    Ah ok.. Your edits don't help at all because you're the one that messed this up... Here's the best suggestion I can make given the info


    You need to make a folder, that is at the top of the directory (ie, right under the UUID) and set that to be where you store containers. There's really no reason for this directory to be shared over SMB, or for you to really access this container 99.999% of the time. Then set that folder as your containers folder.


    Then you're going to have to go back and delete the old containers folder, and then probably install the reset permissions plugin, and start resetting permissions on your shared folders. My guess is the way you've done this you've probably did quite a number on permissions and this will take some work to fix.


    777 really shouldn't be your answer either... learn to properly set your permissions.

  • You need to make a folder, that is at the top of the directory (ie, right under the UUID) and set that to be where you store containers.

    I thought that was what I had done, but on closer inspection I see that wasn't the case at all... I think I'll start over with a new installation of omv and do better this time. Just so I understand you correctly: this folder is what I should specify under "Docker storage" when installing docker in the omv gui?

    777 really shouldn't be your answer either... learn to properly set your permissions.

    Couldnt agree more... Fail and learn, I suppose!

Jetzt mitmachen!

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