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
Nextcloud: Adding local server yields error 400 #496
Comments
Did you try connecting without providing the exact path, just Also note that Nextcloud WebDAV support might be broken under certain conditions, see WebDAV: Uploading to Nextcloud may result in 0 byte files #443. |
I have tried that address too, and still receiving the error. |
Are you sure the Nextcloud server can be properly reached from within the
Docker container using the host name? Name resolution can be different in
some cases.
Do you see anything in the logs of your Nextcloud server so that you know
the connection works on the network level? Any helpful error messages?
|
I am a little unsure on what you mean here.
Nothing in my Nextcloud logs are indication connection errors. Attaching to the Docker container does not log any GET or POST HTTP requests coming from Photoprism. Although, I am able to see requests from Firefox and also Nextcloud itself. |
It seems the PhotoPrism container cannot reach the Nextcloud instance for some reason, maybe because the host name |
My system hosts file contained a record for Nextcloud Hosts:
Photoprism Hosts:
Looking over the Docker Network setup I have a couple of interfaces setup.
Inspecting the Network interfaces of both Nextcloud and Photoprism, they are sharing the same Network Interface...
|
Without spending much time going through your complete networking setup, it seems obvious that PhotoPrism gets HTTP error 400 (invalid request) when trying to connect to 127.0.1.1 (localhost) via WebDAV as it will connect to itself. Docker Compose typically takes care of networking so that you don't need to enter any IP addresses into Here, for example, the |
Any progress / feedback on this? Was my suspicion going in the right direction? |
I haven't had any luck so far with the WebDAV access issue, but have not touched it for the last week. |
I have the same issue, adding either the full path or the docker internal hostname, I both receive the same 400 error:
With the following Service URLs: |
Can the domains nextcloud-app and nextcloud.domain.tld be resolved from inside the container? Do they maybe point to localhost or 127.0.0.1? |
They resolve properly in the container, I used |
Anything else I can try? I would love to use Photoprism, but whatever I try I can't link up Nextcloud. |
I'd love to debug this further with you, but need to take care of existing bug reports first. Did you take a look at #443? It seems Nextcloud's behaviour depends a lot on the Web server (nginx, apache,...) and its specific configuration. |
Is this still an issue? |
Yes it's still an issue. I'm now running PhotoPrism 201207-a43f8be2-Linux-x86_64 via docker-compose. I've looked at #443, I also use the nextcloud-apache container (no php-fpm/fast-cgi), but since I can't add the WebDAV server I haven't run into the same 0-byte file issue as discribed there. |
I'm happy to help once the release is out of the door. |
I have this issue as well. I have them on the same host machine, and I even moved photoprism to it's own IP address and still having issues. It connects successfully when I test it with try.nextcloud.com. I've used hostnames (LAN and docker hostnames) and I've used the ip address. I made sure they that all of these were valid in the nextcloud config. |
Same here. I added WebDAV-Server to photoprisms docker-compose, they share a network, but no connection possible, neither with |
I found somewhat of a workaround: If you first add a remote nextcloud server, you can change the server adress afterwards to local and it works!! |
Interesting, maybe there is an issue with how we parse the host name!? |
praul thank you. The workaround worked for me. That gave me, more detail errors that photoprism had issues with the self sign certificates for nextcloud. Once I turned off enforcing https (only access to either is local lan) on nextcloud sync is starting. |
Oh, you've been using invalid HTTPS certificates? Blocking them is a feature, not a bug - but we should show a helpful error message in this case! |
I think that was part of the issue, just was used to having a pop up saying to ignore it, or can't connect because of it. I've successfully have been able to remove, add, and modify accounts to my local owncloud server. I completely agree with blocking invalid HTTPS certificates, but I agree at least having a log or notification about the invalid certificate would be helpful. I completely forgot about the certificates and it rerouting http to https connections till I got the error with the workaround. |
The certificate I use is valid, and I am not able to get a connection using http either |
I am not using any encryption or certificate, just plain http. It works with the workaround, but not in the initial setup
Also: While the workaround works, photoprism is not saving any configured folders, and always backups to root
|
I am also having this issue too, trying to connect to Nextcloud over HTTPS. My local Nextcloud WebDAV address is: http://192.168.1.1:450/remote.php/dav/files/xxxx/ where 192.168.1.1 is my server's IP on the network. In my case I could not connect to my remote Nextcloud server with Web DAV address: https://nextcloud.mysite.com/remote.php/dav/files/xxxx/ In my Photoprism logs i see: 2020-12-28 00:55:03 WARN sync: Error 1045: Access denied for user 'photoprism'@'photoprism_photoprism_1.nextcloud_default' (using password: YES) where I think 'photoprism' is my username for an account I have crated on Nextcloud for sync purposes. If I run getent hosts nextcloud from within my container it returns 172.18.0.2 nextcloud which is correct. Any ideas what to try? |
Started a preview build, you may test when it's done: https://drone.photoprism.app/photoprism/photoprism/915 |
please, could you give us more details on how the procedure works and in which menus... |
Sorry for the necrobump. I am encountering the same error as this now when connecting to Nextcloud. My setup is using I'd be happy to share my setup as I'm confident that this is related to Photoprism. |
Is there any kind of proxy, like nginx or k3s magic, in between or can PhotorPrism directly access the Apache server Nextcloud is running on? |
Networking on k3s/k8s is pretty much magic as there is a lot existing plumbing to make things work. I've tried to use both the direct connection using the inter-pod networking, via I also tried the Nginx based NextCloud and the logs contain I'm still using self-signed certs, the davs connection asks me if I want to continue. Could this be causing PhotoPrism to reject the connection? |
Yes, you need valid certs when using https, but looks like you're using http? We've learned that nginx doesn't support http features needed for webdav fully, so there might be similar issues. |
I was using the Apache version first and encountered the same challenge. This leads me to believe this isn't on the Nextcloud side |
Did you enter the full webdav resource path or just the host as shown above? |
Thanks @lastzero! It was a problem with an old version of Nextcloud. I upgraded to v20 and everything is working again. I love the software, keep up the great work and thanks for taking time to help. |
Holy complexity batman. Spent 3 hours trying to get Nextcloud working with Photoprism (so I can share albums without exposing my entire collection). The only error to go on has been I'm guessing its because my nextcloud certificate isn't valid? Without a lot of effort AFAIK it's not easy to get a valid certificate for a .home domain... (you have to become your own CA and then self sign root certificates etc. etc.)? It also seems to be a huge pain in the ass to disable HTTPS on Nextcloud (honestly I'm new to nextcloud but the entire thing looks like a php hot mess). Please can we have a button "My webdav is running locally so I really don't need to care about invalid ceritifactes"? I understand the intention is to keep things secure, but this is actually going to have the opposite effect - you're going to force people to expose their nextcloud directly to the internet so they can actually generate a proper certificate, and then make us route Photoprism webdav connections via public URLs! |
I have confirmed, by putting nextcloud out on the world wide web for everyone to attempt to hack into that I can now successfully connect Photoprism to it...:cold_sweat: |
Get a let's encrypt DNS wildcard cert. |
Or use HTTP on the internal network 👍 |
As mentioned you cannot easily get certs for local domains (e.g. .home/.local) and as mentioned, Nextcloud (at least the latest version) does not allow http traffic, it automatically forwards to https. |
Right, you'd need to pay for a regular domain. Can be managed for free at DigitalOcean. |
So back to my original point of good intentions of trying to make things secure, but the unintended consequence is making it so you have to expose nextcloud directly to the internet and then route Photoprism webdav connections via public URL :) As it transpires, it looks like Photoprism strips EXIF data when sharing stuff over Webdav so I need to abandon this anyway. |
No, you can use an internal network together with HTTP (not less secure) or pay for a domain to use HTTPS incl proper validation :) |
There's a dropdown to select the resolution. EXIF only gets removed for thumbs, not originals. It would be too complex to continuously sync Exif data across all thumbs and sizes. Also you might not want to share it when using a small thumb. |
@lastzero I'm not sure you can run NextCloud in HTTP (not easily anyway :( ) Sorry I opened another ticket for the EXIF issue, as its HEIC related. I don't see any resolution selector anywhere when sharing though? |
We're running Nextcloud via HTTP using their official Docker container for testing. Why shouldn't this work? |
Hmm I'm using the |
Just another confirmation from me that http://nextcloud (when photoprism and nextcloud are on the same docker network) does not work at first, but DOES work if I use my external network address (https://nextcloud.mydomain.com) and then change it to http://nextcloud. |
Actually I think I take it back. I was still seeing all the Nextcloud folders in the dropdown so I thought it was working. They must be cached though because uploading still doesn't work. |
I believe I have figured this one out. The problem is on the Nextcloud side. In
to something like this:
Hope this helps some people. |
Nextcloud isn't easy to configure... Many settings to experiment with. |
I am having a NextCloud Snap Installation running on a physical home server. I just installed Photoprism on another sperate physical system as VM with official the Docker Image. I am having this similar issue with WebDav connection to my NextCloud machine when trying to connect via internal LAN IP. One thing I noticed, I need to turn off SSL (HTTPS) on NextCloud Server and then only PhotoPrism can connect to that said nextcloud server via internal LAN IP. If I keep SSL active on NextCloud, the local IP webdav connection fails but if I use TLD (against which the SSL certificate is obtained) and connect via Internet then, photoprism can connect with this same NextCloud Server without any issue with SSL/https. Not sure, if I can call this a NextCloud issue but keeping the SSL off isn't a workable solution for me !! If anyone has any further info, kindly point me towards a solution. Thanks. |
I am looking to test the PhotoPrism Backup functionality with my local Nextcloud server. Both services are running in Docker containers, and both are exposed and accessible. I am utilizing HTTP rather than the HTTPS, as the endpoints are both contained within my local network.
When adding the Nextcloud server to PhotoPrism, I am informed that a connection could not be established.
Looking over the Logs, I am presented with the following information. I attempted a connection twice
Using Cyberduck, I am able to connect to both PhotoPrism and Nextcloud using WebDAV, confirming that both instances are accessible.
The text was updated successfully, but these errors were encountered: