I'll guarantee that directory not being mounted is the problem. Just like #3633 (closed) , I'm not certain that the solution here is to 're-create' that mount point, rather than something else(ie: having a CI job push an updated list to the website repo on success).
@mward You would recommend that the project creates a job in Jenkins that scans the download directory for their project and outputs the results in a file that would need to be committed in the website repo?
From there, they could read the file and display the information they need on their website?
We already encourage projects to use CI jobs to manage their downloads, so having a CI job build a list of downloads doesn't seem out of line(to me).
Another option might be to simply have a 'downloads list' directory(in the web site repo) and each successful job could post a 'build-X.xml' file there and the site could simply read the last N files and display that information.
Or perhaps the PMIs 'release' data fields could be used to drive such a list via the API.
As we work towards better isolation for our service and sites it's going to put strain on things like our publishing tools for downloadable content(which are rooted in the 'net of 20ish years ago), and projects which were using older setups.
I am not a fan of disabling features without informing our users about it beforehand.
I would recommend that we 1) add the mount to avoid breaking our project's website and 2) create an issue announcing the deprecation of the download directory mount for the project websites on eclipse.dev.
This allows the community to provide feedback and raise any concerns and gives them some time to implement alternative solutions.