private Files Verzeichnis und dazu passende .htaccess Datei

Hallo Dorothea,
private files sollten außerhalb der Drupal-Dateiablage sein, also nicht im sites-Verzeichnis.
Die htaccess-Datei funktioniert mit diesem Inhalt:

Dazu musst du dann noch die Datei /sites/default/settings.php ändern:
* Private file path:
*/
$settings['file_private_path'] = 'Dein Pfad';

leider nicht - im Gegenteil, nun kommen zwei Fehlermeldungen: drupal findet das Verzeichnis nicht und behauptet, private Files seien nicht ausreichend geschützt.
Vielleicht liegt es am shared hosting, dass ich irgendwie die Pfade nicht korrekt eingegeben habe? Mir ist noch nicht klar, wie ich einen Pfad anlege, der nicht über das Internet erreichbar ist, wenn ich auf einer chroot Umgebung arbeite und wo ich das dann alles eintragen muss, damit es korrekt läuft...
Aber Danke für die .htaccess Datei!
LG
D.

Da habe ich auch lange zu gebraucht ;-)
mit putty und dem Befehl pwd kannst du dir den richtigen Pfad anzeigen lassen.

shared hosting kann das auch.
Der private Pfad liegt dann (bei mir) z.B. "eins tiefer",
.../extra/ 'daneben' vom Document-Root
.../web/sites/default/ ..
Die .htaccess liegt in diesem Beispiel in /extra
und in settings.php hab ich dann
$settings['file_private_path'] = '../extra';

bei mir scheint das irgendwie nicht zu funktionieren, obwohl ich via FTP das entsprechende Verzeichnis nun an verschiedenen Stellen erstellt habe und die settings.php entsprechend angepasst habe - aber ich habe kein Verzeichnis "web", auch wenn drupal einwandfrei läuft. Vielleicht muss ich alles neu installieren? Oder ich muss erstmal kapieren, wie das mit den Unterverzeichnissen genau sein sollte...
Momentan ist beruflich bei mir viel los - daher melde ich mich wieder, wenn etwas mehr Luft ist.
Danke!
LG
D.

Private files sind in Drupal dafür da um Dateien mit Access-Steuerung durch Drupal zu schützen. Genau darin liegt auch dessen Nachteil, da dies Ressourcen via PHP und Datenbank verbraucht. Das heißt, da sollte man auch wissen, warum man die Private files benutzen möchte bzw. sollte.

Die ".htaccess"-Datei kann diverse Konfigurations-Anweisungen enthalten, die von Apache Web-Servern gelesen und ausgewertet werden. Das ist bei der Standard-Konfiguration von Apache der Fall und wird in der Regel von Shared Hosting-Anbietern genutzt. Das macht die Ausführung von Web-Anwendungen aber langsamer. Um die Flexibilität dieser von Usern bzw. in diesem Fall Drupal selbst organisierter Konfiguration aufrecht zu erhalten aber mehr Performance bei ausliefern von "Public"-Files zu beschleunigen wird vor dem Apache Web-Server gerne auch mal ein Nginx-Webserver als Proxy verwendet. Der Nginx kann aber auch direkt Drupal mit PHP verknüpfen und macht das dann auch schneller. Allerdings sind die Konfigurations-Abweisungen aus .htaccess-Dteien dem Nginx unbekannt. Man muss sich dann also selbst drum kümmern bzw. der Hosting-Verantwortliche. Drupal überprüft aber trotzdem die Standard-Verzeichnisse wie das public und das private Files Verzeichnis, ob es darin einen ".htaccess"-Schutz gibt, der vor allem die PHP-Ausführung verhindern soll. Diese Standard-Überprüfung ist für Nginx nicht nur nervig, sondern geradezu trügerisch, or allem, wenn es fälschlich OK ergibt. Das ist aber eigentlich generell nur ein Hilfskonstrukt da sich weder im Shared Hosting noch im Custom Hosting kaum jemand eine viel sicherer Strategie nutzt: Den Webserver nur zu erlauben, die wirklich benötigten PHP-Dateien auszuführen bzw. an einen PHP-Prozess (z.B. FPM) zu übergeben. Das kann man sowohl unter Nginx als auch Apache so konfigurieren. D.h. shared Hoster könnten das auch machen, aber das habe ich noch nicht gesehen.
Aber bezüglich Private Files außerhalb des Webroots sind spezielle Zugriffs bzw. PHP Beschränkungen in der Regel ngar nicht nötig auch nicht via .htaccess, da dort eben nur Drupal direkt darauf zugreifen kann und eben dann die Daten (auch ein File) nach Überprüfung der Drupal internen Zugriffs-Regeln dem Webserver und dieser dann dem Browser "übergibt".

/web/ wird für D8 oder D9+ mit composer-Skript "drupal/recommended-project" erzeugt. Andere Wege sind möglich, aber da wirds wohl unübersichtlicher.
Wirksamer Maßstab in meiner Erfahrung: drush muss laufen ...