2.4.6 regression: presence of symlink breaks file_server browse

[bones-was-here]

It seems that if a symlink exists in a directory, that directory's contents can't be viewed with the browser. The error is 404. It happens with valid and broken symlinks. 2.4.5 does not have this issue.

[francislavoie]

The change in #4354 must've been the cause.

@HayatoShiba would you be willing to look into this, since it was your change? Thanks!

[mcguirepr89]

I've noticed this issue as well for v2.4.6-- you can see here -- the symbolic links that point to directories are browseable (see Extractions link "By Common Name"). Inside those directores, however, you'll get a 404. I have verified that the symlinks are there. The Extractions link "By Date" are the sources to which the symlinks point, for reference.

Please let me know if I can provide any more information.

[francislavoie]

@mcguirepr89 could you try building from PR #4415, with the proposed fix? Confirmations that it fixes it will speed up the process!

[mcguirepr89]

Sure thing! Give me a little bit and I'll let you know

[mcguirepr89]

@francislavoie unfortunately, that did not fix the issue on my end -- you can see the same site is now being served from a caddy built from PR #4415

for a frameless caddy-only site go here

[francislavoie]

Okay, thanks @mcguirepr89.

@jjlin see the above?

[jjlin]

@mcguirepr89 Are you sure your build actually includes the fix?

Try this:

mkdir /tmp/symlink-test
echo foo > /tmp/symlink-test/foo
ln -s foo /tmp/symlink-test/foo-symlink
caddy file-server -browse -root /tmp/symlink-test -listen :8080

Without the fix (version 2.4.6):

$ curl -I http://localhost:8080
HTTP/1.1 404 Not Found
Server: Caddy
Date: Fri, 12 Nov 2021 21:12:16 GMT

With the fix (PR #4415):

$ curl -I http://localhost:8080
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Server: Caddy
Date: Fri, 12 Nov 2021 21:12:30 GMT

If that works the same way for you, can you elaborate on your directory structure and what your Caddyfile or command line looks like?

[mcguirepr89]

@jjlin
Here is what I can report for now (I've got about 5 more minutes before I have to leave for a few hours):
I ran the "Try this" portion to create the symlinks and have the PR results (HTTP 200 OK) for the curl response.

The directory structure is below:

BirdSongs/Extracted/
├── By_Common_Name
│   ├── Canada_Goose
│   ├── Carolina_Chickadee
│   ├── Carolina_Wren
│   ├── Coopers_Hawk
│   ├── Eastern_Phoebe
│   ├── Eastern_Screech-Owl
│   ├── House_Finch
│   ├── Killdeer
│   ├── Mallard
│   ├── Northern_Saw-whet_Owl
│   ├── Song_Sparrow
│   ├── Turkey_Vulture
│   └── Yellow-breasted_Chat
├── By_Date
│   └── 2021-11-12
├── By_Scientific_Name
│   ├── Accipiter_cooperii
│   ├── Aegolius_acadicus
│   ├── Anas_platyrhynchos
│   ├── Branta_canadensis
│   ├── Cathartes_aura
│   ├── Charadrius_vociferus
│   ├── Haemorhous_mexicanus
│   ├── Icteria_virens
│   ├── Megascops_asio
│   ├── Melospiza_melodia
│   ├── Poecile_carolinensis
│   ├── Sayornis_phoebe
│   └── Thryothorus_ludovicianus
├── external.html -> /home/pi/BirdNET-Pi/homepage/external.html
├── footer.html -> /home/pi/BirdNET-Pi/homepage/footer.html
├── from64 -> /home/pi/BirdNET-Pi/homepage/from64
├── images -> /home/pi/BirdNET-Pi/homepage/images
├── index.html -> /home/pi/BirdNET-Pi/homepage/index.html
├── menu.html -> /home/pi/BirdNET-Pi/homepage/menu.html
├── mobile.html -> /home/pi/BirdNET-Pi/homepage/mobile.html
├── phpsysinfo -> /home/pi/phpsysinfo
├── Processed -> /home/pi/BirdSongs/Processed
├── scripts -> /home/pi/BirdNET-Pi/scripts
├── spectrogram.php -> /home/pi/BirdNET-Pi/scripts/spectrogram.php
├── spectrogram.png
├── style.css -> /home/pi/BirdNET-Pi/homepage/style.css
├── top.html -> /home/pi/BirdNET-Pi/homepage/top.html
└── viewdb.php -> /home/pi/BirdNET-Pi/scripts/viewdb.php

I'm so sorry I have to go at the moment but will update when I am back

And my Caddyfile (with basicauth stuff removed):

http://localhost http://birdnetpi.local https://birdnetpi.pmcgui.xyz {
  root * /home/pi/BirdSongs/Extracted
  file_server browse
  basicauth /Processed* {
  }
  basicauth /scripts* {
  }
  basicauth /stream {
  }
  basicauth /phpsysinfo* {
  }
  reverse_proxy /stream localhost:8000
  php_fastcgi unix//run/php/php7.4-fpm.sock
}

https://extractionlog.pmcgui.xyz {
  reverse_proxy localhost:8888
}

