htaccess lässt sich nicht löschen/ändern
Eingetragen von batman1983 (189)am 16.07.2008 - 12:28 Uhr in
Hey Leute,
meine .htaccess im sites/default/files Ordner lässt sich nicht löschen. Meine Bilder werden nicht angeeigt, aufgrund der .htaccess. Wie bekomm ich die gelöscht oder geändert?
MFG Batman1983
- Anmelden oder Registrieren um Kommentare zu schreiben
1. Aendere den Besitzer bzw.
am 16.07.2008 - 13:40 Uhr
1.
Aendere den Besitzer bzw. die Rechte auf die .htaccess.
oder/und
2.
Benenne die .htaccess um. Zumindest kannst Du dann erst Mal eine neue .htaccess hochladen.
-------------
quiptime
Nur tote Fische schwimmen mit dem Strom.
Leider geht das auch
am 16.07.2008 - 14:22 Uhr
Leider geht das auch nicht.
Das sagt mein FTP Programm:
SITE CHMOD 777 .htaccess
550 .htaccess: Operation not permitted
Ich kann es nicht umbenennen oder löschen.
Da ist wohl beim Hoster das
am 16.07.2008 - 14:34 Uhr
Da ist wohl beim Hoster das .httacces Feature innerhalb von FTP nicht richtig aufgesetzt.
So wie es aussieht hat die .httacces einen besonderen Schutz der es Dir nicht erlaubt mit ihr zu arbeiten. Das ist aber widersinnig.
Teste mal das Umbenennen in ~.htaccess
Also das Zeichen ~ davor. Hat bei mir bisher so in fast allen aehnlich gelagerten Faellen funktioniert. Wenn es so funktioniert ist aber das offensichtliche grundsaetzliche Problem mit der .htaccess noch nicht geloest.
-------------
quiptime
Nur tote Fische schwimmen mit dem Strom.
Das gleiche Problem hatte
am 16.07.2008 - 19:13 Uhr
Das gleiche Problem hatte ich auch mal (mit Filezilla).
Ich nutze nun WinSCP (http://sourceforge.net/projects/winscp/),
und habe derlei Probleme nicht mehr.
Grüsse aus dem Bergischen Land
Dino Conte
Besitzrechte
am 16.07.2008 - 20:29 Uhr
So etwas kenne ich wenn Daten z.B. durch eine Installation erzeugt werden. Dazu bietet mein Provider im admin das Tool "Besitzrechte" um diese auch an den FTP user zurückzugeben.
buntstich
security risk
am 16.07.2008 - 20:33 Uhr
Lass mich raten: in der .htaccess steht das hier drin:
SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006Options None
Options +FollowSymLinks
Die Datei wurde von Drupal angelegt, um security risks vorzubeugen. Lies dazu bitte diesen Thread hier im DC.
Das Leeren der Datei als Umgehen des Löschens (weil sie nach Löschen gleich wieder neu angelegt wird) ist höchstriskant genau dann, wenn bei Dir User Upload-Rechte haben. Falls nicht, könnte man die Rechte der Datei via PHP ändern und die Datei tatsächlich leeren.
Meine Bilder werden nicht angeeigt, aufgrund der .htaccess.
Das wäre kein "normales" Verhalten. Der Schluss muss auch nicht stimmen ... - Man sollte dem vor dem wilden Löschen besser auf den Grund gehen.
Das ganze befindet sich auf
am 16.07.2008 - 21:37 Uhr
Das ganze befindet sich auf unserem Root Server. Da ich nicht der Server Admin bin, ich aber weiß, dass wir durch Confixx sehr eingeschränkt sind, weiß ich nicht, wie wir dem entgegenwirken können, dass die hochgeladenen Bilder angezeigt werden. Derzeit habe ich nur ich die Berechtigung Bilder hochzuladen. Später bekommen evtl. auch User Bilder hochzuladen.
MFG Batman1983
PS: Das mit Winscp hat auch nicht geklappt... (Grüße an meine Heimat: das Bergische Land ;))
Server Admin
am 16.07.2008 - 23:30 Uhr
Bitte doch Deinen Server-Admin, dass er Dir mitteilt, warum der Apache verweigert, Dateien aus dem sites-Ordner auszuliefern (error.log?). Er möge eine Lösung in Betracht ziehen, die die .htaccess-Datei unter sites so beläßt, wie sie ist. Falls der Server-Admin das Problem lösen kann, bitte ich dringend um Dein Posting hier, wie er das gemacht hat. Es handelt sich nämlich in irgendeiner Weise um eine Apache-(Miss?)- oder auch sonstwie untaugliche Server-Konfiguration, dass es hier Probleme gibt. Ich wüsste daher selber auch sehr gerne, wie das Problem entsteht, denn einerseits haben doch einige Drupal-Admins dieses Problem immer wieder, andererseits haben alle Drupal-Installationen eine .htaccess im files-folder und das funktioniert auch meistens.
EDIT: Ist das eigtl. unmittelbar nach der Installation aufgetreten, oder erst eine Folge von - ja von was? Seit welchem markanten Ereignis tritt das auf? Gab es einen Serverumzug? (Wie genau lauten die Dateiberechtigungen der .htaccess? -> 0664 ?)
EDIT-2: Hast Du im Drupal-Root-Verz. etwas an der originalen .htaccess verändern müssen, damit Drupal läuft?
Also wie schon geschrieben,
am 17.07.2008 - 17:25 Uhr
Also wie schon geschrieben, sind wir durch Confixx sehr eingeschänkt. Wenn unser Server Admin was ändern will, blockt Confixx das wieder. Folgende Optionen erlaubt Confixx:
Deshalb musste ich auf die erste .htaccess ändern, damit D6 überhaupt läuft:
#
# Apache/PHP/Drupal settings:
#
# Protect files and directories from prying eyes.
#<FilesMatch "\.(engine|inc|info|install|module|profile|po|sh|.*sql|theme|tpl(\.php)?|xtmpl)$|^(code-style\.pl|Entries.*|Repository|Root|Tag|Template)$">
# Order allow,deny
#</FilesMatch>
# Don't show directory listings for URLs which map to a directory.
#Options -Indexes
# Follow symbolic links in this directory.
#Options +FollowSymLinks
# Customized error messages.
ErrorDocument 404 /index.php
# Set the default handler.
#DirectoryIndex index.php
# Override PHP settings. More in sites/default/settings.php
# but the following cannot be changed at runtime.
# PHP 4, Apache 1.
<IfModule mod_php4.c>
php_value magic_quotes_gpc 0
php_value register_globals 0
php_value session.auto_start 0
php_value mbstring.http_input pass
php_value mbstring.http_output pass
php_value mbstring.encoding_translation 0
</IfModule>
# PHP 4, Apache 2.
<IfModule sapi_apache2.c>
php_value magic_quotes_gpc 0
php_value register_globals 0
php_value session.auto_start 0
php_value mbstring.http_input pass
php_value mbstring.http_output pass
php_value mbstring.encoding_translation 0
</IfModule>
# PHP 5, Apache 1 and 2.
#<IfModule mod_php5.c>
# php_value magic_quotes_gpc 0
# php_value register_globals 0
# php_value session.auto_start 0
# php_value mbstring.http_input pass
# php_value mbstring.http_output pass
# php_value mbstring.encoding_translation 0
#</IfModule>
# Requires mod_expires to be enabled.
<IfModule mod_expires.c>
# Enable expirations.
ExpiresActive On
# Cache all files for 2 weeks after access (A).
ExpiresDefault A1209600
# Do not cache dynamically generated pages.
ExpiresByType text/html A1
</IfModule>
# Various rewrite rules.
<IfModule mod_rewrite.c>
RewriteEngine on
# If your site can be accessed both with and without the 'www.' prefix, you
# can use one of the following settings to redirect users to your preferred
# URL, either WITH or WITHOUT the 'www.' prefix. Choose ONLY one option:
#
# To redirect all users to access the site WITH the 'www.' prefix,
# (http://example.com/... will be redirected to http://www.example.com/...)
# adapt and uncomment the following:
#
# To redirect all users to access the site WITHOUT the 'www.' prefix,
# (http://www.example.com/... will be redirected to http://example.com/...)
# uncomment and adapt the following:
# RewriteCond %{HTTP_HOST} ^www\.example\.com$ [NC]
# RewriteRule ^(.*)$ http://example.com/$1 [L,R=301]
# Modify the RewriteBase if you are using Drupal in a subdirectory or in a
# VirtualDocumentRoot and the rewrite rules are not working properly.
# For example if your site is at http://example.com/drupal uncomment and
# modify the following line:
# RewriteBase /drupal
#
# If your site is running in a VirtualDocumentRoot at http://example.com/,
# uncomment the following line:
# RewriteBase /
# Rewrite URLs of the form 'index.php?q=x'.
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]
</IfModule>
# $Id: .htaccess,v 1.90 2007/10/05 14:43:23 dries Exp $
Spruch des Tages
am 17.07.2008 - 17:57 Uhr
Wenn unser Server Admin was ändern will, blockt Confixx das wieder.
Das ist der Spruch des Tages.
Ich denke, dass auch via Confixx vhost-spezifische Apache-Einstellungen vom Admin getätigt werden können. Ich würde für den Drupal-vhost "AllowOverride All" setzen lassen und die originale DOCUMENT_ROOT-.htaccess von Drupal verwenden. Dann würde wohl auch das files-Verz. gleich ganz willig mitspielen. Anderfalls aber müssen für Deinen vhost sicherlich für das Verz. files (um das es hier geht) die "Options +FollowSymLinks" in der httpd.conf gesetzt sein. In der .htaccess im files-Verz. müssten dann die beiden letzten Zeilen, da wohl nicht zugelassen, auskommentiert werden, so dass nur die erste SetHandler-Zeile stehen bleibt. Vielleicht geht es ja dann so.
Jedenfalls würde ich ein manipuliertes PHP-Skript, wie im oben verlinkten Neben-Thread erwähnt, hochladen und auszuführen versuchen, um sicher zu sein, dass der Drupal-Sicherheitsmechanismus von Confixx auch wirklich "zugelassen wurde". Vorher würde ich da niemanden "Fotos" hochladen lassen. Aber so, wie Du es beschreibst, ist der Einsatz von Confixx das größere Sicherheitsrisiko.
Da ich kein Server Admin
am 18.07.2008 - 13:16 Uhr
Da ich kein Server Admin bin, sondern nur jemand, der Drupal zum laufen bringen will, kann ich dazu nicht viel sagen. Unser Admin hat mir folgendes geschrieben:
- und exakt das, was tumblingmug da behauptet ist auch möglich...
- nur halt global...
- und damit haben alle leute die rechte...
- und exakt das ist nicht sinn der sache...
- bei uns läuft halt nicht nur ein account sondern mehrere...
Vielleicht kannst du da nun was zu sagen?
Die AllowOverride-Direktive
am 18.07.2008 - 17:51 Uhr
Die AllowOverride-Direktive ist directory-spezifisch, d.h. für einen einzelnen Vhost, dessen DOCUMENT_ROOT unter z.B. /var/www/vhost543 liegt könnte m. E. gesetzt werden, z.B.:
<Directory /var/www/vhost543/htdocs>AllowOverride All
</Directory>
Das müsste in die http.conf (am besten unterhalb der INCLUDE-Anweisung für die confixx_vhost.conf) eingebunden werden. Aber natürlich muss das der Admin auch wollen. Du kannst mit solchen Rechten schon ziemlich Schindluder treiben ...