Warning The supplied option ---------------- not supported

I have the same setup in two places and they are both connecting to a backend SFTP server on a non standard SSH port. It all works fine, it backs up, it restores, but I always get 2 warnings:

Warnings: [
    The supplied option ------------------------------------------------------------------------------- is not supported and will be ignored,
    The supplied option ------------------------------------------------------------------------------ is not supported and will be ignored
]
Errors: []

I only have 1 option under advanced options: ssh-fingerprint ssh-rsa 2048 (hex info)

The warning doesn’t say which option has a problem. Anyone have any ideas where to start looking?

I edited your post to improve the formating. (Just added ~~~ before and after the output you pasted, see here for details).

Try exporting the backup to either a file (JSON) or commandline, and see if it looks bonkers there. I am guess that there is a hidden advanced setting somewhere.

I exported to json and looked. There is nothing in there that shouldn’t be there. It’s all what the program added itself. I don’t see an option to suppress warnings either. That’s not a permanent solution but I would still get errors.

I even completely removed the entry and recreated it but it shows the same thing. Plus I have another computer that is doing the exact same thing. They are both connecting to the same back end SFTP server using different users though.

Hmm, I have only seen this reported on Chrome:

Could it be the same?

I don’t understand how the browser would affect the duplicati service running in the background. It shows the error in the system tray long before I open the localhost webpage in any browser. Maybe I’m not understanding your view here.

It’s not the browser affecting the service so much as how the browser gathers up the parameters from the various web form fields and passes them to the background service.

If it gets a parameter value mis-aligned with a paramer name, or even has an issue parsing quotes or escape characters, then the resulting command to the server may not be correct.

That being said, if you take instead of exproting to JSON you export “As Command-line” you can then open a shell and trying running the backup from the shell to see if you also get the errors when it’s run from something other than the GUI-server communication process.

The errors show up immediately even running it from command line.
This is what I get, this is only the first part:

Backup started at 10/9/2017 10:27:02 AM
The supplied option ------------------------------------------------------------
------------------- is not supported and will be ignored
The supplied option ------------------------------------------------------------
------------------ is not supported and will be ignored
Checking remote backup …
Listing remote folder …
Scanning local files …
24140 files need to be examined (45.23 GB) (still counting)
27568 files need to be examined (65.88 GB)
16552 files need to be examined (59.44 GB)
5185 files need to be examined (25.25 GB)
0 files need to be examined (0 bytes)
Uploading file (829 bytes) …
Uploading file (877 bytes) …
No remote filesets were deleted
Compacting because there are 1 fully deletable volume(s)

I run a .bat file required before backup. If I remove that option, it does not show the error in the command line. I use that bat file to robocopy /b files to a single folder then backup that folder. The VSS snapshot didn’t work. It kept getting errors. I tried installing the “Microsoft Visual C++ 2008 SP1 Redistributable Package” but it still didn’t work so I came up with running robocopy /b which does backup the files in backup mode. The administrator has backup privilege to backup files that the admin doesn’t have permission to open.

This was my attempt to work around the problem.

That’s a clever idea to get around the VSS issue! (I’m still fighting permissions issues around VSS on one of my machines.)

Would you mind posting the erroring commandline and called bach file (with private data hidden, of course)? It’s possible Duplicati is having a problem parsing the --run-script-before command.

It’s less likely but also possible the batch file is setting some environment variables that Duplicati is trying to interpret as commands. Most commandline arguments that Duplicati can accept, can also be provided as duplicati__XXXX=yyy (where xxxx is the parameter name with dashes replaced by underscores, and yyy is the parameter value). If your batch file is setting something like duplicati__not_a_real_parameter=oops then it might be seeing the “duplicati__” prefix them complaining that the rest of the parameter name is bad.

Command line with redaction:

"C:\Program Files\Duplicati 2\Duplicati.CommandLine.exe" backup "ssh://mysite:9000//offsite_backup.site/srvg-dc1/?auth-username=user&auth-password=password&ssh-fingerprint=ssh-rsa%202048%20CA%3A11%3AD9%3ACF%3A0F%3AEC%3A7B%3A3B%3A55%3AC4%3A3F%3AD6%3A80%3AE0%3AF0%3AD9" "C:\offsite_backup\\" --backup-name="Offsite Backup" --dbpath="C:\Users\Administrator\AppData\Roaming\Duplicati\KRRNAERTMR.sqlite" --encryption-module="aes" --compression-module="zip" --dblock-size="50mb" --keep-time="3M" --passphrase="mypassphrase" --run-script-before-required="c:\offsite_backup.bat" --disable-module="console-password-input"

Environment Vars from server:

