Understand the note in the compose.yaml file about the stack dir (CORRECT vs WRONG)

[RyanBalfanz]

I do not understand the note in the compose.yaml file about the stack directly.

dockge/compose.yaml

Lines 16 to 20 in 05191b1

	# Your stacks directory in the host (The paths inside container must be the same as the host)
	# ⚠️⚠️ If you did it wrong, your data could end up be written into a wrong path.
	# ✔️✔️✔️✔️ CORRECT: - /my-stacks:/my-stacks (Both paths match)
	# ❌❌❌❌ WRONG: - /docker:/my-stacks (Both paths do not match)
	- /opt/stacks:/opt/stacks

What does my host directory location have to do with the location in the container? And if they don't match why/how might data be written to the wrong path?

It seems the interpretation of the comment is that they must match, but that should not need to be the case.

[louislam]

See previous post: #35

As I said before, it is hard to explain. But you can understand it by doing it wrong:

Assume that you want to store your stacks in /my_stacks.

1. Spin up a Dockge with a wrong config: /my_stacks:/opt/stacks
2. Start this compose via this Dockge.

version: '3.8'
services:
  uptime-kuma:
    image: louislam/uptime-kuma:1
    volumes:
      - ./data:/app/data

3. Now, check /my_stacks/uptime-kuma, you will find there is a compose file, but no data.

Where is the data?
Still in /opt/stacks

[bmcgonag]

Are you saying that the data mapped as a volume in the stack being created is being stored in /opt/stacks on the host because this is a default location for docker to store volume data?

Or do you mean it's only in the dockge container because the volume was not mapped as indicated?

Either way, it's interesting.

[louislam]

Maybe the first one.

Because docker-compose convert the relative path ./data to the absolute path /opt/stacks/uptime-kuma/data and send it to the Docker daemon.

Because the Docker daemon is actually in the host, so it creates /opt/stacks/uptime-kuma/data in the host.

So that's why the stacks dir inside container has to match the host's path.

[RyanBalfanz]

(On mobile) That doesn’t sound right and I don’t think that’s ever been my experience.

The path can be absolute or relative. If it is relative, it is resolved

from the Compose file's parent folder. If it is absolute, the path prevents the Compose file from being portable so Compose displays a warning. In the later case, build arguments can be specified, including an alternate Dockerfile location. https://docs.docker.com/compose/compose-file/build/#:~:text=The%20path%20can%20be%20absolute,including%20an%20alternate%20Dockerfile%20location . Could this be a platform issue? I’ve never used docker on Windows. Otherwise I suspect this may just be a phasing or wording issue that can be resolved with help. Sent from Gmail Mobile

…

On Wed, Nov 22, 2023 at 17:11 Louis Lam ***@***.***> wrote: Maybe the first one. Because docker-compose convert the relative path ./data to the absolute path /opt/stacks/uptime-kuma/data and send it to the Docker daemon. Because the Docker is actually in the host, so it creates /opt/stacks/uptime-kuma/data in the host. So that's why the stacks dir inside container has to match the host's path. — Reply to this email directly, view it on GitHub <#146 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABARHVOQ63TXEHDXUV3WYDYF2PCXAVCNFSM6AAAAAA7VGFPMCVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TMNBXGQ4TI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[trythatagain]

Got to say, this is the first container that I've had to do this. It does seem weird though.
I was a little worried as when I use OMV and you generally use the whole drive string eg. /dev/.../directory but it's working fine using the whole path.

[louislam]

Maybe there is a workaround which I didn't know. Maybe someone could dig into it.

[RyanBalfanz]

But are you using the same absolute path on the host and the container, or are the both different (but still absolute)? Sent from Gmail Mobile

…

On Thu, Nov 23, 2023 at 11:16 trythatagain ***@***.***> wrote: Got to say, this is the first container that I've had to do this. It does seem weird though. I was a little worried as when I use OMV and you generally use the whole drive string eg. /dev/.../directory but it's working fine using the whole path. — Reply to this email directly, view it on GitHub <#146 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABARHV5YWIBUNP5Z4EWGMTYF6AGVAVCNFSM6AAAAAA7VGFPMCVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TMNJTHE2DI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[trythatagain]

