starred/photoprism

Fork 0

mirror of https://github.com/photoprism/photoprism.git synced 2026-03-02 22:57:18 -05:00

WebDAV: Service can't be configured to connect on a non-standard port #1835

New issue

Open

opened 2026-02-20 01:00:57 -05:00 by deekerman · 5 comments

deekerman commented

2026-02-20 01:00:57 -05:00

Owner

Originally created by @eculicny on GitHub (Jul 27, 2023).

Originally assigned to: @lastzero on GitHub.

It seems that photoprism doesn't support the case when a port is specified when setting up a WebDAV service connection.

Environment: Docker
Photoprism version: 230719-73fa7bbe8-Linux-AMD64-Plus
Docker host is physically separate from a TrusNAS WebDAV host

The recommended curl command works as expected from inside the docker container and prints the XML for the directory and the items within it.
curl -X PROPFIND -H "Depth: 1" -u <user>:<pwd> http://<ip>:<port>/photosimport/

When setting up this connection in the UI, the network request to the Photoprism API is returning 400 Could not connect, please try again

If I remove the port in the setup form, http://<ip>/photosimport/, the service is added successfully, although it obviously doesn't actually work since that is the wrong port.

Original discussion

(edit: fixed link markdown)

Originally created by @eculicny on GitHub (Jul 27, 2023). Originally assigned to: @lastzero on GitHub. It seems that photoprism doesn't support the case when a port is specified when setting up a WebDAV service connection. Environment: Docker Photoprism version: `230719-73fa7bbe8-Linux-AMD64-Plus` Docker host is physically separate from a TrusNAS WebDAV host The recommended curl command works as expected from inside the docker container and prints the XML for the directory and the items within it. ```curl -X PROPFIND -H "Depth: 1" -u <user>:<pwd> http://<ip>:<port>/photosimport/``` When setting up this connection in the UI, the network request to the Photoprism API is returning 400 `Could not connect, please try again` If I remove the port in the setup form, `http://<ip>/photosimport/`, the service is added successfully, although it obviously doesn't actually work since that is the wrong port. Original [discussion](https://github.com/photoprism/photoprism/discussions/2617#discussioncomment-6560873) (edit: fixed link markdown)

deekerman added the

help wanted

needs-analysis

labels

2026-02-20 01:00:57 -05:00

deekerman commented

2026-02-20 01:00:57 -05:00

Author

Owner

@eculicny commented on GitHub (Jul 27, 2023):

One additional piece I noticed while testing, the IP address used does need to be accessible in some way, which I assume is verifying that a response is returned from the default 80/443 port. In my case, there is a web server running on the server that responds to requests on port 80, which is why I assume it was able to be saved.

http://192.168.0.100:8080/photosimport/ - returns the "Could not connect" popup message
http://192.168.0.100/photosimport/ - saves the connection successfully
http://192.168.0.123/photosimport/ - returns the "Could not connect" popup message, there isn't any host with that local IP address

@eculicny commented on GitHub (Jul 27, 2023): One additional piece I noticed while testing, the IP address used does need to be accessible in some way, which I assume is verifying that a response is returned from the default 80/443 port. In my case, there is a web server running on the server that responds to requests on port 80, which is why I assume it was able to be saved. - `http://192.168.0.100:8080/photosimport/` - returns the "Could not connect" popup message - `http://192.168.0.100/photosimport/` - saves the connection successfully - `http://192.168.0.123/photosimport/` - returns the "Could not connect" popup message, there isn't any host with that local IP address

deekerman commented

2026-02-20 01:00:57 -05:00

Author

Owner

@lastzero commented on GitHub (Aug 15, 2023):

@eculicny I could not reproduce this, unfortunately. Using port 8080 worked perfectly after I configured the firewall to allow connections from the local network via port 8080.

At first, I could not connect to my host over the internal Docker network, also not with curl from inside our dev Docker container:

curl -I -X PROPFIND -H "Depth: 1" -u admin:insecure http://192.168.1.4:8080/Photos/
curl: (28) Failed to connect to 192.168.1.4 port 8080 after 130482 ms: Couldn't connect to server

However, once the firewall was properly configured, it worked with both curl and PhotoPrism:

curl -I -X PROPFIND -H "Depth: 1" -u admin:insecure http://192.168.1.6:8080/Photos/
HTTP/1.1 207 Multi-Status
Content-Type: text/xml; charset=utf-8
Www-Authenticate: Basic realm="Restricted"
Date: Tue, 15 Aug 2023 10:12:15 GMT
Transfer-Encoding: chunked

Uploading files worked as well after the service was added:

DEBU[2023-08-15T10:09:33Z] webdav: connecting to http://admin:insecure@192.168.1.6:8080/Photos/ 
DEBU[2023-08-15T10:10:34Z] server: POST /api/v1/services/2/upload (200) [18.901762ms] 
DEBU[2023-08-15T10:10:34Z] webdav: connecting to http://admin:insecure@192.168.1.6:8080/Photos/ 
INFO[2023-08-15T10:10:34Z] share: uploaded /20120427-171750-Deutscher-Filmpreis-2012.jpg to 192.168.1.6:8080 
INFO[2023-08-15T10:10:34Z] share: uploaded /20120416-130213-Flower-2012.jpg to 192.168.1.6:8080 
INFO[2023-08-15T10:10:34Z] share: uploaded /20111002-110008-Dog-2011.jpg to 192.168.1.6:8080 
INFO[2023-08-15T10:10:34Z] share: uploaded /20111002-110008-Dog-2011.yml to 192.168.1.6:8080

I see you are also using an address from your local network, possibly the same host that Docker is running on. So it might also be a problem with the firewall or another network related issue?

I don't know what else I could try to reproduce this...

Screenshots

Add Account Dialog

Account Successfully Added

Edit Account Dialog

@lastzero commented on GitHub (Aug 15, 2023): @eculicny I could not reproduce this, unfortunately. Using port 8080 worked perfectly after I configured the firewall to allow connections from the local network via port 8080. At first, I could not connect to my host over the internal Docker network, also not with curl from inside our dev Docker container: ``` curl -I -X PROPFIND -H "Depth: 1" -u admin:insecure http://192.168.1.4:8080/Photos/ curl: (28) Failed to connect to 192.168.1.4 port 8080 after 130482 ms: Couldn't connect to server ``` However, once the firewall was properly configured, it worked with both curl and PhotoPrism: ``` curl -I -X PROPFIND -H "Depth: 1" -u admin:insecure http://192.168.1.6:8080/Photos/ HTTP/1.1 207 Multi-Status Content-Type: text/xml; charset=utf-8 Www-Authenticate: Basic realm="Restricted" Date: Tue, 15 Aug 2023 10:12:15 GMT Transfer-Encoding: chunked ``` Uploading files worked as well after the service was added: ![webdav-upload](https://github.com/photoprism/photoprism/assets/301686/181a2732-e3ee-4855-a9ee-9e2551244a50) ``` DEBU[2023-08-15T10:09:33Z] webdav: connecting to http://admin:insecure@192.168.1.6:8080/Photos/ DEBU[2023-08-15T10:10:34Z] server: POST /api/v1/services/2/upload (200) [18.901762ms] DEBU[2023-08-15T10:10:34Z] webdav: connecting to http://admin:insecure@192.168.1.6:8080/Photos/ INFO[2023-08-15T10:10:34Z] share: uploaded /20120427-171750-Deutscher-Filmpreis-2012.jpg to 192.168.1.6:8080 INFO[2023-08-15T10:10:34Z] share: uploaded /20120416-130213-Flower-2012.jpg to 192.168.1.6:8080 INFO[2023-08-15T10:10:34Z] share: uploaded /20111002-110008-Dog-2011.jpg to 192.168.1.6:8080 INFO[2023-08-15T10:10:34Z] share: uploaded /20111002-110008-Dog-2011.yml to 192.168.1.6:8080 ``` **I see you are also using an address from your local network, possibly the same host that Docker is running on. So it might also be a problem with the firewall or another network related issue?** I don't know what else I could try to reproduce this... ## Screenshots ### Add Account Dialog ![add-account](https://github.com/photoprism/photoprism/assets/301686/4f3323e3-61cc-45d1-8046-4e6f8ae2c951) ### Account Successfully Added ![added-account](https://github.com/photoprism/photoprism/assets/301686/86f443db-f2fd-4872-82a2-648f4e84791f) ### Edit Account Dialog ![edit-account](https://github.com/photoprism/photoprism/assets/301686/bbb94d40-289f-4857-b77c-950e6a9ed57d)

deekerman commented

2026-02-20 01:00:58 -05:00

Author

Owner

@lastzero commented on GitHub (Aug 15, 2023):

There is a tiny chance that it is a bug in the Go programming language. It has been updated recently, so I tested it with the latest version, while our stable versions use an older Go version. However, it's unlikely that such a basic feature is broken or that Google wouldn't have found and fixed such a major bug long ago.

@lastzero commented on GitHub (Aug 15, 2023): There is a tiny chance that it is a bug in the Go programming language. It has been updated recently, so I tested it with the latest version, while our stable versions use an older Go version. However, it's unlikely that such a basic feature is broken or that Google wouldn't have found and fixed such a major bug long ago.

deekerman commented

2026-02-20 01:00:58 -05:00

Author

Owner

@eculicny commented on GitHub (Aug 16, 2023):

@lastzero Thanks for taking a look and trying to reproduce it!

I see you are also using an address from your local network, possibly the same host that Docker is running on. So it might also be a problem with the firewall or another network related issue?

They are both on the same local network, but the NAS host is a physically separate machine from the host running Docker. The addresses listed are just examples and not actual; my local network is mostly in 10.10.0.0/16 which is where both of these hosts are. I just went with defaults for the examples since I didn't think the actual IP values might be an issue here.

It could be something I missed with the networking. However, the fact that running the curl command from within the running Photoprism container properly connects to and gets the expected response from the NAS host made me think that it's something happening within the Photoprism application when setting up the service connection.

I'll take another look and see if updating to latest from my current version seems to fix the issue or provides any more useful info.

@eculicny commented on GitHub (Aug 16, 2023): @lastzero Thanks for taking a look and trying to reproduce it! > **I see you are also using an address from your local network, possibly the same host that Docker is running on. So it might also be a problem with the firewall or another network related issue?** They are both on the same local network, but the NAS host is a physically separate machine from the host running Docker. The addresses listed are just examples and not actual; my local network is mostly in `10.10.0.0/16` which is where both of these hosts are. I just went with defaults for the examples since I didn't think the actual IP values might be an issue here. It could be something I missed with the networking. However, the fact that running the `curl` command from _within_ the running Photoprism container properly connects to and gets the expected response from the NAS host made me think that it's something happening within the Photoprism application when setting up the service connection. I'll take another look and see if updating to latest from my current version seems to fix the issue or provides any more useful info.

deekerman commented

2026-02-20 01:00:58 -05:00

Author

Owner

@eculicny commented on GitHub (Aug 20, 2023):

Yeah, seems to still be resulting in the same problem with the preview amd64 image available on docker hub. However, I think this might be some problem(s) with how TrueNAS is configuring the webdav share (or some weird networking problem I haven't noticed yet)

From inside the running container

root@230818:/photoprism$ photoprism --version
photoprism version 230818-a3f27c8d6-Linux-AMD64-Plus
root@230818:/photoprism$ curl -I -X PROPFIND -H "Depth: 1" -u webdav:<password> http://10.10.0.2:8080/photosimport/
HTTP/1.1 207 Multi-Status
Date: Sun, 20 Aug 2023 16:00:32 GMT
Server: Apache/2.4.46 (FreeBSD) mpm-itk/2.4.7-04 OpenSSL/1.1.1h-freebsd
Content-Length: 2021
Content-Type: text/xml; charset="utf-8"

In the UI:

If I remove the authentication on the webdav share, I can save the connection in the Photoprism UI

However, I can't seem to get any of the upload or syncing functionality to work. The generic "Could not connect, please try again" popup comes up each time I go to configure one or the other and neither seem to work.

So my guess as to what is happening is that when authentication is setup for the webdav share, the initial test for it fails, and photoprism doesn't save the service config. When auth isn't present, it can save the service, but if the service isn't configured properly, then trying to configure it in Photoprism fails. And the initial troubleshooting I was doing seemed to lead us down the wrong path since all other non-photoprism testing seemed to indicate the webdav share was working as expected.

I'll keep trying to sort this issue out, but it seems less likely that Photoprism is the culprit and more likely that TrueNAS is setting up the share in an incompatible way which was triggering when authentication was enabled. I don't see a reason to keep this issue open as an actual problem since the initial issue seems to work correctly.

@eculicny commented on GitHub (Aug 20, 2023): Yeah, seems to still be resulting in the same problem with the `preview` amd64 image available on docker hub. However, I think this might be some problem(s) with how TrueNAS is configuring the webdav share (or some weird networking problem I haven't noticed yet) From inside the running container ``` root@230818:/photoprism$ photoprism --version photoprism version 230818-a3f27c8d6-Linux-AMD64-Plus root@230818:/photoprism$ curl -I -X PROPFIND -H "Depth: 1" -u webdav:<password> http://10.10.0.2:8080/photosimport/ HTTP/1.1 207 Multi-Status Date: Sun, 20 Aug 2023 16:00:32 GMT Server: Apache/2.4.46 (FreeBSD) mpm-itk/2.4.7-04 OpenSSL/1.1.1h-freebsd Content-Length: 2021 Content-Type: text/xml; charset="utf-8" ``` In the UI: ![image](https://github.com/photoprism/photoprism/assets/4071957/153b7417-fa5c-4958-804a-67fc08b08050) If I remove the authentication on the webdav share, I _can_ save the connection in the Photoprism UI ![image](https://github.com/photoprism/photoprism/assets/4071957/52c8f8cd-21e7-44d7-9141-376ba4bb8556) However, I can't seem to get any of the upload or syncing functionality to work. The generic "Could not connect, please try again" popup comes up each time I go to configure one or the other and neither seem to work. So my guess as to what is happening is that when authentication is setup for the webdav share, the initial test for it fails, and photoprism doesn't save the service config. When auth isn't present, it can save the service, but if the service isn't configured properly, then trying to configure it in Photoprism fails. And the initial troubleshooting I was doing seemed to lead us down the wrong path since all other non-photoprism testing seemed to indicate the webdav share was working as expected. I'll keep trying to sort this issue out, but it seems less likely that Photoprism is the culprit and more likely that TrueNAS is setting up the share in an incompatible way which was triggering when authentication was enabled. I don't see a reason to keep this issue open as an actual problem since the initial issue seems to work correctly.