https://birdnetlog.pmcgui.xyz {
  reverse_proxy localhost:8080
}

[jjlin]

Well, I don't see anything unusual there. I'm still thinking something else is going wrong on your side.

Famous last words, but I don't see anything that could go catastrophically wrong in the PR. directoryListing() doesn't return errors anymore, and os.Stat() errors on symlinks are just swallowed, so even if the path construction logic is totally wrong, the worst case result would be the size reported for a symlink is the size of the symlink itself.

It would be helpful if others affected by this issue could offer some additional data points. I serve a directory structure with lots of symlinks, and the fix works fine for me.

[francislavoie]

Please turn on the debug global option and report what's in your logs. file_server errors are often reported at the debug level because some are "normal" and would be too noisy otherwise.

[mcguirepr89]

Hello @francislavoie and @jjlin -- I apologize for the delay. Please find the debug-enabled logging for the site using #4415. The log shows me attempting to access a directory with symbolic links:

2021/11/13 13:23:13.334	DEBUG	tls.handshake	default certificate selection results	{"identifier": "birdnetpi.pmcgui.xyz", "subjects": ["birdnetpi.pmcgui.xyz"], "managed": true, "issuer_key": "acme-v02.api.letsencrypt.org-directory", "hash": "e44f3e0bc6870f99372deb14e42783a7e5135ddfd1247b22118d80164de0b5a2"}
2021/11/13 13:23:13.334	DEBUG	tls.handshake	matched certificate in cache	{"subjects": ["birdnetpi.pmcgui.xyz"], "managed": true, "expiration": "2022/02/10 19:53:00.000", "hash": "e44f3e0bc6870f99372deb14e42783a7e5135ddfd1247b22118d80164de0b5a2"}
2021/11/13 13:23:13.377	DEBUG	http.handlers.file_server	sanitized path join	{"site_root": "/home/pi/BirdSongs/Extracted", "request_path": "/By_Common_Name/", "result": "/home/pi/BirdSongs/Extracted/By_Common_Name/"}
2021/11/13 13:23:13.377	DEBUG	http.handlers.file_server	no index file in directory	{"path": "/home/pi/BirdSongs/Extracted/By_Common_Name/", "index_filenames": ["index.html", "index.txt"]}
2021/11/13 13:23:13.377	DEBUG	http.handlers.file_server	browse enabled; listing directory contents	{"path": "/home/pi/BirdSongs/Extracted/By_Common_Name/", "root": "/home/pi/BirdSongs/Extracted"}
2021/11/13 13:23:15.604	DEBUG	http.handlers.file_server	sanitized path join	{"site_root": "/home/pi/BirdSongs/Extracted", "request_path": "/By_Common_Name/Belted_Kingfisher/", "result": "/home/pi/BirdSongs/Extracted/By_Common_Name/Belted_Kingfisher/"}
2021/11/13 13:23:15.606	DEBUG	http.handlers.file_server	no index file in directory	{"path": "/home/pi/BirdSongs/Extracted/By_Common_Name/Belted_Kingfisher/", "index_filenames": ["index.html", "index.txt"]}
2021/11/13 13:23:15.608	DEBUG	http.handlers.file_server	browse enabled; listing directory contents	{"path": "/home/pi/BirdSongs/Extracted/By_Common_Name/Belted_Kingfisher/", "root": "/home/pi/BirdSongs/Extracted"}

The messages do say no index file in directory, which are usually created dynamically, is that right?

I'm still thinking something else is going wrong on your side.

@jjlin I am not able to do much more until tomorrow when I will be able to test these things on a clean install, but please let me know how I can help.

Thank you all,
Patrick

[mcguirepr89]

I've still not been able to get back to try on a clean install -- but I did downgrade to 2.4.5 and now everything works as expected. I didn't change anything else on my end except for the downgrade.

[jjlin]

@mcguirepr89 It's a bit difficult to determine what's really going wrong without access to your environment. Could you maybe pare down your directory structure and config to create a minimal reproducible example? Also, it would probably be better to move this discussion over to #4415 since your issue is really with that specific implementation.

[mholt]

If someone else with the problem can verify that #4415 fixes the problem, we can probably merge it.

[mcguirepr89]

I can verify that PR #4415 fixes my issue thanks to @jjlin

[mholt]

Thank you everyone for helping with this!

[mcguirepr89]

I echo those thanks