this post was submitted on 04 Apr 2026
9 points (90.9% liked)

Linux 101 stuff. Questions are encouraged, noobs are welcome!

1477 readers
1 users here now

Linux introductions, tips and tutorials. Questions are encouraged. Any distro, any platform! Explicitly noob-friendly.

founded 2 years ago
MODERATORS
gyro@lemmy.world
Guenther_Amanita@feddit.de
9
How do I interact with a git repo set up by docker compose in a persistent volume outside the container? (lemmy.world)
submitted 4 days ago* (last edited 4 days ago) by early_riser@lemmy.world to c/linux4noobs@lemmy.world
12 comments fedilink hide all child comments
 

There's a lot I don't understand about both docker and git, so my question and description of the problem may not be as detailed as some would like.

I've set up a container, Otter wiki, via the docker compose file offered in the docs. This sets up a persistent volume outside the container where the wiki config and git repo containing the wiki's pages live. Everything works fine. I can go to the site and everything works. But I want to add external files to the repo. When I try to do it, it throws an error saying I need to enter my email and user name. I do this, and it still says permission denied.

I assume the instance of git that's tracking the repo lives inside the docker container, but the repo itself lives outside the container. How do I add and commit files?

CLARIFYING EDIT:

The repo I'm trying to use isn't for Otter's source code. Otter uses git as the revision tracking system component common to most wikis. That is, the wiki itself is a git repo filled with markdown files. In order to add a bunch of existing markdown files to the wiki, I have to tell git to track them, but this is a persistent volume outside the container, so the instance of git I'm using is on the host, but the instance of git that's tracking the files is in the container.

top 12 comments
sorted by: hot top controversial new old
[–] j4k3@lemmy.world 1 points 4 days ago* (last edited 4 days ago) (1 children)

The stuff outside is likely exported from the container, but is likely just a link to what is inside, made to look transparent from the host but is not real.

Containers create an overlay layer on top of the host. Some stuff on the host may still be linked directly.

The abstract concept to understand here is that the thing you want to put in a container is likely to need outdated or different library (code) dependencies than the host machine. If you installed this software on the host, the conflicting dependencies are a nightmare and are likely to break stuff over time. So the container is the solution. It is as likely to be as small of an overlay image as possible and contains the dependencies that would otherwise conflict, and keeps them separate from the host.

If you want to work with these, you must log into the container, and use the tools within. This will likely involve both the container and a Python venv layer, conda, or uv.

It is also likely that docker is just an alias for podman on a Linux machine.

[–] early_riser@lemmy.world 1 points 4 days ago (1 children)

It is also likely that docker is just an alias for podman on a Linux machine.

This is on a Raspberry Pi running RPi OS, and I installed docker and docker compose myself.

[–] j4k3@lemmy.world 1 points 4 days ago

That has the daemon running that podman avoids. Be carefully what you do with it or expose it to on the internet. Sorry for wasting the time of responding

[–] folekaule@lemmy.world 1 points 4 days ago* (last edited 4 days ago) (1 children)

I don't know the specifics of your app, but Docker containers aren't designed to be used for persistent data. They are designed to be immutable after they're built.

Instead you would create a volume to keep files in and mount them where your application needs them. Typically like /data or /var/something. (Edit: otter wiki wants /app-data)

You can use a bind mount to mount a local directory or a named volume which is kept in a set location by Docker. Generally bind mounts are easier to start with since you can browse the files directly on the host.

[–] early_riser@lemmy.world 1 points 4 days ago (2 children)

I don’t know the specifics of your app, but Docker containers aren’t designed to be used for persistent data. They are designed to be immutable after they’re built.

It's on a Raspberry Pi 5 running Raspberry Pi OS.

Also, I've brought this exact point up elsewhere, that Docker doesn't seem like it was meant for this purpose, to distribute server applications to end users, but to be used by developers who need a reproducible environment, and that dockerizing things can cause as many problems as they solve, but I got a fair amount of push back. I keep running into apps that are distributed mainly or exclusively through docker, like nginx proxy manager.

In my case, I'm already using containers, whether in the form of cheap low spec VPSes or as proxmox containers on an old anemic laptop, so having to make a virtual turducken just to host one app adds frustration and complexity.

[–] folekaule@lemmy.world 3 points 4 days ago (1 children)

I understand Docker can be confusing, especially if you're not a developer. Docker was developed to solve the problem of "it works on my computer" (but not yours), meaning it is meant to behave the same regardless of where it is installed. It does this by carrying all its dependencies with it. How well it succeeds in solving the problem is up for debate and I'm not here to debate the merits of Docker anyway.

I would say two things: don't get discouraged:; it has a learning curve. And conversely: don't think Docker solves everything, either. Understanding how it works and what it can do is your best bet at using it successfully or even deciding that your use case is not right for it.

I'm not familiar with Otter wiki (just heard about it today in this thread), but I will go by the online docs and see if I can help you get going. Going by the docker compose instructions, the example shows this compose file:

services:
  otterwiki:
    image: redimp/otterwiki:2
    restart: unless-stopped
    ports:
      - 8080:80
    volumes:
      - ./app-data:/app-data

The two last lines are key: the volumes section. The first and only entry maps a local directory ./app-data outside the container through a bind mount, to the path /app-data (note the leading slash) inside the container. It is mapped by default read-write, so the container can write to the directory. You can also read/write from the host side and put files you want in there.

