WebDAV: Uploading to Nextcloud may result in 0 byte files #443
Comments
I can confirm same behavior in my environment. Steps I performed:
Environment: PP logs: NC logs: |
|
@lastzero I guess this has to be considered a part of the MVP milestone? |
|
Yes, going to look into that soon! |
|
Couldn't find any issues when uploading to Nextcloud 19.0.1:
Also doesn't matter how many files I select, they are properly uploaded. Note that we don't use https for our local test environment, this can make a difference (connection should fail completely though). Logs: To debug this further, we need additional information. Maybe it's just a file permission problem, either in Nextcloud or PhotoPrism? |
|
Maybe this only affects certain file types or there is a request size limit in Nextcloud or a proxy in front of it? |
Test with a third-party WebDAV client worksJust to make sure this isn't caused by the Nextcloud I've used a third-party WebDAV client (Cyberduck) and tested the upload.
ProxyThe Nextcloud is hosted by the Apache, the this is serving the content directly without a additional proxy in front of it. Directory listing works, upload itself not.I don't think this has something to do with HTTPs. The listing of the upload directories works. You can see the folders that exists on the Nextcloud and select the correct one. I've also tried using the root directory and not a sub-folder. Same result. File upload call gets rejected with 401, unauthorized.In the last test I discovered someshow that the final call that should upload the file gets rejected with HTTP status 401, others work fine tho... ... so the WebDAV implementation used in PP is not checking for the status of the file upload? Test with different file typesTo rule out an error with the size or type I uploaded the same file that I've used in the upload with cyberduck, uploaded it to PP and tried to share it from there. Same result. 0KB Used Nextcloud version: 18.0.7 |
|
Our WebDAV upload is based on https://github.com/studio-b12/gowebdav They also have a stand-alone command you can use for testing: https://github.com/studio-b12/gowebdav/tree/master/cmd/gowebdav |
|
Looks like there is a Edit: Think I can also see it in my logs, so not sure if this is something that needs a fix. |
|
Yep, that's an issue in the gowebdav client.
I will test a little bit more and raise an issue over there. I wonder why it is working without issues for your tho... |
|
Opened an initial issue studio-b12/gowebdav#35 |
|
@lastzero and I have the bad feeling that this might be our issue... studio-b12/gowebdav#28 |
|
Error reporting might be an issue, but what causes the error in the first place? Maybe just a small change needed as it works over here. Are there custom settings for Nextcloud that can lead to auth issues? Plugins? We use URL auto detection when adding the account ( |
|
Hmm tried it with the short (autogen) and full path. Same result. Is your storage encrypted? Also I've upgrade my instance to 19.0.1, same issue persists. |
|
No, we don't modify originals. So no encryption whatsoever. Maybe a HTTP / Webserver issue after all, or there's a problem with the base64 encoded password in the header (there are slightly different standards for this, do you use any special characters other than a-z and 0-9?). |
|
It's actually an app password generated by Nextcloud itself. Looks something like this With the encryption I was referring to your test nextcloud instance Is the build-in nextcloud encryption enbaled for this? |
|
Probably not... If this is not the default. Maybe there's an issue with encryption and app passwords? |
|
Hmm ok because in the nextcloud issue there is some relation to encryption.. @uLUViL3gCs do you have encryption enabled in your instance? |
|
@lastzero could you try this with your build against https://try.nextcloud.com/ ? (User gets created automatically) I will dig around in the gowebdav later and see if i can figure out what is causing this. A quick look revealed that the status returned from the NC instance does not include any error so far, but I will dive deeper into it later. |
No, I am not using encryption as coming along, build-in by NC.
Same here.
Just to let you know that even on storage the uploaded file size is 0kB in my case.
Using nextcloud demo and the same local PP, I am encountering same issue (files visible, file size == 0kB). Just for your information that I am using nginx for the local PP instance. |
|
I'm also using nginx as revrese proxy. But it should not have any impact since the connection to Nextcloud is direct without a proxy (PP connects directly to the NC instance via HTTPS) |
|
Did anyone try without app password? Do app passwords also have a username or is it just the password without username? Nginx will limit upload size by default, we had many "bug" reports related to this when the real issue was that the files were larger than what nginx was configured for. |
|
That reminds me that we run Nextcloud behind a Caddy proxy, so this might fix / modify the request in a certain way... |
|
Could it be a locking issue? See https://help.nextcloud.com/t/file-is-locked-how-to-unlock/1883 |
|
app password use the same username as the normal login. |
Yes, just now on my local NC => Same result, file gets uploaded, 0kB size.
Yes, same user name is required. |
|
Did move my instance to nginx. Same issue. Nginx logs: PP logs: |
|
Also tried it with the nginx option |
|
Did you follow the advice on https://trac.cyberduck.io/wiki/help/en/howto/mount/issues/fastcgi and https://sabre.io/dav/0bytes/? Seems like |
lastzero
changed the title
|
Finally - This did the trick! You've to enable Keep in mind that the default nextcloud documentations states that you turn this off. So the majority of people will most likley have the same issue. |
|
Excellent, so the only thing we need to do is add specific docs for Nextcloud users? Edit: Maybe you should only enable it for WebDAV routes, not for regular Nextcloud pages. Might have a performance impact. |
|
Yes. I guess this will be enough. For me it's fine since I wanted to switch to Nginx anyways... :) Setting the option only for the webdav routes is a good idea. Will change that in my configuration. |
Just to let you know that the same is true for my instance; changing |
lastzero
added
docs 📚
|
Adding my grain of salt. I can indeed upload via CURL using Strange enough, I found a way to make my uploads work: Using this path works: The latter still creates 0 byte size files in the GUI, but this time, the file is actually transfered, and exists with a real size in the data directory. Now the fun part is: If I happen to switch back to Hope this helps someone until this gets sorted out. |
|
Some more bug reports: https://bz.apache.org/bugzilla/show_bug.cgi?id=57087 |
|
@kesselb Does indeed explain the php-fpm problem that gets resolved by using mod_php ;) What's the difference between dav and webdav URIs ? |
|
@deajan wrong repository as your problem/question is not related to photoprism ;) |
|
@kesselb Ahem... yes ;) Sorry for the noise |
|
FYI, here's the explanation and possible solutions https://trac.cyberduck.io/wiki/help/en/howto/mount/issues/fastcgi |
|
As this is mentioned in our docs (https://docs.photoprism.org/user-guide/settings/sync/). Can we close this issue or is there something left todo? @lastzero |
and others
Preamble
Im not sure if this is something broken with my nextcloud instance or actually a bug.
So i would appreciate if someone (who has access to a Nextcloud instance) could test this.
Problem desciption
If you setup the upload via WebDAV to nextcloud and share one or multiple pictures, the file in nextcloud is emtpy. It basically only created the file with no contents. Therefore you can't load/display the picture.
Also if you download the file it has zero bytes in it.
Logs
Log output from PhotoPrism:
Log output from Nextcloud:
The text was updated successfully, but these errors were encountered: