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
 

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.

you are viewing a single comment's thread
view the rest of the comments
[–] 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