C:\Users\Administrator>set
ALLUSERSPROFILE=C:\ProgramData
APPDATA=C:\Users\Administrator\AppData\Roaming
CLIENTNAME=JASON
CommonProgramFiles=C:\Program Files\Common Files
CommonProgramFiles(x86)=C:\Program Files (x86)\Common Files
CommonProgramW6432=C:\Program Files\Common Files
COMPUTERNAME=SRVG-DC1
ComSpec=C:\Windows\system32\cmd.exe
FP_NO_HOST_CHECK=NO
HOMEDRIVE=C:
HOMEPATH=\Users\Administrator
LOCALAPPDATA=C:\Users\Administrator\AppData\Local
LOGONSERVER=\\SRVG-DC1
NUMBER_OF_PROCESSORS=4
OS=Windows_NT
Path=C:\ProgramData\Oracle\Java\javapath;C:\Windows\system32;C:\Windows;C:\Windo
ws\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files (x
86)\Microsoft SQL Server\90\Tools\binn\;C:\cygwin\bin;C:\sec_521r2\tools;C:\MySQ
L0601\MySQL Utilities 1.4.3\;C:\MySQL0601\MySQL Utilities 1.4.3\Doctrine extensi
ons for PHP\;C:\Program Files (x86)\WinSCP\
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC
PROCESSOR_ARCHITECTURE=AMD64
PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 26 Stepping 5, GenuineIntel
PROCESSOR_LEVEL=6
PROCESSOR_REVISION=1a05
ProgramData=C:\ProgramData
ProgramFiles=C:\Program Files
ProgramFiles(x86)=C:\Program Files (x86)
ProgramW6432=C:\Program Files
PROMPT=$P$G
PSModulePath=C:\Windows\system32\WindowsPowerShell\v1.0\Modules\
PUBLIC=C:\Users\Public
SESSIONNAME=RDP-Tcp#0
SystemDrive=C:
SystemRoot=C:\Windows
TEMP=C:\Users\ADMINI~1\AppData\Local\Temp\4
TMP=C:\Users\ADMINI~1\AppData\Local\Temp\4
USERDNSDOMAIN=SOAD.LOCAL
USERDOMAIN=SOAD
USERNAME=administrator
USERPROFILE=C:\Users\Administrator
windir=C:\Windows

Batch file that is required to run:

robocopy /mir /B /r:1 c:\EnvBackup c:\offsite_backup\EnvBackup
robocopy /mir /B /r:1 c:\shares c:\offsite_backup\shares
robocopy /mir /B /r:1 c:\Quickbooks_Backup c:\offsite_backup\Quickbooks_Backup

Nope - not seeing anything bad in either of those - but thanks for posting them.

Perhaps there’s something in the robocopy output that Duplicati is picking up on. Can you try adding “>nul” (no quotes) to the end of each robocopy command? This will send any text output (like the files being progressed and progress percentages) to the “nul port”.

--run-script-before-required="c:\offsite_backup.bat"

to

--run-script-before-required="c:\offsite_backup.bat > null"

I put the > null in but it said “The system cannot find the file specified”. So it’s treating anything in the quotes as the file itself.

Sorry - we each goofed a little here.

  1. “null” in this use is a single “L” (so nul, not null)
  2. I meant in your batch file, like:
robocopy /mir /B /r:1 c:\EnvBackup c:\offsite_backup\EnvBackup >nul
robocopy /mir /B /r:1 c:\shares c:\offsite_backup\shares >nul
robocopy /mir /B /r:1 c:\Quickbooks_Backup c:\offsite_backup\Quickbooks_Backup >nul

Add > nul to each line of the contents of your batch file, like this:

robocopy /mir /B /r:1 c:\EnvBackup c:\offsite_backup\EnvBackup > nul
robocopy /mir /B /r:1 c:\shares c:\offsite_backup\shares > nul
robocopy /mir /B /r:1 c:\Quickbooks_Backup c:\offsite_backup\Quickbooks_Backup > nul

I guess @JonMikelV is on the right track with this, because output to stdout can be treated as input for the backup job.
The Robocopy command generates separator lines using dashes ( ----------).
Lines sent to stdout starting with a double dash (--) will be treated as an advanced option, so the separator lines that Robocopy is generating are sent to the backup job as an extra option (the complete line excluding the first 2 dashes).

Snippet from run-script-example.bat:

REM All Duplicati options can be changed by the script by writing options to
REM stdout (with echo or similar). Anything not starting with a double dash (--)
REM will be ignored:
REM echo "Hello! -- test, this line is ignored"
REM echo "--new-option=""This will be a setting"""

Thanks for finding something more than my guess as to the possible cause for this! :slight_smile:

Those separator commands come with the robocopy header and summary text, so instead of using a > nul redirect one could also use the standard robocopy /NJH and /NJS parameters to disable the Header and Summary output.

The > null does not work in the quotes. It sees the > null as the batch filename.

The robocopy no output worked!!!

Here is the new batch file:

robocopy /mir /B /r:1 /nfl /ndl /njh /njs /nc /ns /np c:\EnvBackup c:\offsite_backup\EnvBackup
robocopy /mir /B /r:1 /nfl /ndl /njh /njs /nc /ns /np c:\shares c:\offsite_backup\shares
robocopy /mir /B /r:1 /nfl /ndl /njh /njs /nc /ns /np c:\Quickbooks_Backup c:\offsite_backup\Quickbooks_Backup

Glad to hear it!

If any particular post helped you resolve this, clicking the checkmark icon will mark the topic as resolved so others who may bump into the same issue will know where to go. And if more than one got you going, feel free to :heart: them!

@kees-z, I know it’s not a full fix but perhaps checking for “–[a-z,0-9]*” might reduce false hits like this (sorry, I don’t recall the regex format for a-9).

You can add --verbose to Duplicati, which will make it report whatever input it got, which helps to figure out what shell escape errors you have.

Not sure it would have worked here, because Duplicati thinks anything starting with -- is an option, so the ------ will be “parsed” as an option.