"TEMPORARY/PUBLIC/PRIVATE FILES DIRECTORY" security error provides useless guidance

Testing on D 9.5.7. ....

1. Error message leads to the wrong docs and finding this issue is a question of luck. (found it by checkin gif it already exist and needs to be created and then finding a link in another issue leading to here).
2. After reading thrue the issue it creates the impression the correct doc link is this: https://www.drupal.org/docs/installing-drupal/some-directory-not-fully-p... →
3. This docs state that removing a possible outdated .htaccess file will make Drupal to recreate it after entering the file management settings page in admin area. This is partly true and only happens if you run cron.
4. The .htaccess file created by Drupal after that will cause the same error message again.

Comparing the created .htaccess file with others shows following difference:

git diff --git a/private-files/.htaccess b/web/sites/default/files/.htaccess
index d436879..e7f06ca 100644
--- a/private-files/.htaccess
+++ b/web/sites/default/files/.htaccess
@@ -1,13 +1,3 @@
-# Deny all requests from Apache 2.4+.
-<IfModule mod_authz_core.c>
-  Require all denied
-</IfModule>
-
-# Deny all requests from Apache 2.0-2.2.
-<IfModule !mod_authz_core.c>
-  Deny from all
-</IfModule>
-
 # Turn off all options we don't need.
 Options -Indexes -ExecCGI -Includes -MultiViews

@@ -19,9 +9,9 @@ SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006
 </Files>

 # If we know how to do it safely, disable the PHP engine entirely.
-<IfModule mod_php7.c>
+<IfModule mod_php5.c>
   php_flag engine off
 </IfModule>
-<IfModule mod_php.c>
+<IfModule mod_php7.c>
   php_flag engine off
 </IfModule>
\ No newline at end of file

Which propably needs another issue since this here is only regarding the error message.

Since this is a security warning I partly agree on the issue status since this issue let users run in circles with no avail. I strongly recommend to add a temporary section to the docs linked to in the warning leading to here. The warning level in the admin reports is high so it isn't just a "notification".

In comment #29, diqidoq objects:

This doc page states that removing a possible outdated .htaccess file will make Drupal to recreate it after entering the file management settings page in admin area. This is partly true and only happens if you run cron.

This is not my experience.

If the directory in question is writeable by the web server.
The required and correct .htaccess is automatically created when one visits the file system configuration page.

This is really bad UX folks. Please see " support forum post → for a recent example.

Setting it back to "Needs review". If you really think it "Needs work, please list remaining tasks in the issue summary.

A core committer commented with desired changes in #27 yet I don't see any patches since that, nor comments addressing those points.

Updated issue summary with current status.

#33 mentioned the changes that should be addressed

#33 doesn't mention any changes, it just refererences #27. As for #27, it mentions three changes, summarized below:

1. we've got a weird additional indent here
2. let's just inline @doc into the translation string so the additional context is there for translators
3. can we use the directory from the loop instead of ::getTempDirectory for %directory?

I've no idea what is meant by the first one, so I am unable to address this.

However, items #2 and #3 look sensible.

Anyway, we've moved from Drupal 9 to Drupal 11, and patch in #23 no longer applies.