I’ve been getting asked to put this together for years including in official GitHub issues. I always knew it would be a great idea but it turned out even better than I expected. This image works great on all platforms including Raspberry Pi!
This is based off my Minecraft Bedrock Linux Dedicated Server scripts for Linux project. I’m going to release a version for the Java Minecraft edition as well so stay tuned for that.
The official GitHub repository is located here.
The official Docker Hub repository is located here.
If you are looking for the Java version of the Docker container it is located here. This is for the Bedrock edition of Minecraft.
You can also run my Geyser + Floodgate Java Minecraft Server container and Bedrock players will be able to connect to it!
It’s now possible to convert your worlds between Bedrock and Java versions. Check out my guide on Chunker here for more information.
Features
- Sets up the official Minecraft Bedrock Server (currently in alpha testing)
- Fully operational Minecraft Bedrock edition server in a couple of minutes
- Adds logging with timestamps to “logs” directory
- Multiarch Support – all Docker platforms supported including Raspberry Pi
- Automatic backups when container/server restarts
- Supports multiple instances — you can run multiple Bedrock servers on the same system
- Updates automatically to the latest or user-defined version when server is started
- Files stored in named Docker volume allowing for extremely easy access/editing and leveraging more advanced Docker features such as automatic volume backups
- *NEW* – Box64 support added for improved speeds on aarch64 (ARM 64 bit)
Usage
First you must create a named Docker volume. This can be done with:
docker volume create yourvolumename
Now you may launch the server and open the ports necessary with one of the following Docker launch commands.
With default ports:
docker run -it -v yourvolumename:/minecraft -p 19132:19132/udp -p 19132:19132 -p 19133:19133/udp -p 19133:19133 --restart unless-stopped 05jchambers/legendary-bedrock-container:latest
With custom ports:
docker run -it -v yourvolumename:/minecraft -p 12345:12345/udp -p 12345:12345 -p 12346:12346/udp -p 12346:12346 -e PortIPV4=12345 -e PortIPV6=12346 --restart unless-stopped 05jchambers/legendary-bedrock-container:latest
IPV4 only:
docker run -it -v yourvolumename:/minecraft -p 19132:19132/udp -p 19132:19132 --restart unless-stopped 05jchambers/legendary-bedrock-container:latest
Configuration / Accessing Server Files
The server data is stored where Docker stores your volumes. This is typically a folder on the host OS that is shared and mounted with the container. I’ll give the usual locations here but if you’re having trouble just do some Googling for your exact platform and you should find where Docker is storing the volume files.
You can find your exact path by typing:
docker volume inspect yourvolumename
This will give you the fully qualified path to your volume like this:
{ "CreatedAt": "2022-05-09T21:08:34-06:00", "Driver": "local", "Labels": {}, "Mountpoint": "/var/lib/docker/volumes/yourvolumename/_data", "Name": "yourvolumename", "Options": {}, "Scope": "local" }
On Linux it’s typically available at:
/var/lib/docker/volumes/yourvolumename/_data
On Windows it’s at
C:\ProgramData\DockerDesktop
but may be located at something more like
\wsl$\docker-desktop-data\version-pack-data\community\docker\volumes\
if you are using WSL (Windows Subsystem for Linux).
On Mac it’s typically
~/Library/Containers/com.docker.docker/Data/vms/0/
If you are using Docker Desktop on Mac then you need to access the Docker VM with the following command first:
screen ~/Library/Containers/com.docker.docker/Data/com.docker.driver.amd64-linux/tty
You can then normally access the Docker volumes using the path you found in the first step with docker volume inspect
Most people will want to edit server.properties. You can make the changes to the file and then restart the container to make them effective.
Backups are stored in the “backups” folder
Log files with timestamps are stored in the “logs” folder.
Version Override
In some scenarios you may want to run a specific version of the Bedrock server. That is now possible by using the “Version” environment variable:
-e Version=1.18.33.02
For example:
docker run -it -v yourvolumename:/minecraft -e Version=1.18.33.02 -p 19132:19132/udp -p 19132:19132 --restart unless-stopped 05jchambers/legendary-bedrock-container:latest
This is useful if Microsoft hasn’t released versions of the client and dedicated server at the same time so you can match whichever version your players can connect with.
Clean Environment Variable
If the server is having trouble starting you can clean the downloads folder and force reinstallation of the latest version like this:
docker run -it -v yourvolumename:/minecraft -e Clean=Y -p 19132:19132/udp -p 19132:19132 --restart unless-stopped 05jchambers/legendary-bedrock-container:latest
This is useful if a download corrupted or something modified your container contents as it will clear everything out and reinstall the latest Bedrock server fresh.
Disable Box64 (aarch64 only):
If you are having trouble running the dedicated server with Box64 support you can tell it to use QEMU instead with:
-e UseQEMU=Y
For example:
docker run -it -v yourvolumename:/minecraft -e UseQEMU=Y -p 19132:19132/udp -p 19132:19132 --restart unless-stopped 05jchambers/legendary-bedrock-container:latest
TZ (timezone) Environment Variable
You can change the timezone from the default “America/Denver” to own timezone using this environment variable:
docker run -it -v yourvolumename:/minecraft -e TZ="America/Denver" -p 19132:19132/udp -p 19132:19132 --restart unless-stopped 05jchambers/legendary-bedrock-container:latest
A list of Linux timezones is available here.
NoPermCheck Environment Variable
You can skip the permissions check (can be slow on very large servers) with the NoPermCheck environment variable:
docker run -it -v yourvolumename:/minecraft -e NoPermCheck="Y" -p 19132:19132/udp -p 19132:19132 --restart unless-stopped 05jchambers/legendary-bedrock-container:latest
Troubleshooting Note – Oracle Virtual Machines
A very common problem people have with the Oracle Virtual Machine tutorials out there that typically show you how to use a free VM is that the VM is much more difficult to configure than just about any other product / offering out there.
It is because there are several steps you need to take to open the ports on the Oracle VM. You need to both:
- Set the ingress ports (TCP/UDP) in the Virtual Cloud Network (VCN) security list
- *and* set the ingress ports in a Network Security Group assigned to your instance
Both of these settings are typically required before you will be able to connect to your VM instance. This is purely configuration related and has nothing to do with the script or the Minecraft server itself.
I do not recommend this platform due to the configuration difficulty but the people who have gone through the pain of configuring an Oracle VM have had good experiences with it after that point. Just keep in mind it’s going to be a rough ride through the configuration for most people.
Troubleshooting Note – Hyper-V
There is a weird bug in Hyper-V that breaks UDP connections on the Minecraft server. The fix for this is that you have to use a Generation 1 VM with the Legacy LAN network driver.
There is a second fix that was shared by bpsimons here. For that fix you need to install ethtool first with sudo apt install ethtool. Next in your /etc/network/interfaces file add “offload-tx off” to the bottom as the issue appears to be with TX offloading.
Here’s an example:
# The primary network interface auto eth0 iface eth0 inet static address 192.168.1.5 netmask 255.255.255.0 network 192.168.1.0 broadcast 192.168.1.255 gateway 192.168.1.1 offload-tx off
This can also be done non-persistently with the following ethtool command:
ethtool -K eth0 tx off
Additional Support
The comments section right here is the best place for support. The second best place is the GitHub issues section.
I will add additional documentation based on what problems people are running into / questions people are asking because right now I’m not really sure what those will be yet. Definitely let me know if you need any of these things!
Hi,
First of all – thanks for all the work put into the container and the underlying scripts. Your posts have been the reason that I have bought a Raspberry Pi 4 (8 GB) with Kingston M.2 SATA and the Argon One case; what a wonderful combination that works really well.
I have installed Ubuntu Server 22.04 on the Pi along with your Bedrock Docker Container; and as other have commented, it initiates a fully-fledged Minecraft server within a few minutes. No errors – yay!
However, I have had quite a few problems connecting to the server from my LAN. The Raspi Minecraft server shows up automatically on the “Friends tab” in Minecraft on Windows and iOS, but whenever I am trying to join, it shows “unable to connect to world” within approx. 10 seconds.
I have tried to boot up the Minecraft server on my Windows 10 PC, and it allows me to join from iOS devices effortlessly. Hence, I think it is more of a Raspberry Pi-based issue than a router-based issue.
I am using a fresh Ubuntu installation and default settings for my Minecraft docker container. Do you have some useful references or tools that I can use to troubleshoot this issue? I am no stranger to Ubuntu but quite new to Minecraft, so there might be something that I have missed.
I am looking forward to solving this issue; the server is for my daughter and her cousins 🙂
Hey Chris,
Thanks for your kind words about the container! You did some great troubleshooting here to narrow things down. The M.2 SATA drive should be a fantastic choice as well! The default Ubuntu installation shouldn’t be causing too much trouble as ufw (the Ubuntu universal firewall) is not installed/enabled by default.
Are you unable to join the containerized world on any platforms, or is it just iOS? Do you see any activity in the server console when people are trying to join? iOS really prefers IPV6 so it’s possible it could be IPV6 related if those are the only ones having trouble joining.
When you tried it on your PC did you run it natively or did you also use Docker / the container?
What does your Docker startup line look like? I believe for Bedrock almost all of the communication uses UDP. This means it’s important that when your firewall settings pop up for Minecraft on Windows for example you choose to allow “Public” traffic as UDP traffic is always considered public basically. This means it’s very important that you have both sets of ports for TCP and UDP (like the examples, TCP and UDP for both IPV4 and IPV6). I bring this up because the server info port I think is one of the few things that actually uses TCP but actually playing the game on Bedrock will be all UDP traffic.
You may want to try running the container as sudo / root for a test so you’d add sudo to the front of your Docker launch line. This would be to rule out permissions issues like maybe your user isn’t a member of the “docker” group in Linux or something like that. Sometimes there are weird permissions related restrictions on ports that aren’t immediately obvious until you try it as root and it works (then we can figure out what the specific problem is as we’ve narrowed it down enough for that if this was the case). If this fixed it we would still want to figure out the cause as a lot of the security benefits you are getting from Docker go out the window when running Docker as root basically.
I take it there’s no port forwarding issues involved if this is on LAN but I figured I’d mention it anyways as people often leave out the “UDP” part of the rules on their firewall configs when port forwarding (common mistake for people just starting to play with the servers a bit).
One thing you may want to try that has been wildly successful on my non-containerized version of the script is to try changing your server off the default ports. That means don’t use either of the default ports and select your own ports. This is definitely worth a try as there are some really weird bugs with the Bedrock default ports. We’ve seen this impact both discovery with the “Friends” menu and connecting. I have a setting custom ports example launch line here as well showing an example.
Let’s see if we can narrow it down a little and I’m sure we can figure it out here!
Hi James,
Thank you for the comprehensive troubleshooting. It turned out that the main problem was that I had installed two instances of docker; one via snap and another via apt. That’s what you get from mindlessly following guides on the internet 😉
Once I got rid of the snap version of docker, rebooted, and changed the default ports, the problem was solved.
Running the game on the Raspberry Pi is actually really responsive and I don’t perceive any lag when breaking blocks and moving around. However, there are two issues that hold back the Pi as a useable mini-server:
1. Loading time. When joining on my Windows 10 PC and iPhone, it takes between 2 – 3 minutes from pressing the “join” button to actually accessing the game. This seems to be independent of different values of view-distance in server.properties. I could probably live with the wait (hey, Windows 98!), but it is probably too long for the target audience (6 – 12 years).
2. World generation time; this is lesser of an issue than (1), but you need some patience when flying around, especially in areas that have never been seen before. Even when the areas have been visited before, I have a feeling that the “AutoCompaction” feature of the server actively shrinks the size of the database, removing entries of auto-generated content. When you revisit some areas, it definitely feels like going back to square one, relying on the CPU-intensive seed-based world generation.
Are high loading times on the Pi a common issue, or is it just me? According to your benchmark, the SSD works as intended with a score of just below 8000.
If the x86 emulation continues to improve, I think this could be a nice, self-hosted server. In the meantime, I will probably find other uses for the little Pi.
Hey Chris,
Great findings and results! That about lines up with my experience as well. It’s “almost” good enough on the Pi. Yours is about exactly where mine is at performance wise when running on the Pi.
The only other thing within your control is that 64 bit operating systems do seem to do a bit better than if you are using the regular 32 bit ARM distro (you may be using 64 bit already). SSD scores looking fantastic, nothing to be done there.
There’s another option specifically for aarch64 / 64 bit ARM called box64 that is a different type of emulator than QEMU. People have got this working before on the non-containerized version and I have tried to build it statically to put in the container and box64 has issues with static builds so I was waiting for them to fix that to try to implement it in the container. This may give it another additional boost and others have said it bridges the final gaps that you outlined here.
I guess I could probably have the Docker build server actually just build box64 for the aarch64 image. Maybe it’s time for me to experiment with that a little bit more since I don’t think the developer has posted any progress in fixing static builds of the box64 emulator yet. I actually did reach out on their GitHub and others had already been posting about it as well so I mostly just “seconded” it. Theoretically the Docker container could just build a dynamic version for the container using the container’s dependencies.
The container is meant for all platforms for sure and it’s totally conceivable to run the same server on multiple different platforms potentially. We’ve had people start out hosting on the Pi and then migrate to x86_64 later and the container will do this without a hitch for sure. For the Pi specifically I am guessing that the next Pi will handle this with just pure QEMU. In the mean time I am going to continue to explore getting box64 in the container. If it ends up being a big enough leap in performance I may move my containers (or to be more semantically accurate the contents of the Docker volume i.e. my server files) back to the Pi for example.
Thanks for the feedback and take care!
“Fully operational Minecraft Bedrock edition server in a couple of minutes”
This is completely true. I had a Raspberry Pi 400 and purchased an SSD for this project. I’ve never used Docker before and figured that I might as well try it out first to see if it was easier than manually setting everything up. Your container came right up, and although I may have questions later I just wanted to leave a comment thanking you for all of your work.
Hey Keith,
Thanks for leaving this, it’s great to hear that as this part of it is quite new! I’m very glad it helped and definitely feel free to stop by if you have any questions/problems!
Hi,
I’ve used the container using the following command:
docker run -it -v bedrockserver:/minecraft -e Version=1.18.31.04 -p 19132:19132/udp -p 19132:19132 05jchambers/legendary-bedrock-container:latest
However, the container instantly fails, and closes likely due to there being no server.properties (every other server i’ve tried automatically generates it, strange)
I will try to copy one over and run again, but here is the file structure after first run.
drwxr-xr-x 2 root root 4096 May 31 13:39 backups
-rwxrwxr-x 1 root root 97383832 Apr 27 02:35 bedrock_server
-rw-rw-r-- 1 root root 24111 Apr 27 02:26 bedrock_server_how_to.html
-rwxrwxr-x 1 root root 149737912 Apr 27 02:35 bedrock_server_symbols.debug
drwxrwxr-x 26 root root 4096 Apr 27 02:35 behavior_packs
-rw-r--r-- 1 root root 0 May 31 13:41 Dedicated_Server.txt
drwxrwxr-x 8 root root 4096 Apr 27 02:35 definitions
drwxr-xr-x 2 root root 4096 May 31 13:39 downloads
drwxr-xr-x 2 root root 4096 May 31 13:39 logs
-rw-rw-r-- 1 root root 580 Apr 27 02:26 release-notes.txt
drwxrwxr-x 4 root root 4096 Apr 27 02:35 resource_packs
drwxrwxr-x 15 root root 4096 Apr 27 02:35 structures
-rw-r--r-- 1 root root 30 May 31 13:39 version_installed.txt
Hey Volwar,
It’s definitely just the bedrock server that generates it. I haven’t heard of this before or seen anyone else having it in Bedrock but I have seen it in the Java version.
I just added the same workaround as there where I just copy a default server.properties if it’s not there. No idea why it only happened to you and nobody else but I doubt you’re the only one it will / has happened to so I updated the container to fix this. The latest version should take care of it, thanks for letting me know!
Hi James,
amazing work getting arm emulation working in the container!
I tried starting the container via docker-compose however I had issues with screen running without a terminal attached. Terminal is available when running via docker run -it, but not when started via docker-compose.
My current workaround is as follows (there is probably a better way):
version: "3.5"
services:
app:
image: 05jchambers/legendary-bedrock-container:arm64v8
restart: "unless-stopped"
ports:
- 19133:19133
- 19133:19133/udp
- 19132:19132
- 19132:19132/udp
volumes:
- ./data:/minecraft
entrypoint: ["/usr/bin/script", "-c TERM=vt100 /bin/bash /scripts/start.sh"]
Hey Ladislav,
Thanks for leaving this! I actually haven’t tried it with docker-compose yet so you may be the first.
These workarounds look pretty reasonable here. I almost wonder if me just adding -c term=vt100 to set the terminal like you have would fix it if I made it a part of the container image itself.
I did find something here that for docker-compose the equivalent options would be:
services:
myservice:
...
stdin_open: true # docker run -i
tty: true # docker run -t
Maybe you could just add the stdin_open and tty lines and it might do the same thing here. If this works let me know and I could probably even distribute a docker-compose file right in the main repository so that people know that’s the working base config for it.
I’ll definitely look into getting docker-compose set up here and do some testing and see if I can eliminate this issue for you at the container or docker-compose level. Thanks for letting me know this was happening / your fixes for it!
Hi James,
I just stubled upon your container project for Bedrock. I have a solution for Ubuntu 22.04 LTS which doesnt require manual install 🙂
I posted this to the official Bedrock server bugs page. Perhaps this might be a nicer and more reliable way to install it 🙂
—
It appears they updated the OpenSSL Version in Ubuntu 22.04 LTS.
I was able to resolve myself using the following commands:
echo "deb http://security.ubuntu.com/ubuntu impish-security main" | sudo tee /etc/apt/sources.list.d/impish-security.list
sudo apt-get update
sudo apt-get install libssl1.1
If this works for you, show me some gratitude!
Hey It’sMeStevieG,
Welcome! So I have seen that method before and believe it or not although it doesn’t look like it our methods are actually the same.
You’re adding the URLs for Impish to the sources.list file and I’m actually using the exact same .deb package from Impish. They are completely identical packages / files.
Your method has the advantage that it would update itself on a standalone installation but Docker doesn’t really work this way. I’ll have to manually update the package in the container when they release updates for it but because of the way Docker works those are all “frozen” in the Docker image anyway. It’s all locked into the Docker image once you build the Dockerfile (if you aren’t using the Docker Hub version).
We only need one package though. We can just navigate to the Ubuntu repositories and download the package we need: http://archive.ubuntu.com/ubuntu/pool/main/o/openssl/. Then we can just do a
sudo dpkg -i mypackage
. This will keep all of your repositories/packages on 22.04 and not change anything from stock configuration. This will prevent any conflicts with Impish packages (that’s Ubuntu 21.10, a different version). When you add it to the sources.list technically it could install any package from Impish.I’ve never heard of conflicts from this for Impish specifically but I’ve certainly seen conflicts before when people have added things like 18.04 (bionic) which is a variation of the fix you posted that I’ve seen that I definitely wouldn’t recommend (that’s not even close of a version, 18.04 packages with 21.10!).
Normally you’d want to do this when you install a package that has hundreds of dependencies. Those are the situations most likely to actually break from this (you’ll be replacing hundreds of 22.04 packages with 21.10 packages in that case) but that is when it would be necessary because otherwise you will be manually downloading and installing dozens or hundreds of packages one by one and installing them all with dpkg -i and that’s not realistic. It is realistic if you only need 1 and definitely avoids some potential pitfalls.
Both approaches will for sure work. It will add some extra weight though to have an entire extra distro’s repository (the older versions) available within apt and this would bloat the container a little bit (I do clean apt during generation of the Dockerfile but even cleaned there will be some bloat). The advantage of your way is that it will install future updates for it without me having to download the package (not a big deal for me generating the Docker image for everyone but this would be very annoying on standalone installs).
My final method in code looks like this:
sudo curl -o libssl.deb -k -L http://archive.ubuntu.com/ubuntu/pool/main/o/openssl/libssl1.1_1.1.1l-1ubuntu1.3_amd64.deb
sudo dpkg -i libssl.deb
This is exactly where your method gets the package from. The Ubuntu repositories. The package and files are completely identical. It’s just apt filling in the URL for you when adding it to sources.list. However, when they release different versions of it later than ‘l’ (the letter at the end of the package after 1.1.1) I will have to manually update the Dockerimage .deb package using my method and you wouldn’t.
That sucks for me, but my vision is with a lot of people using the container then it’s worth it for me to add this to my calendar and check for the new package once or twice a week and then regenerate an updated Dockerimage for everyone. This is pretty typical with the other maintenance I do for the non-Docker version of the scripts as well as the Java Minecraft versions (with the Java edition it’s the OpenJDK package I have to worry about with all of the exact same problems or even more than the openssl package).
Thanks for sharing this!
Hey, how do I get this to work on arm
Hey beastminer,
Great question! Believe it or not it’s exactly the same. You will run it as is from the instructions basically with:
sudo apt install docker.io
sudo volume create yourvolumename
docker run -it -v yourvolumename:/minecraft -p 19132:19132/udp -p 19132:19132 -p 19133:19133/udp -p 19133:19133 05jchambers/legendary-bedrock-container:latest
This has been tested on both 32 and 64 bit operating systems for the Pi. If you are having any trouble let me know what you are running into but I think that should get it for you!
Hey, im just simply using an arm machine, though when i run the command, it says: WARNING: The requested image’s platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested
Hey beastminer,
That issue should be fixed in the latest version. I think you may have an earlier version cached.
Can you try:
docker pull 05jchambers/legendary-bedrock-container:latest
and then running again? This issue came up on GitHub here.
Another thing you can do is add
--platform linux/amd64
to the launch line like this:sudo docker run -it -v yourvolumename:/minecraft -p 19132:19132/udp -p 19132:19132 --platform linux/amd64 05jchambers/legendary-bedrock-container:latest
That should no longer be necessary though with the latest version pulled from Docker but that fixed it for the person on GitHub as well (before I figured out I could put it in the Dockerfile to avoid this issue entirely).
You do want to choose linux/amd64 as the platform to run it even on ARM because the Minecraft Bedrock server is only distributed by Microsoft in x86_64. Fortunately Docker will magic it for us and make it work anyway (and much faster than through emulation like my standalone project uses). It’s not really magic but it sure seems like it compared to what we have to do in the standalone version to get it to run on ARM platforms.
We just need to pull the latest or tell it with that –platform switch that yes, we understand and that is exactly what we want Docker to do and it will go right through. If you do a pull and it still won’t launch without putting the flag then maybe I need to do even more in the Dockerfile to make it automatically do this on all platforms. It’s pretty new still so this is certainly possible.
I didn’t get this behavior on Raspberry Pi (32 bit ARM) but the person I linked to in the GitHub thread above was running aarch64 on a Pi and did get this. It may have nothing to do with the platform and may be configuration differences within Docker or even our specific distro’s packages that might explain it. This is the second time I’ve heard of it.
Once I added that line to the main Dockerfile / base image I stopped getting a platform warning even on my Raspberry Pi when launching. For some reason on my Pi previously it displayed that warning and then proceeded to work anyway. It never stopped it from launching but it did for you and the other person and I’m not 100% certain why that is yet. The latest shouldn’t even have the warning unless there’s more going on that I need to fix in the Dockerfile for specific platforms.
Hopefully that helps and let me know if you’re still having issues with it!
I redesigned the entire container around this issue. Thank you to everyone for reporting this.
Now there actually is an image for each platform! Go ahead and do a:
docker pull 05jchambers/legendary-bedrock-container:latest
and now it will select the right image for your platform.
This should definitely get you going if you were having trouble before. It works completely differently basically as the old way was causing too many problems. This is much faster anyway because now the container’s OS does completely match your host’s architecture. This is always faster/more ideal than any of the alternatives.
Let me know if any of you are still having issues!
I am having a hard time locating my server folder on omv 6 .I’ve tried using the command you posted for linux but it simply say its a directory.
Hey masterchief417,
Welcome! I think I can help. So I found a command that I think I need to add to the documentation for this. It’s:
docker volume inspect yourvolumename
Check this out:
james@jamesgigabyte-linux:~$ docker volume inspect minecraftbe
[
{
"CreatedAt": "2022-05-09T21:08:34-06:00",
"Driver": "local",
"Labels": {},
"Mountpoint": "/var/lib/docker/volumes/minecraftbe/_data",
"Name": "minecraftbe",
"Options": {},
"Scope": "local"
}
]
This should give you the exact fully qualified path where your volume is under “Mountpoint”. To get to my volume I would do this:
cd /var/lib/docker/volumes/minecraftbe/_data
You may have to become root before going to this directory. If it tells you access denied try:
sudo su
to temporarily become root. If you want to do this in the GUI it depends on which distro you are using but in Ubuntu you can run the file manager as root with:
sudo nautilus
A new file explorer window will open that is root context. If you want to drag and drop to the files and use the GUI this will give you access to them with the regular GUI. This will be the most comfortable for most people for sure but you can absolutely use either method to navigate to and edit the files (GUI or CLI). Just keep in mind that this is usually a privileged location for security purposes so you will usually need to jump through a hoop to get “root” privileges first before navigating to / editing the files.
It looks like OMV6 is similar (sounds like it’s based on Debian Linux) although they may use a different file manager but if you open a file explorer window and do “ps -A” you can probably figure out what the process name of your file manager is and do a
sudo yourfilemanager
and you should be good to go.I’ll definitely get this added into the docs as well. Hopefully that helps!