Okey-Dokey. /data it is!
I just want to say thanks for this project. I was able to follow your direction you laid out and got everything up and running with several of the one click addons I have been wanting to use. Again, thanks and great work.
2 Likes
At the risk of asking a stupid question: is there an EZ-start script for Mac?
I only see Linux and Windows mentioned.
I'm up for installing manually but the EZ-start method seems so elegant 
The EZ-Start process works from the command line on MacOS as well.
Thanks!
The EZ-Start script worked great on my Mac mini.
The first few times I ran the script I got an error that the -d was an unknown flag...it turned out to be extra characters in the command string and once I re-entered the script on a single line it worked perfectly.
Thanks @bnhf for this great project!
1 Like
I installed the ezstart late last year to replace my piece-meal setup. I'm not sure if I had a problem before, but definitely since. when my win11 server reboots, portainer fails to start. a restart of docker fixes (or manually starting portainer and restarting other stacks).
I can't find anything in logs, and I see no sign of db corruption as just restarting docker fixes.
before I script a ps to restart docker a minute after boot I thought I'd ask here for help since gemini want's to fix problems I don't have.
Sounds like you might need to delay starting the docker service on bootup.
One solution found in a search Q&A: How Do I Delay the Start of my Windows Service? | The Core Technologies Blog
after my earlier post I did remember the delay option in services so I went there and docker was set to manual. I changed to automatic and rebooted. portainer again failed to start, checked services again to set delayed start, but it had reverted back to manual.
I'm going to turn off Start Docker Desktop when you sign in to your computer in the docker gui and try the service again.
so this needs to stay on. the service is not actually running in the background all the time. having the service running does not mean the docker engine is running.
back to square1
edit; to be clear this does not have to do with windows booting. it can be fully booted, but the first time docker starts, it cannot/will not start portainer.
also portainer is set to restart always
can we get a variable for the /data location? maybe i'm alone, but on windows I prefer c:\data or /mnt/c/data (portainers website is unclear, but manual install only works with /mnt/c/data)
the issue I have is ez-start sets portainer to /data and that's in the wsl vm so on startup it's extremely slow, the stacks with /mnt/c/data load faster, but don't all load correctly with portainer/olivetin volume still unreachable.
I always have to remote in and start/restart portainer, then start/restart all my stacks via portainer, then Reload M3U for my ah4c sources in CDVR.
when I manually installed portainer with /mnt/c/data, portainer did startup automatically as it should on pc reboot, but installed via olivetin it never seems to.
hope that makes sense, been trying to wrap my head around this for months
There's always been an env var for that, which is HOST_DIR. If you want to change it in an existing installation, you can copy the contents of your current HOST_DIR value to a new location, then stop the olivetin stack and change HOST_DIR to the new value.
You can also add HOST_DIR to the EZ-START command line for new spin-ups, or change it when you're running the OliveTin Environment Variables Generator/Tester -- so there are lots of options to set it however you'd like.
Keep me informed on this, as using your WSL Linux distro's filesystem is actually known to be faster than crossing-over to the Windows filesystem, so kind of the opposite of what you're saying. However, startup related timing may be another matter.
1 Like
ezstart HOST_DIR still put portainer here
VOLUME [/data]
but I decided, I'd just ride with defaults and removed docker, wsl. then re-installed wsl, then both debian and docker with the command scripts from the old soup2nuts pack.
ran ezstart default
docker run -d --name olivetin-ezstart
--pull always
-p 1338:1337
-e EZ_START=-ezstart
-e CHANNELS_DVR=10.0.0.7:8089
-e TZ=$(readlink /etc/localtime)
-v /config
-v /var/run/docker.sock:/var/run/docker.sock
bnhf/olivetin:latest
olivetin env generator was
TAG=latest
DOMAIN=localdomain tailscale-domain.ts.net
HOST_PORT=1337
CHANNELS_DVR_HOST=10.0.0.7
CHANNELS_DVR_PORT=8089
CHANNELS_CLIENTS=
ALERT_SMTP_SERVER=
ALERT_EMAIL_FROM=
ALERT_EMAIL_PASS=
ALERT_EMAIL_TO=
UPDATE_YAMLS=true
UPDATE_SCRIPTS=true
TZ=America/Chicago
HOST_DIR=/data
DVR_SHARE=/mnt/c/channels-data
LOGS_SHARE=/mnt/c/programdata/channelsdvr
TUBEARCHIVIST_SHARE=/mnt/c/channels-data
DVR2_SHARE=
LOGS2_SHARE=
TUBEARCHIVIST2_SHARE=
DVR3_SHARE=
LOGS3_SHARE=
TUBEARCHIVIST3_SHARE=
HOST_SFS_PORT=8080
FOLDER=/web
PORTAINER_TOKEN=ptr_yxxxxxxxxxxxxxxxxxxxxxxxxxx=
PORTAINER_HOST=10.0.0.7
PORTAINER_PORT=9443
PORTAINER_ENV=1
PERSISTENT_LOGS=false
on windows startup, docker starts, but never starts portainer or olivetin. no log entries.
if I quit docker, then start docker, portainer starts and lets me login to 9000, but any action results in this little popup
Failed loading environment
Dial unix /var/run/docker.sock: connect: connection refused
I can restart portainer in docker and then it works.
everytime portainer starts the log is the same;
2026-05-31 18:47:09.090 | 2026/05/31 11:47PM INF github.com/portainer/portainer/api/cmd/portainer/main.go:330 > encryption key file not present | filename=/run/secrets/portainer
2026-05-31 18:47:09.090 | 2026/05/31 11:47PM INF github.com/portainer/portainer/api/cmd/portainer/main.go:370 > proceeding without encryption key |
2026-05-31 18:47:09.090 | 2026/05/31 11:47PM INF github.com/portainer/portainer/api/database/boltdb/db.go:137 > loading PortainerDB | filename=portainer.db
2026-05-31 18:47:09.639 | 2026/05/31 11:47PM INF github.com/portainer/portainer/api/cmd/portainer/main.go:527 > instance already has an administrator user defined, skipping admin password related flags. |
2026-05-31 18:47:09.639 | 2026/05/31 11:47PM INF github.com/portainer/portainer/api/chisel/service.go:198 > found Chisel private key file on disk | private-key=/data/chisel/private-key.pem
2026-05-31 18:47:09.639 | 2026/05/31 23:47:09 server: Reverse tunnelling enabled
2026-05-31 18:47:09.639 | 2026/05/31 23:47:09 server: Fingerprint zNw9xxxxxxxxxxxxxxxxxxxxxeAhwEC3w=
2026-05-31 18:47:09.740 | 2026/05/31 23:47:09 server: Listening on http://0.0.0.0:8000
2026-05-31 18:47:09.740 | 2026/05/31 11:47PM INF github.com/portainer/portainer/api/datastore/postinit/migrate_post_init.go:114 > Executing post init migration for environment 1 |
2026-05-31 18:47:09.760 | 2026/05/31 11:47PM INF github.com/portainer/portainer/api/cmd/portainer/main.go:643 > starting Portainer | build_number=22 go_version=go1.25.9 image_tag=2.39.2-linux-amd64 nodejs_version=v22.22.2 pnpm_version=10.27.0 version=2.39.2 webpack_version=5.105.0
2026-05-31 18:47:09.768 | 2026/05/31 11:47PM INF github.com/portainer/portainer/api/http/server.go:367 > starting HTTPS server | bind_address=:9443
2026-05-31 18:47:09.768 | 2026/05/31 11:47PM INF github.com/portainer/portainer/api/http/server.go:351 > starting HTTP server | bind_address=:9000
not sure why it doesn't work with mostly defaults
HOST_DIR is for the location of OliveTin data. Portainer data is stored in a Docker/Portainer Volume called portainer_data. I assume you meant OliveTin data. Anyway, I'll take a look at this tomorrow.
I was thinking both, but decided it may not be a good idea. anyway when I gave up and went to one-click my ah4c's something told me to try editing olivitin env in portainer to HOST_DIR=/mnt/c/data first with re-pull, then setup my ah4c stacks with the same. while checking the ah4c sources were working i realized i was messing around when the new season of rick and morty started, so I checked my ch4c and of course my exvist' audio wasn't working.
while fixing ch4c I rebooted. after verifying ch4c was working 
I realized I needed to check docker.
it was working, everything was running, portainer worked. I think I may have needed to reload m3u in channels for ah4c, but I can work with that.
I'd have to verify again another day, but based on my experience tonight there was something going on with using the HOST_DIR=/mnt/c/data in the ezstart command or simply with ezstart olivetin env creation or stack creation.
i'll keep you posted.
more info. I've had a couple successful pc reboots since my last post. did not even have to reload the ah4c m3u's it just worked. I was awake early this am and noticed the server was idle so I rebooted. came back fine. this afternoon I started messing around with ch4c and my exvist. I rebooted but this time portainer & olivetin were not running, ah4c was but cdvr showed 0 channels. had to start/restart everything again. I'm not sure it was the case for the last 9 months, but right now, I'm thinking a 'busy' cdvr on docker sources connects before portainer can do it's thing. I'll have to put a delay in cdvr service start I guess
I've seen this behavior myself, where Docker Desktop attempts to start various containers at login, but isn't successful. They're typically sitting in an "exited" state. I would consider this to be a bug in Docker Desktop, since the containers themselves are setup to start when Docker Desktop starts.
One approach for dealing with this would be to have your own startup script, that would execute after login (with a delay for Docker Desktop), and would include:
docker start portainer olivetin ah4c
That would restart those three containers, if they're sitting in an exited state. If they're already running, it would do nothing. You could add a curl command or two, that would reload CDVR M3Us or whatever else.
ah4c is usually runnng, olivetin and portainer usually not, and olivetin's static file server is usually partially loaded. I typically stop ah4c, start portainer, restart file server, then start the others. the issue with the started ah4c is it's using a volatile filesystem and adb key's are never the same. it ends up popping the auth on the osprey's, but a 2nd tune after proper startup will clear, but padded or 0pad recordings on same channel will leave the authorization box up during all the recordings.. now I have a 3 minute test record every 3:40am on all ah4c sources to help mitigate.
I will try setting ah4c to not autostart and make a script. I'm thinking I'll have it watch for portainer ports, then check olivetin and file system.
thanks for validating my issue (thought I was crazy or just really stupid). I've always thought it was mainly docker & portainer not playing well, but I can't seem to find much with every google search i've tried. just get the usual, restart=always.
the other thought I had is the fact that wsl installed ubuntu, but olivetin is using debian. I've set debian to default, but I don't know how docker handles these things.
Maybe use depends_on and healthchecks
https://oneuptime.com/blog/post/2026-01-25-docker-compose-depends-on/view
No need to stop ah4c.
If your situation is like what I've seen, you're actually restarting Portainer. To confirm after your next reboot where Portainer is not running, execute this from the Debian command line:
docker inspect -f '{{.State.Status}}' portainer
If you see exited, that means it just needs to be restarted with:
docker start portainer
You can do the same for olivetin, and once confirmed, both can be restarted on one line (which I'm suggesting you could do with a script or even Task Scheduler):
docker start portainer olivetin
This should not be necessary either.
There's something amiss here, as those keys are stored persistently in a properly configured setup. They're stored under $HOST_DIR/ah4c/adb.