400 Bad Request when uploading to WebDAV Server about docker-volume-backup HOT 13 CLOSED

This is now included in v2.16.0

from docker-volume-backup.

WEBDAV_URL_INSECURE=true (without quotes) ... WORKS!!!!!! Wuhuuu :) Thank you so much! I'm looking forward for the next official release.

from docker-volume-backup.

I don't know much about WebDAV myself other than it seems to work against the bytemark/webdav:2.4 server that is used in the test setup, so it's likely that you are correct about your assumption that this is an upstream issue in the gowebdav client.

There seems to be one issue in that repo that might be relevant studio-b12/gowebdav#42 and where the fix is not in docker-volume-backup yet. Do you think this could be causing your issue? Could you try backing up a single foo.txt file and see if you still encounter that 400 error?

from docker-volume-backup.

Hi m90, I got one step forward. In my password I used a special character (a dash "-"). When removing this one I am able to do backups to the HTTP backend. But as far as I switch to HTTPS (same server) it gives me an 400 again with no traces in any logs... So I think that is no issue with whitespaces as you suggested.

from docker-volume-backup.

Thanks for the additional info. This sounds a bit as if gowebdav fails to properly URL encode the password in your HTTP case. What exactly is happening in the HTTPS case I'm not sure but since all that docker-volume-backup is doing is passing down URL, password and username here:

the problems must happen further down in the client library.

Do you maybe want to open an issue in the upstream repository about this? The version in use here is https://github.com/studio-b12/gowebdav/tree/3f8721cd4b6fd825469e6ac2393a8ac042427efd

from docker-volume-backup.

I now checked if I am able to upload to another server (magentacloud). This fails either. And I removed all whitespaces.

~ # backup time="2022-04-20T08:01:55Z" level=info msg="Stopping 2 container(s) labeleddocker-volume-backup.stop-during-backup=trueout of 4 running container(s)." time="2022-04-20T08:03:03Z" level=info msg="Created backup of/backupat/tmp/"nextcloud-2022-04-20T08-01-55.tar.gz"." time="2022-04-20T08:03:05Z" level=info msg="Restarted 2 container(s) and the matching service(s)." time="2022-04-20T08:03:06Z" level=error msg="Fatal error running backup: copyBackup: error creating directory 'smalltest' on WebDAV server: MkdirAll /smalltest/: 400" time="2022-04-20T08:03:06Z" level=info msg="Removed tar file /tmp/"nextcloud-2022-04-20T08-01-55.tar.gz"."

from docker-volume-backup.

In any case this is an issue upstream that cannot really be fixed in here unfortunately. I might want to update the dependency in any case, but it doesn't sound as if this would solve your issue.

from docker-volume-backup.

I just released v2.15.3 which contains the update for package webdav. I doubt this fixes your problems, but if I understand studio-b12/gowebdav#54 correctly it should at least give you slightly more informative errors about what's going on.

from docker-volume-backup.

Thats pretty cool! Thank you. Now there are more details available. In the case of my Synology it is the self signed certificate that causes trouble: x509: certificate signed by unknown authority
As far as I see there is no option in gowebdav to allow unsecure connections so docker volume backup cannot either. Would you agree on that? So I think I need to create my own authority and allow this one explicitly for ... the docker host or the docker container? I will investigate this.

Maybe you can update your docs concerning self signed certs then.

from docker-volume-backup.

It seems the webdav client library would let you define a custom transport, so we could model such an option after AWS_ENDPOINT_INSECURE (which does the exact same thing in the end) and introduce WEBDAV_INSECURE (defaulting to false) which then does something like this when instantiating the client:

client.SetTransport(&http.Transport{
    TLSClientConfig: &tls.Config{InsecureSkipVerify: config.WEBDAV_INSECURE},
})

For reference, this is where it's happening for all S3 storages:

from docker-volume-backup.

@stevenengland I implemented a WEBDAV_URL_INSECURE setting over at this branch: https://github.com/offen/docker-volume-backup/tree/insecure-webdav-transport

In case it's possible for you, it would be much appreciated if you could try building an image off that branch and see if it works for your use case:

git clone [email protected]:offen/docker-volume-backup.git
cd docker-volume-backup
git checkout insecure-webdav-transport
docker build . -t offen/docker-volume-backup:insecure-webdav-transport

Then try running a backup using the offen/docker-volume-backup:insecure-webdav-transport image while setting WEBDAV_URL_INSECURE="true" and see if you can use your self signed cert like this?

from docker-volume-backup.

Hi @m90 awesome! I will give it a try. Because I am relatively new to docker I maybe need some time to implement a working test environment :)

from docker-volume-backup.

If possible, the easiest way to test this would be to clone the repo and build the image on the host where you are running your containers. This way, the insecure-webdav-transport tag would be available immediately after building without having to transfer it anywhere.

from docker-volume-backup.