Run-script-before-required fails

How or where do you tell Duplicati where a script file is to run it before a backup? I have a application that I want to dump the database before the backup, copy it to host file system and then back up.

I keep getting the below error.

  • 2025-04-12 17:52:00 -04 - [Error-Duplicati.Library.Main.Controller-FailedOperation]: The operation Backup has failed with error: An error occurred trying to start process ‘/usr/local/bin/sh backup_freshrss.sh’ with working directory ‘/app/duplicati’. No such file or directory Win32Exception: An error occurred trying to start process ‘/usr/local/bin/sh backup_freshrss.sh’ with working directory ‘/app/duplicati’. No such file or directory

I’m running Duplicati on Linux in a Docker container.

Thanks

Please see Scripts documentation for general information, however you might want

--run-script-before (Path) Run a script on startup. Executes a script before performing an operation. The operation will block until the script has completed or timed out.

in Options → Advanced options. There’s a group of options further down in selector:

I only know enough about Docker to ask – is file accessible from inside container?
You can probably verify that by going to docker exec and looking at failing paths.

I found the option to run a script in the advanced section. I created the script and do not know how to point where the script is. The script is on my local file system, not in the container.

I want the script to do a sql dump of the application for backup. I think the docker container should be stopped first so the script has to be accessible on the host file system.

I’ve looked at the documentation and did see " --run-script-before (Path)" path to where? In the container? Outside the container? Can I map a volume to the script location on the host file system?

Since Duplicati is in the container, then there’s the problem.

You should already be mapping some, per directions for your image.

https://hub.docker.com/r/duplicati/duplicati
https://hub.docker.com/r/linuxserver/duplicati

Commonly container is to back up some data outside the container.
State information such as configuration and DBs should be on host.
You can probably reuse one of those, or you can add a special one.

So next question is – even if Duplicati can see and run the script (just give Duplicati its path inside the container, with correct permissions, etc. on the script), can you do all that inside?

Containers contain, making it hard to reach outside (I think – I don’t build Docker systems).

I’m pretty sure people have invented various ways to coordinate outside-and-inside, but I’m not able to immediately cite them. Maybe a web or forum search will find some other ideas.

There are also some forum users who know Docker better, and a new way to run a backup.

You should already be mapping some, per directions for your image.

https://hub.docker.com/r/duplicati/duplicati
https://hub.docker.com/r/linuxserver/duplicati

Commonly container is to back up some data outside the container.
State information such as configuration and DBs should be on host.
You can probably reuse one of those, or you can add a special one.

I already have volumes mapped. The question I asked was if you can map a volume to where the script is. If you have the script inside the container as you suggested the next time the container is created or updated the script is not recreated as well. This is why you want volumes for the persistent data to always be present.

I’m still not sure how the before of after scripts work within Duplicati. Any documentation or a post that would explain this would be very helpful.

My answer that you quoted:

if you don’t want to reuse something already mapped.

This was never suggested, but you might have misread it as “script inside the container”.
“just give Duplicati its path inside the container” means map it into the container, and give Duplicati the inside-the-container path to wherever you placed it. Duplicati can then see it.

You map things into the container so they can be referenced by path inside the container.

I think we’re in huge agreement. That’s what I had said in your quoted text of

There is a whole chapter there with extensive examples which describe more.
If you have specific questions, please ask, but please see documentation too.

EDIT:

Documentation is for generic Duplicati. It does not get into Docker-only issues.

I used the search box at top right to type in

docker script on the host

Handshake between docker-duplicati and host popped up, and there are others.
Or maybe there’s some way for script to reach outside the container sufficiently.
Another question is whether there are programs you need to run from the script.
Trying to run host executables sounds a bit iffy to me, but I’m no Docker wizard.
Sometimes a web search or a specialty forum can turn up answers to questions.

Thanks for the confirmation that this can be mapped to a volume for Duplicati to see the script.

I added an edit with some more worries. Duplicati forum specializes more in just Duplicati.

Another question is whether there are programs you need to run from the script.
Trying to run host executables sounds a bit iffy to me, but I’m no Docker wizard.

There is a whole sub-set of Docker commands to get into an interactive shell and to copy files into and out of a container. I’ve seen other posts where people are asking about the same thing I am trying so I know this is not an unusual request.

I’ve still not mapped a volume for the scripts but I will try that soon as time allows.

You can do that, but it is a bit cumbersome to work with.

Instead, what you can do is place the script in a folder that you will use just for scripts.
Then use the regular folder mounting in Docker to mount the folder.
Once done, Duplicati (running inside the container) can see the script on the path you have mounted, and can run the script, even though it exists outside Docker.

Since the script is to be persisted, this is a better approach than copying in the script, and it is also easy to update the script from outside Docker.