I used dplsh to test it out and sure enough, passing / to getattr yields DPL_FAILURE
bucket_name: bucket_name:/> getattr / status: *DPL_FAILURE (-1)* bucket_name:/> getattr -r test.file last-modified= accept-ranges=bytes etag= date= server=AmazonS3 content-type= x-amz-request-id= content-length= x-amz-id-2= Which explains why even the nightly has the same issue, but does not explain why it worked before. On Friday, November 20, 2020 at 9:13:44 AM UTC+3 Dmitry Ponkin wrote: > I'm having the same issue with AWS S3 at the moment. No SSL errors though. > HEAD in logs, too. This is how droplet backend checks if the bucket exists > and if the connection could be established. > > https://github.com/bareos/bareos/blob/9c59c6460c7ddcdc361c6fb03fa01a2fd2aaa28e/core/src/stored/backends/droplet_device.cc#L352-L355 > According to the comments, libdroplet can return unexpected results in > some cases, but I don't understand how is that possible, considering that > my configuration worked flawlessly for several months but then just "broke". > > On Friday, November 20, 2020 at 12:20:38 AM UTC+3 [email protected] wrote: > >> I checked SSL access directly using the MinIO Client on the bareos-sd >> server. That works. >> >> I have to assume that I'm doing something wrong, and would appreciate >> extra eyes on the configuration. >> >> James Bellinger >> >> >> -- You received this message because you are subscribed to the Google Groups "bareos-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/bareos-users/1751c8e3-a4ff-4648-88cb-ebc560d286c1n%40googlegroups.com.
