Joomla – keine Installation von Templates möglich

nonpareille8

unregistriert
Thread Starter
Dabei seit
13.05.2005
Beiträge
6.482
Reaktionspunkte
12.661
Hallo,

ich verzweifle so langsam aber sicher:
Es ist nicht möglich ein Template zu installieren, egal wie ich es anstelle.

Ebenso lassen sich auch keine Plug-Ins installieren.

Ob als Paket, aus Verzeichnis oder URL - immer kommt eine Fehlermeldung.
Ich arbeite am Mac, 10.9.4, Joomla 3.3.1, XAMPP 1.8.3-4.

Ich hatte auch den offenen Template-Ordner in den TEMPLATES-Ordner gelegt, das wird auch nicht erkannt.

Die ZIP-Datei wird zwar erkannt, lässt sich aber nicht installieren.

Warnung
Warnung! - Die Datei kann nicht verschoben werden!

JFolder: :files: Der Pfad ist kein Ordner! Pfad: /Applications/XAMPP/xamppfiles/htdocs/wwp_cms/tmp/install_53c28b17c6891

JFolder: :folder: Der Pfad ist kein Ordner! Pfad: /Applications/XAMPP/xamppfiles/htdocs/wwp_cms/tmp/install_53c28b17c6891

JFolder: :files: Der Pfad ist kein Ordner! Pfad: /Applications/XAMPP/xamppfiles/htdocs/wwp_cms/tmp/install_53c28b17c6891

JInstaller: :Install: Die Joomla!-XML-Installationsdatei konnte nicht gefunden werden.

Fehler
Archive does not exist


Mache ich was falsch, hat das irgendwas mit Rechten zu tun, wenn ja, wie kann ich die sinnvoll ändern?
 

Anhänge

  • Rechte.jpg
    Rechte.jpg
    26,9 KB · Aufrufe: 222
Danke für die Info.

Ich habe dem Joomla-Ordner samt den Unterverzeichnissen Lese- und Schreibrechte gegeben.
Jetzt funktioniert es.

Ist das vertretbar wenn die Seite später online gestellt wird (auch aus Sicherheitsaspekten), oder greift da sowieso die Rechteverwaltung des Providers?
 
Kommt darauf an mit was Du die Seite hochlädtst. :)
PRovider-EInstellungen ziehen da ohnehin nicht.
Bei cyberduck z.B. kannst Du angeben ob die Rechte gesetzt werden auf "xx" oder ob sie 1:1 übernommen werden sollen.


wenn alles auf 777 sitzt, dann wäre mir persönlich das zu riskant.

Nein, es gibt leider kein mir bekanntes Script das "Hex, Hex" macht und das alles wieder auf "normal" setzt.
 
Nein, es gibt leider kein mir bekanntes Script das "Hex, Hex" macht und das alles wieder auf "normal" setzt.

Doch, klar gibt's das ;-)

Um nur Dateien rekursiv zu behandeln:

find . -type f -print0 | xargs -0 chmod 644

Um nur Directories rekursiv zu behandeln:

find . -type d -print0 | xargs -0 chmod 755
 
Ich meine "für Joomla richtige" Werte. ;)

Nicht alles in allen Unterverzeichnissen hat ja die selben Rechte. Das meine ich damit.
Ansonsten haben nur die wenigsten Hoster-Webspace einen Shell-Zugang, also muss er das vorher machen und dann sind wir wieder beim Womit-Hochladen. :)
 
Ich meine "für Joomla richtige" Werte. ;)

Nicht alles in allen Unterverzeichnissen hat ja die selben Rechte. Das meine ich damit.
Ansonsten haben nur die wenigsten Hoster-Webspace einen Shell-Zugang, also muss er das vorher machen und dann sind wir wieder beim Womit-Hochladen. :)

doch, hat es. Das sind genau die Werte der ca. 120 Joomla-Installationen auf meinem Server.

Damit man dem wwwrun-Problem aus dem Weg geht, sollte PHP am besten mit fcgid laufen.
 
Also, MEINE "configuration.php" hat 344... :noplan:

EDIT:
Muss natürlich 444 sein. :D :shame:
 
Zuletzt bearbeitet:
Sind die Probleme mit den Rechten mit MAMP hinfällig?
 
@nonpareille8
Meinst du bezogen auf XAMP vs. MAMP? Nein, das ist das Gleiche.

@Falk und beage
Sollte die config nicht 444 haben?
344 hiesse ja ausführen-schreiben/lesen/lesen (u/g/o).

Eine meiner configs ist es jedenfalls und ich habe da nichts geändert.
Das ist aber ein nicht ewig geupdatetes Joomla und das macht es ja seit einiger Zeit von selbst (chmod 444).

Wenn ich mir so einige Installationen ansehe, stehen dort oft Files auf 640 und Dirs auf 750.
(Das hängt aber sicher auch vom Provider ab, ob man das so einstellen kann)
 
Zuletzt bearbeitet:
@Olivetti: Wenn man es genau nimmt, sollte die configuration.php auf 444 stehen. Allerdings müsste man sie dann jedesmal, wenn man im Joomla-Backend die Config speichert, die Rechte ändern.
344 hab ich auch so noch nicht gesehen, weil dieses Recht eigentlich Schwachsinn ist. Warum sollte der Eigentümer ausführen und schreiben dürfen, aber nicht lesen?
 
Nönö, seit 2.5 ist das wohl schon so (config auf 444 und im Backend bearbeitbar).

Ich will ja auch nur auf das von Falk, wahrscheinlich fälschlicherweise, genannte 344 hinweisen.
 
Ist das vertretbar wenn die Seite später online gestellt wird (auch aus Sicherheitsaspekten), oder greift da sowieso die Rechteverwaltung des Providers?
Naja, die Rechte hast Du damit praktisch außer Kraft gesetzt, weil Du eben gesagt hast: jeder darf schreiben.

Doch, klar gibt's das ;-)

Um nur Dateien rekursiv zu behandeln:

find . -type f -print0 | xargs -0 chmod 644

Um nur Directories rekursiv zu behandeln:

find . -type d -print0 | xargs -0 chmod 755
Das geht einfacher: chmod -R ug=rwX,o-rwx * oder gar noch restriktiver chmod -R u=rwX,go-rwx

EDIT: wenn Du unbedingt ein 755/644 haben willst, geht natürlich auch chmod -R u=rwX,go=rX *. Wobei, wenn "die Anderen" nicht schreiben dürfen, dann brauchen sie auch nicht lesen müssen.
 
Zuletzt bearbeitet:
@Falk und beage
Sollte die config nicht 444 haben?
344 hiesse ja ausführen-schreiben/lesen/lesen (u/g/o).

Stimmt. Klassik doofer Tippfehler von mir... :teeth:
:keks:



Eine meiner configs ist es jedenfalls und ich habe da nichts geändert.
Das ist aber ein nicht ewig geupdatetes Joomla und das macht es ja seit einiger Zeit von selbst (chmod 444).

Wenn ich mir so einige Installationen ansehe, stehen dort oft Files auf 640 und Dirs auf 750.
(Das hängt aber sicher auch vom Provider ab, ob man das so einstellen kann)

Einstellen können sollte man es bei jedem Provider, sonst verdient er den Namen nicht - jedenfalls meine Meinung.

Ansonsten zeigt die begonnene Diskussion, dass es eben sehr differenzierte Rechte gibt und wenn man die erst mal irgendwie vergeigt hat, dann ist das Rekonstruieren ziemliches Gefummel.
 
@Falk
Dachte ich mir bei dir ja, dass es ein Versehen ist.

Ich hake jetzt aber trotzdem nochmal nach, weil ich das Gefühl habe,
nonpareilles eigentliche Frage wurde noch nicht befriedigend beantwortet.

Wenn er seine lokal chmod-verhunzten Dateien und Ordner via ftp (abgesehen von z.B. Cyberduck,
wo es einstellbar ist) auf einen üblichen FTP-Server hochlädt, dann bekommen die Dateien und Ordner
jedenfalls die Rechte des Provider-FTP-Servers, welche üblicherweise mit umask 0022 maskiert werden,
d.h. Files 644 und Ordner 755.
 
Zuletzt bearbeitet:
It depends .. siehe weiter vorne. Es kommt darauf an womit er die hochlädt. Es gibt ftp-clients, die ändern das nun mal ab.
 
Naja, die Rechte hast Du damit praktisch außer Kraft gesetzt, weil Du eben gesagt hast: jeder darf schreiben.


Das geht einfacher: chmod -R ug=rwX,o-rwx * oder gar noch restriktiver chmod -R u=rwX,go-rwx

EDIT: wenn Du unbedingt ein 755/644 haben willst, geht natürlich auch chmod -R u=rwX,go=rX *. Wobei, wenn "die Anderen" nicht schreiben dürfen, dann brauchen sie auch nicht lesen müssen.

Naja, ob das jetzt einfacher ist ...
 
Ich hake jetzt aber trotzdem nochmal nach, weil ich das Gefühl habe,
nonpareilles eigentliche Frage wurde immer noch nicht befriedigend beantwortet.

Wenn er seine lokal chmod-verhunzten Dateien und Ordner via ftp auf einen üblichen FTP-Server hochlädt,
dann bekommen die Dateien und Ordner jedenfalls die Rechte des Provider-FTP-Servers,
welche üblicherweise mit umask 0002 maskiert werden, d.h. Files 644 und Ordner 755.

Richtig
 
Zurück
Oben Unten