Error 401 on rest-server
romanoLT opened this issue · 5 comments
I have an issue with my rest-server. It used to work but I can't identify the changes that broke everything.
Configuration: rest-server on a local homelab and on remote there is the server I would like to backup using restic pre-build binary (restic 0.12.1 compiled with go1.16.6 on linux/amd64).
I regenerate a certificate in case of in was an issue with it but I have the same issue with a new self signed certificate.
Output of rest-server --versionDocker build rest-server version rest-server 0.10.0-dev compiled with go1.17.2 on linux/amd64
How did you run rest-server exactly?
on the remote server :
sudo restic --cacert restic_public_key -r rest:https://user:pass@url:8888/backups --verbose backup --files-from ./includes.txt
on the local server:
sudo docker run -d -p 8888:8000 -v /raid/share/data/:/data --name rest_server rest-server:local --listen ":8000" --path /data --debug --private-repos --tls --tls-cert /data/restic_public_key --tls-key /data/restic_private_key
the log from the rest-server on local:
HEAD /backups/config
What backend/server/service did you use to store the repository?
ZFS
Expected behavior
upload the changes
Actual behavior
sudo restic --cacert restic_public_key -r rest:https://user:pass@url:8888/backups --verbose backup --files-from ./includes.txt
open repository
Fatal: unable to open config file: unexpected HTTP response (401): 401 Unauthorized
Is there a repository at the following location?
rest:https://user:pass@url:8888/backups/
Do you have any idea what may have caused this?
no
Do you have an idea how to solve the issue?
no
You haven't said anything about creating a .htpasswd file, which is where you define the username and password for the users accessing the rest-server. Since you have specified user:pass in your repository URL, I presume you have a .htpasswd in place that rest-server uses, is that correct?
You are using the --private-repos option to rest-server which means that you should be using a repository URL that has a username in it, search for private-repos in https://github.com/restic/rest-server/blob/master/README.md . Is your username backups such that it matches the backup at the end of your repository URL? If not, this is probably what you need to correct. If you want the backups stored in a backups/ folder on the server, adjust that using --path /data/backups in the rest-server command.
Yes sorry for omitting the .htpasswd part. So there is a .htpasswd file. I also tried to use different passwords to check whether there were parsed correctly or not. It doesn't seem to be an issue with this file because when using a wrong password I got:
Invalid htpasswd entry for user.
Here is the content of my local server (rest-server):
root@local:~# ls /raid/share/data/
backups public_key_restic2 restic_new.csr restic_new.key.org restic_public_key
private_key_restic2 restic_new.crt restic_new.key restic_private_key
root@local:~# ls /raid/share/data/backups/
config data index keys locks snapshots
My understanding is that /data/ is already implicit if I add --path /data/backups instead of --path /data rest-server is unable to start and locate the .htpasswd. the backups/ at the end of url was actually init-ed some time ago and use to work for the user.
Is your username backups such that it matches the backup at the end of your repository URL?
^ You never answered this question. What is the user's username? Do you have more than that one user?
If you want to use private repos, the repository URL can be rest:https://USERNAME:pass@url:8888/USERNAME - the username and the first part of the path must match.
OK thanks @rawtaz, it actually worked. But what is strange is that I never used something like rest:https://USERNAME:pass@url:8888/USERNAME instead it was rest:https://USERNAME:pass@url:8888/backups and I was able to backup (I checked and there were 10 snapshots). I checked my .bash_history and for 100% I never used USERNAME.
So I renamed the backups folder to USERNAME and then it worked.
Does restic changed something ?
My first guess would be that you previously ran rest-server without the --private-repos option enabled. When you do that, you don't need the first path element in the URL to match the username.