I used the same on host and container. Normally I'd used full path on host and whatever is stated for container. The only time I change this is for my media containers, where I generally use the folder name on the container side for ie /dev/... /download:/download just for ease of use

…

On Thu, 23 Nov 2023, 17:28 Ryan Balfanz, ***@***.***> wrote: But are you using the same absolute path on the host and the container, or are the both different (but still absolute)? Sent from Gmail Mobile On Thu, Nov 23, 2023 at 11:16 trythatagain ***@***.***> wrote: > Got to say, this is the first container that I've had to do this. It does > seem weird though. > I was a little worried as when I use OMV and you generally use the whole > drive string eg. /dev/.../directory but it's working fine using the whole > path. > > — > Reply to this email directly, view it on GitHub > < #146 (comment)>, > or unsubscribe > < https://github.com/notifications/unsubscribe-auth/AABARHV5YWIBUNP5Z4EWGMTYF6AGVAVCNFSM6AAAAAA7VGFPMCVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TMNJTHE2DI> > . > You are receiving this because you authored the thread.Message ID: > ***@***.***> > — Reply to this email directly, view it on GitHub <#146 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AUUW46BLRW4VREK6PBLTICDYF6BVPAVCNFSM6AAAAAA7VGFPMCVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TMNJUGAYTQ> . You are receiving this because you commented.Message ID: ***@***.***>

[mikecarr]

Ok stupid question, I setup as you have recommended after trying and failing with my own folders LOL. When I setup my own folders stacks were written correctly but container volumes, I have no idea where or if they were created locally.

What permissions do you put on /opt/stacks /opt/dockge? Do you leave as root and run everything as root?

[RyanBalfanz]

See also: #35

[RyanBalfanz]

I think what is important, and might be what @louislam is trying to communicate, is that the container directory should match the value for DOCKGE_STACKS_DIR (as in
https://github.com/louislam/dockge/blob/05191b14de1cdf9a7a25ee9b2d44db66e6a7f1b6/compose.yaml#L22C1-L23). But the wording is confusing.

Notice that a similar warning does not exist for the data dir in the example compose file

dockge/compose.yaml

Line 11 in 05191b1

- ./data:/app/data

. I just confirmed this myself by using a relative directory as the host value in my volume for my stacks directory. This was the result that I expected. I confirmed this both without and with an existing data and stacks dir. The only difference there, depending on your setup, might be the user who owns the directories (in addition to their contents).

I think that the warning comments should be replaced with a note that the container directory in the volume entry should match that of DOCKGE_STACKS_DIR, which has a default value.

Or, this configurability may not even need to exist. Why might someone need to change the stacks directory in the container (or the data dir for that matter, which is not similarly configurable).

[RyanBalfanz]

As a start, consider something like this: RyanBalfanz/dockge@master...RyanBalfanz-patch-1

[trythatagain]

I've just changed my dockge.yml file as RyanBalfanz suggested, which is how I would normally do it, ' - /srv/dev-disk-by-uuid-etc/compose:/opt/stacks' and the eviroment to ' - DOCKGE_STACKS_DIR:/opt/stacks'

It all worked, showed up a compose.yml file when clicking a container, allowed to edit and save that yml. Also when creating a new one, saved the dir to my compose dir fine (apart from being root, but, lets hope that gets fixed).
So as RyanBalfanz say, the ' - DOCKGE_STACKS_DIR:' needs to match the container value (right hand value) of the compose volume path.

[TheToby1]

I tried this and everything seemed to be working until I had a relative path in one of my compose files.

With the config as:

• /my_stacks:/opt/stacks
  and
• DOCKGE_STACKS_DIR:/opt/stacks

I then try to point to a relative file (my_file.txt) in a stack (lets call it test_stack).

Launching the stack through dockge tries to point to the /opt/stacks/test_stack/my_file.txt, but that directory does not exist on the host system. It is actually in /my_stacks/test_stack/my_file.txt.

This caused the docker daemon to have an error caused by incorrect bind mount.