cd: /data/compose/62: No such file or directory

[lockheed]

I tried to run this and got the following error on adguardhome. Any idea what can be the cause?

Choose what containers to update.
Enter number(s) separated by comma, [a] for all - [q] to quit: 1,2,3,20,23

Updating containers:
(...)

/root/.local/bin/dockcheck.sh: line 315: cd: /data/compose/62: No such file or directory
Path error - skipping adguardhome
/root/.local/bin/dockcheck.sh: line 315: cd: /data/compose/62: No such file or directory
Path error - skipping adguardhome-sync
/root/.local/bin/dockcheck.sh: line 315: cd: /data/compose/175: No such file or directory
Path error - skipping db-backup
/root/.local/bin/dockcheck.sh: line 315: cd: /data/compose/4: No such file or directory
Path error - skipping deluge
/root/.local/bin/dockcheck.sh: line 315: cd: /data/compose/191: No such file or directory
Path error - skipping jellystat.kv
/root/.local/bin/dockcheck.sh: line 315: cd: /data/compose/172: No such file or directory
Path error - skipping metube
/root/.local/bin/dockcheck.sh: line 315: cd: /data/compose/109: No such file or directory
Path error - skipping plant-it
/root/.local/bin/dockcheck.sh: line 315: cd: /data/compose/5: No such file or directory
Path error - skipping nginx_filmweb
/root/.local/bin/dockcheck.sh: line 315: cd: /data/compose/27: No such file or directory
Path error - skipping paperless
/root/.local/bin/dockcheck.sh: line 315: cd: /data/compose/27: No such file or directory
Path error - skipping paperless-redis
/root/.local/bin/dockcheck.sh: line 315: cd: /data/compose/32: No such file or directory
Path error - skipping pingvin-share

[mag37]

I'm guessing they're all started with portainer?
It's not only adguardhome, all the containers in the list trying to cd to /data/compose/### which looks like portainer structure.

I've tried to look into how I could support containers started with portainer, but no luck yet.

@lockheed - please confirm if they're started with portainer.

[lockheed]

They are all created as portainer stacks, not sure if they are "being started" by portainer.

[mag37]

Yeah, thats it I'm afraid.
Portainer doesn't handle docker compose the usual way in the backend, which ends up with different labels and setups. So the script cant do its things.

Sorry I can't help you with that, there's a few other issues open about portainer. I'll close this one, as there's nothing new.

[mag37]

Duplicate of #40

[lockheed]

What are the chances/timeline to get it fixed?
Does this also apply to dockge and dockemon, or just portainer?

[mag37]

No timeline and slim chances.
I'll give it another look if I get time to spare, but last time I spun up a test machine with portainer I didn't find a solution.

Never used either but from what I could tell when reading quickly it seems like it should work.
As long as they dont do anything odd with the compose files etc.

[jermanoid]

it seems like maybe mapping Portainer's data directory to /data would fix this. or having a parameter in dockcheck.sh that let you provide the path to wherever you have the data directory mapped. I'm sure there is more nuance in there somewhere that is less obvious to me.

[jermanoid]

I set a symbolic link at /data that points to my portainer container's /data map.
ln -s /docker/storage/portainer/data /data
then I ran dockcheck.sh and it at least downloads the images, although it tangles trying to recreate the containers due to a "naming conflict"

[mag37]

I set a symbolic link at /data that points to my portainer container's /data map. ln -s /docker/storage/portainer/data /data then I ran dockcheck.sh and it at least downloads the images, although it tangles trying to recreate the containers due to a "naming conflict"

That's interesting!
Last time I remember some of the labels/info the script needs to extract from the containers didn't work.

I dont have time to check it right now, will try to run a VM and test some stuff when I can.

But maybe you could check errorCheck.sh and paste what it spits out? You dont need to run it on your whole stack, just test some containers and see
For example: ./errorCheck.sh homer

[mag37]

I've been labbing a little with this in a VM now, and while I can write some (ugly, will clean) logic to do a few checks and rewrites the path if a container has the portainer structure /data/compose/### to use the compose-location.. I also hit the issue with recreation breaking.

If I added something to stop+rm the container and then recreate it, it's not managed by Portainer anymore when it gets up.
And I dont know if people uses docker-volumes for the portainer data, then it'll work differently I'm afraid. Have not tested that yet.

My testing modifications have been something like this:

## Added this before line 314, will only work if your portainer container is called exactly "portainer"
      PortPath=$(docker inspect -f '{{ range .Mounts }}{{ if eq .Destination "/data" }}{{ .Source }}{{ end }}{{ end }}' portainer)
      if [[ $ContPath =~ ^/data.* ]] ; then
        ContPath=${ContPath/#\/data/$PortPath} 
      fi

## modified this on line 318 (322 after the addition above)
      if [[ $ContConfigFile = '/'* ]] ; then
        CompleteConfs=$(for conf in ${ContConfigFile//,/ } ; do $conf=${$conf/#\/data/$PortPath} ; printf -- "-f %s " "$conf"; done)
      else

If this is something I'll implement I'll probably clean it some more :) But for testing.
I'll do some more digging if its possible to recreate the container within portainers scope, let me know if you've got any ideas!

Edit:
I tried adding the --force-recreate flag with no luck. Was looking at Portainer web-hooks but that seems to be business only.