-
Notifications
You must be signed in to change notification settings - Fork 79
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Backing up using webDAV from DAVx⁵ to nginx fails with HTTP 409, HTTP 405 #500
Comments
Thanks for the detailed report! One thing to try here is: Open the default "Files" app, and then try to copy some files to your DAV mount. You could even try to create a new folder |
No problem, it's the least I can do. Trying with the default files app, I copied a handful of files to the webDAV mount without issue. Trying to create
This seems like intentional behaviour by nginx based on the interpretation that lacking trailing slash does not need to be handled by the server: https://trac.nginx.org/nginx/ticket/1966 and seems like the same thing that I'm seeing with seedvault.
If I add a trailing slash, to create If I create Trying to create the directory a second time, like I saw in the initial test, fails with the error:
So it seems like
|
Regarding 1.: the DAVx⁵ documentation (DAVx⁵ (WebDAV) has been successfully tested with nginx) proposes a work-around in the form of an nginx configuration suggestion. With that, requests without trailing slashes are rewritten to have them. This does not solve the problem that seedvault or DAVx⁵ tries to create the .SeedVaultAndroidBackup directory even if it exists already, which causes the backup to fail. |
ok, so it seems that only |
Thanks, the workaround for DAVx⁵ using the nginx rewrite does resolve 1. Thanks for the hint on 2, based on it being expected to create the directory if it doesn't think it's present, 3 seems likely related. Checking seedvault source: seedvault/app/src/main/java/com/stevesoltys/seedvault/plugins/saf/DocumentsStorage.kt Line 248 in c856048
I don't see any nginx config to auto-index all files, but there are some source patches online. I could also just use another server. So seems like I guess the combination of 2&3 should make seedvault generally incompatible with stock nginx? I haven't tested this yet - I'll separate out my hacked web server from the one it's on now that's being used for other things so might take a bit, but I'm pretty confident of the cause. Thanks to all of you for the help, and thanks for the tool! |
You closed the issue, but if you or someone else is interested in investigating further: the cause seems to lie in nginx's PROPFIND implementation arut/nginx-dav-ext-module#41 I am not sure which project should do anything about the problem. If seedvault would be willing to tackle it, it could allow customizing the name of the backup root directory (so the dot at the beginning could be removed). |
I am able to backup over DAVx⁵ to nginx by applying this patch: mid1221213/nginx-dav-ext-module@51185d0 |
that's #143 |
Thanks, yes I saw the nginx-dav-ext-module patch possibility, but thought it would make ongoing updates more of a pain so opted to try reverse proxying through nginx to stock apache. I then hit the problem described in #503 with the repeated MKCOL's causing 405's from apache when the directory already exits.. So I went back and applied the patch to nginx-dav-ext-module and built it as an external module, so that I can still run stock nginx from repos and hopefully update without having to recompile, at least as long as the module ABI doesn't change(?) And yes agreed nginx with this patch does seem to work for me, the only thing that's worked so far. If seedvault is wanting to apply a workaround, checking for file location on hidden files does seem to work in my test with unpatched nginx with cadaver client, it's just not listed. So the strategy for checking if the directory exists could be modified, if wanted. It still seems like it's not really seedvault's issue, but man this webdav ecosystem is less compatible than I expected. |
I've spent time trying to set up nginx only to run into this same problem. Is there an alternative webdav server is there that's working with Seedvault? I really don't want to have to resort to doing crazy things like patching nginx just to support seedvault Edit: I managed to get the webdav backup working with Apache on Debian Bullseye. Had issues with Alpine linux missing a driver and doesn't seem to be available in Alpine's package manager. |
@StevenPolley you could give a try to lighttpd ) |
Seedvault now has native WebDAV support. Did anyone here try this yet with nginx? |
Trying the native WebDAV option, I get errors during initialization. Seedvault shows "An error occurred while accessing the backup location", and my WebDAV server shows constant errors of Seedvault continue to loop with error requests if the So just going to stick with my previous patched dav-ext-module module workaround with the DAVx^5 option. |
I guess this is nginx? Maybe let's wait until you get an update including #681 and try again. |
Using DAVx⁵ initially from f-droid version 4.2.6-ose - then changed to a locally compiled debug version off commit bee7cf20, with seedvault in LineageOS 19-20221220-microG-mata, when I chose DAVx⁵ as the backup location to setup a webDAV mount, I get DAVx⁵ logs:
and nginx logs:
and no files are created on the server.
If I hack a trailing slash onto the MKCOL in DAVx⁵, then I can add the backup location without error, but when I try to start a backup I get the logs:
and nginx logs:
which results in just an empty
.SeedVaultAndroidBackup/
created on the server.I think nginx might be being more strict about webDAV than some other servers. I'm not sure if the responsibility lies with seedvault to i.e. MKCOL with a trailing slash, or if that's DAVx⁵'s responsibility to translate a generic "mkdir" into the appropriate webDAV MKCOL with a trailing slash - if it's the latter I'd be happy to move this issue to them.
I realize none of this clearly points to seedvault, seedvault is just erroring once DAVx⁵ throws an exception.
Have you seen anything like this, or do know what could be causing it?
The text was updated successfully, but these errors were encountered: