Fatal: unable to open config file: negative content length

Getting Help
1

hello all,
my first post here. I searched the forum but could not find a match to my situation.
Looking for some help to verify if this is user error or a bug.

workstation_pc : W10 with restic 0.12.1
repo_pc: W10 with fixed ip and rest-server 0.10.0 and restic 0.12.1

I have been successfully using the restic + rest-server combo to backup over VPN. Including data integrity check, restoring snapshots and files.

But since about 1 week i can not do anything anymore. I always get the “negative content length” error when i try anything via the rest: protocol. It does not even ask the password. Example at workstation_pc :

PS C:\Users\MyUserId> C:\LocalData\tools\Restic\restic.exe -r 'rest:http://1.2.3.4:8080/MyUserId' snapshots
Fatal: unable to open config file: negative content length
Is there a repository at the following location?
rest:http://1.2.3.4:8080/MyUserId/

on repo_pc the rest-server does not output anything after giving above command. Normally it would print that it saves blobs and such things.

rest-server is started like this on repo_pc 1.2.3.4:
C:\_RESTIC>c:\LocalData\tools\RestServer\rest-server.exe --no-auth --append-only --listen ":8080" --max-size 300000000000 --path "/_RESTIC/RSR" --debug

When i approach the repository locally at repo_pc i can do anything without problem:

PS C:\_RESTIC\RSR> C:\LocalData\tools\Restic\restic.exe -r 'C:\_RESTIC\RSR\MyUserId' snapshots
enter password for repository:
repository 225889fa opened successfully, password is correct
 <SNIP LONG LIST>
PS C:\_RESTIC\RSR>

The config file exists and because i can still perform local actions with restic on repo_pc i believe it should be fine? restic check reveals no issues.

PS C:\_RESTIC\RSR> dir C:\_RESTIC\RSR\MyUserId\config

    Directory: C:\_RESTIC\RSR\MyUserId

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a----        12/21/2021   8:01 PM            155 config

Meanwhile i also upgraded to the freshly released rest-server 0.11.0 but that gives the same result.

Does anybody have an idea how to investigate this matter?
Would love to get restic going again via the rest protocol.

2

Welcome to the forum. Do you know whether anything has around the time the error started to appear?

There are a few things you could try:

  • What does the rest-server log if you add --log logfile.txt to the command line?
  • What happens if you open http://1.2.3.4:8080/MyUserId/config in your webbrowser? If you open the network tab in the webbrowser’s developer tools then you can also take a look at the exact response returned by the server. What Content-Length does the reply include?
  • Are you able to use the rest protocol to access the repository when running restic at the repo_pc?
  • Does the rest-server have enough permissions to read the files in the repository?
3

Thank you @MichaelEischer for your response, it helped me to solve the issue!

By trying the link in the browser I found out that port 8080 was in use by another aplication. They rolled out an SNMP application at port 8080 on repo_pc and did not inform me.
Now we run restic at port 8888 and everything works as it should.

Interestingly rest-server does not complain at start up that the port is already taken.

To get back to some of your specific suggestions:

  • adding --log logfile.txt does not log anything to that file, after giving some commands like restic check, snapshots, list. Many messages scroll in the terminal like GET, DELETE, SAVE as before with the debug flag.
    So then I restart rest-server without --debug and a lot of information is put in the logfile. It seems --log and --debug are mutually exclusive.
4

I cannot reproduce any of the problems you’ve mentioned using the latest rest-server.

.\rest-server.exe --no-auth --debug --log abc.txt --path test provides debug output for me and also writes to the log file. It may be the case that it takes some time or a certain amount of requests until log messages become visible in the logfile.

Trying to start rest-server twice for the same port returns error: unable to listen: listen on :8000 failed: listen tcp :8000: bind: Only one usage of each socket address (protocol/network address/port) is normally permitted. So maybe the SNMP application blocked the port in a non-standard way?

5

Aha, the logfile takes indeed a while to start writing. It stayed long at 0 bytes with some basic commands. After i started a full restic check --read-data for ~300GB/50000 pack files repository, it started to write to the file in bursts every few minutes, adding thousands of lines at a time. When i killed the rest-server it flushed out the last few hundred lines.

Good idea to try start rest-server twice, i also tried that and then i get the same error from rest-server. So i agree the SNMP application is not playing nice.

Thanks again and i think we can leave it here. The items that I observed are no bugs or problem but user error and a burst-write nature of the --log flag that did not match my expectation.

p.s. It was fun to play around with restic and rest-server for this case and it proves again for me that in the basis it is a very robust tool.