Wasabi - client.PutObject: Access Denied

Does anyone have a working Wasabi connection?
Just curious.

I have given the “s3” user policy full access, and confirmed it functions.
But restic refuses to work with it.

I ended up using rclone for the repository, works instantly.
The lack of CIFS support and the lack of Wasabi support I presume are not of great interest overall for the project devs, but have to admit woulda been really nice if it worked properly OOTB.

Perhaps there’s a way I can debug it to find out more info?
But yea can consider this resolved at this time. good day to you

Did you follow the instructions at https://restic.readthedocs.io/en/stable/030_preparing_a_new_repo.html#wasabi ? A quick search also turn up several users of wasabi S3, so I guess it should work.

There’s not much point to implementing a CIFS client in restic as all major operating systems are able to mount CIFS filesystems.

To help you with debugging the problem, we need a lot more information than that: Which restic version did you use, which command exactly did you use, what is the output produced by restic?

Of course, followed the instructions precisely.
And I would agree on CIFS, using rsync works just fine, despite using up hard drive space locally to procure the repository (what I was hoping to avoid, the entire point of a remote mounted drive).
I’d use FTP if it weren’t such a slow protocol.

Environment info:

# uname -r
5.8.9-arch2-1
# restic version
restic 0.10.0 compiled with go1.15.2 on linux/amd64

The command executed (targeting east-1):

export AWS_ACCESS_KEY_ID=abc123
export AWS_SECRET_ACCESS_KEY=secret123
restic -r s3:https://s3.wasabisys.com/mybucket/ init

The result:

enter password for new repository: ****
enter password again: ****
<2 minute delay>
Fatal: create key in repository at s3:https://s3.wasabisys.com/mybucket/ failed: client.PutObject: Access Denied

It takes about 2 minutes before it responds, suggesting some kind of timeout is happening.
This is why I asked if anyone is using it actively, right now. And is it actually functioning for them? To help isolate environment vs program.

But really it’s ok I have a workaround & it’s working amazingly well.
So while i definitely honestly appreciate the support, and respect your efforts, I think we can save each other time by deleting this post.
Especially if I’m the only one using Wasabi or the only one having an issue.
I humbly assume the latter.

I read somewhere, wish I saved the link so I could reference it, it was mentioned that Restic is using an old library for S3, which is why I stumbled upon chaining it with RClone, which uses an updated(official?) s3 api library.
I would tend to presume S3 works fine, but something specific about Wasabi is not. Again, wondering if anyone else is actively using wasabi right now…

We’ve updated the minio library used for S3 (we’re not using the official AWS SAK) before the release of restic 0.10.0. I’ve noticed that the documentation does not use a trailing slash for the repository path s3:https://s3.wasabisys.com/mybucket, no sure whether that makes any difference.

There are several mentions of wasabi in the forum and the github bugtracker within the last year, so I’d assume it should work. Actually there’s even a Wasabi help desk page: https://wasabi-support.zendesk.com/hc/en-us/articles/115002240372-How-do-I-use-Restic-with-Wasabi- . But I can’t tell whether anyone has already successfully used restic 0.10.0 with wasabi.

If you want to dig a bit further you could create a debug build of restic go build -tags debug ./cmd/restic and then run DEBUG_LOG=debug.log restic -r s3:https://s3.wasabisys.com/mybucket/ init and look for the http requests and replies.

hmmm - I am backing up more than 20 machines with restic to wasabi for nearly two years now. Never had any problems. Also with the new 0.10.0 everything works fine.

Regarding the problem of the threadstarter, the only diference to my setup is that I have the region in the bucket url. Example:

export RESTIC_REPOSITORY="s3:https://s3.eu-central-1.wasabisys.com/bucketname"

So I am not sure if you can access your bucket just with s3.wasabisys…

Excellent thank you so much guys!
That confirms for sure that it must be my environment. I did try without the trailing slash too but no dice.

However I will note that this morning, it appears to no longer have the timeout (2min delay), and instantly responds (same as above). Which is an odd change. Perhaps it’s a DNS issue? Strange.

I’ll try out the debug build, and see if I can get some better details on this.