The files here are only stored in that one place (i.e., not copied), so if you want backups you need to take care of that separately.

For your use-case, it may be enough to use the customization instructions for Otter wiki. Notice how their customized docker compose file has a second volume in it. In their example, you would put additional files into the ./custom directory on the host. It works the same as the app-data volume.

That takes care of just running the application, but what if you wanted to customize it more? That is where you need to use the source and git. I am going to just use a fictional example app for this, because Otter wiki app may have some extra steps that can make it confusing. Basically what you want to do is clone the git repo of whatever you're building:

git clone https://github/whatever

Now you have the source. You can add files, make code changes, whatever. And once you're done with that you will use git as usual and commit the changes, push it to your branch, and maybe open a PR to the original repo. That's not important for Docker.

The next thing you do is build the Docker image. Many people confuse Docker images and containers, but on short: the image is like the file system for the container, and the container is an instance of that file system + processes running on a Docker host. Many containers can run the same image on the same host and in fact that is how you horizontally scale an application.

Once you have the image, you can just run it locally, or you can push it to a registry. Here is how you would do that:

# Build the local image in the context . (current directory) and tag it as my-cool-app with tag latest
# This uses the instructions in the Dockerfile to build the image. It can run commands, copy files, etc.
docker build . -t my-cool-app:latest 
# ...lots of messages...

# Run the app - press control-C to stop it
docker run --rm -it my-cool-app:latest

If you want to push it to Docker hub or another registry:

# Tag the image with the repo name in front
docker tag my-cool-app:latest registry.example.com/myuser/my-cool-app:latest 
# Push the image to the registry
docker push registry.example.com/myuser/my-cool-app:latest

One thing to keep in mind here is do not include any secrets with the image. If you do, anyone who can download the image can read them, because they get baked in with it.

Let me know if you have any other questions and I'll be happy to answer.

[–] early_riser@lemmy.world 1 points 4 days ago* (last edited 4 days ago) (1 children)

This was wonderfully detailed thank you have an upvote. Though I should clarify why I'm messing with git in the first place. Most wikis have some sort of revision control on wiki pages. The ethos, at least on sites like Wikipedia which uses MediaWiki under the hood, is to allow anyone to edit, but record every change so bad edits or vandalism can be reverted. Otter has elected to use git as the revision control system for the wiki itself, with wiki pages being markdown files stored on the file system and tracked by git. If you have a bunch of pre-existing markdown files you want to put onto the wiki, you have to add them to the repo in the CLI.

If I understand the relationship between the container and host correctly, the instance of git that's tracking the changes in the wiki lives inside the container, but the files are most easily accessed outside the container in the persistent volume set up by docker compose, which is running a completely different instance of git with its own configuration. When I try telling git to track the new files, I'm telling the git that's on the host, not the git that's in the container.

[–] folekaule@lemmy.world 2 points 4 days ago (1 children)

Ah ok. That explains a lot. I think what you are looking for is the git web server option for Otter wiki.

How that probably works is that there is a git repo inside the container, and probably stored in /app-data. If you have that mount set up you may see what looks like a bare git repo in there.

If you want to poke around inside the container, you can run a shell inside of it like this, assuming /bin/bash exists in the container:

docker exec -it containername /bin/bash

Anyway, you don't need to mess with that, because Otter wiki exposes a git server itself. All you have to do is clone the URL it gives you in the GUI, add your files, commit and push.

So the most straightforward way is:

  1. Clone the repo to a local working copy: git clone https://otterwiki.example.com/repopath (the URL should show in the UI)
  2. Enter the directory: cd ./repopath
  3. Make your changes, add files, etc.
  4. Stage the changes git add .
  5. Commit the changes git commit -m "imported buncha files"
  6. Push them to the origin remote (Otter wiki): git push

If you're not comfortable with the git command line, there are a bunch of TUI and GUI git clients you can use. It makes no difference which one. I usually just use the built-in vscode one for my hobby projects.

[–] early_riser@lemmy.world 1 points 3 days ago (1 children)

Thanks. I had been skipping over the git-specific portions of the docs because it didn't click that it would be relevant. It sounds like the intended way to add files is to add the files to a local repo, then push them to the wiki. I still have to figure out how that works but you've pointed me in the right direction for further troubleshooting.

[–] folekaule@lemmy.world 1 points 3 days ago

Happy to help. You may want to check out the section on Repository Management.

The key here is to just treat it like any other git repo (like one on GitHub). In fact, you can set it up to pull/push from/to GitHub or another repo also, for off-site backup or collaboration outside your network.

Make sure to clone the report to a local working copy first. From there, it should be pretty simple once you're familiar with the most common git commands (or use a UI).

[–] ikidd@lemmy.world 1 points 4 days ago* (last edited 4 days ago)

not to distribute server applications to end users, but to be used by developers who need a reproducible environment,

What? No. It's extremely suited to be used as a server for client applications. I think you might want to learn a great deal more about docker before you come to that conclusion.

Use bind mounts instead of named volumes for persistent data and it's a lot more predictable to use like you want.

[–] tofu@lemmy.nocturnal.garden 1 points 4 days ago

The repo should just be some files, not actively "managed" from inside or outside the container. Interfering from outside might still cause some confusion.

I assume the volume is created in /var/lib/docker/volumes. What's the error once you configured username and email?

If you can't get it to work from outside, you can "log into" the running docker container with docker exec -ti CONTAINERID /bin/sh.