RetroArch lives in a read-only layer when you run it in a live container
When you launch RetroArch inside a live container, the program itself installs into a temporary filesystem that exists only while the container is running. The moment you shut down the container, that installation disappears — it is not saved to your hard drive. This happens because a live container uses a read-only base image that resets to its original state each time you start fresh.
The actual files land in a layered filesystem managed by your container engine (Docker, Podman, or similar). You do not navigate to them the way you would a normal program folder. Instead, the container presents them to RetroArch as if they were in standard Linux paths like /usr/bin or /opt, depending on how the container was built. The container's creator decides where to place the files when they build the image.
If you want RetroArch to persist — to keep your game saves, configuration files, and ROM library between sessions — you have to mount a folder from your actual computer into the container. That folder becomes the bridge between the temporary container and your permanent storage.
Key Takeaways
- RetroArch files in a live container exist only during that session and vanish when you close the container, unless you mount a persistent folder.
- The program installs into a read-only base layer managed by your container engine, not into a folder you can browse directly on your computer.
- To keep game saves and settings between sessions, you must mount a directory from your host computer into the container using a -v flag (Docker) or -v flag (Podman).
- Configuration files and ROM libraries should live in the mounted folder, not in the container's temporary layer, so they survive a container restart.
How the layered filesystem works in practice
A live container operates in layers. The bottom layer is the read-only base image — this contains the operating system, libraries, and the RetroArch program itself. On top of that sits a temporary writable layer that only exists while the container runs. Any changes you make during the session (installing plugins, downloading ROMs, changing settings) write to that temporary layer.
When you close the container, the temporary layer is discarded. The next time you start the container, you get a fresh copy of the base image with a brand-new temporary layer on top. This design keeps containers lightweight and predictable — each run starts from the same known state.
The container engine handles all of this invisibly. You do not see these layers as separate folders. Instead, the container presents a unified filesystem to RetroArch, so the program behaves as if everything is in one place. RetroArch does not know it is running in a container and does not care where the files actually live on your hard drive.
Mounting a folder so your data persists
To keep RetroArch settings and game saves between container sessions, you create a mount point — a connection between a folder on your computer and a path inside the container. When you mount a folder, the container can read and write to your actual hard drive, and those changes stick around after the container closes.
In Docker, you use the -v flag when you start the container. For example:
docker run -v /home/user/retroarch-data:/home/retroarch/.config/retroarch myimage
This command tells Docker: "Take the folder /home/user/retroarch-data on my computer and make it appear inside the container at /home/retroarch/.config/retroarch." Anything RetroArch writes to that path now goes to your actual hard drive. When you stop the container and start it again, that folder is still there with all your data.
Podman uses the same syntax. The key is choosing the right paths: the left side of the colon is your computer's path, the right side is the container's path. If you get the container path wrong, RetroArch will not find your settings or ROMs.
Where to store ROM files and configuration
ROM files and RetroArch configuration should both live in the mounted folder, not scattered across the container's temporary layer. This keeps everything in one place and ensures nothing gets lost when the container restarts.
A common setup is to create a single folder on your computer — say, /home/user/retroarch-data — and mount it into the container. Inside that folder, create subdirectories: one for ROMs, one for configuration, one for save states. Then tell RetroArch where to find each one through its settings menu or configuration file.
If you store ROMs in the container's temporary layer instead, they vanish the moment you close the container. You would have to re-copy them every time you want to play. Mounting a folder solves this entirely.
Why live containers reset their installations
Live containers are designed to be disposable. Each time you start one, you get a clean, predictable environment. This is useful for testing, for running untrusted software safely, and for keeping your main computer uncluttered. The trade-off is that nothing persists unless you explicitly mount a folder.
This design also means you cannot accidentally break a container by installing conflicting software or corrupting system files. If something goes wrong, you straightforward close the container and start a fresh one. The base image is never modified.
For RetroArch, this means you can experiment with different emulator cores, change settings, and read ROMs without worrying about cluttering your computer or creating a mess that is hard to clean up. When you are done, close the container. Your computer is exactly as it was before.
Checking what is mounted and where
If you need to see what folders are mounted inside a running container, you can use the docker inspect command (or podman inspect for Podman). This shows you the mount points and confirms that your data folder is connected to the right path inside the container.
You can also open a shell inside the running container and navigate the filesystem directly. With Docker, use docker exec -it container_name /bin/bash. This opens a terminal inside the container where you can browse folders and confirm that your mounted directory is accessible at the path you specified.
If RetroArch cannot find your ROMs or settings, the first thing to check is whether the mount is actually connected. Use these commands to verify before troubleshooting RetroArch itself.
Moving data between containers or updating the image
Because your data lives in a mounted folder on your computer, not in the container, you can easily switch to a different container image or update to a newer version. straightforward mount the same folder into the new container, and RetroArch will find all your settings and ROMs exactly where you left them.
This also means you can run multiple containers with the same data folder if you want to test different configurations or emulator versions side by side. Each container sees the same ROMs and settings, but maintains its own temporary layer for any changes you make during that session.
If you ever want to back up your RetroArch data, just copy the mounted folder to another location on your computer. No special tools or container commands needed — it is just a regular folder.
Frequently Asked Questions
What happens to my ROMs and settings when I close the container?
If they are stored in a mounted folder, they stay on your computer and are still there when you start the container again. If they are stored only in the container's temporary layer, they disappear. Always mount a folder for anything you want to keep.
Can I use the same mounted folder with different container images?
Yes. As long as both containers mount the same folder at a path where RetroArch looks for its data, they will share the same ROMs and settings. This is useful for testing different versions or configurations.
How do I know if my mount is working correctly?
Open a shell inside the running container with docker exec -it container_name /bin/bash, then navigate to the mounted path and list the files. If you see your ROMs and configuration files, the mount is working. If the folder is empty, check that you specified the correct paths in the -v flag.
Do I need to install RetroArch again every time I start the container?
No. RetroArch is part of the base image, so it is already installed and ready to run. The container starts with a fresh temporary layer, but the program itself is there. You only need to mount your data folder so your settings and ROMs are available.
What if I want to keep changes to RetroArch's core files between sessions?
Mount the entire RetroArch configuration directory into the container. This includes cores, plugins, and all settings. Any changes you make are written to the mounted folder and persist across container restarts. Just make sure you have enough disk space for the cores you read.