Fehler 500 beim Aufruf der Webseiten in Unterordnern DS218

[Uli-Stefan]

Hallo zusammen,

Folgende Situation: ich möchte zu Testzwecken verschiedene Webseiten (verschiedene Ordner) auf dem Webserver ans Laufen zu bringen und bekomme beim Aufruf der Seiten ständig die Fehlermeldung „500 Bei der Verarbeitung dieser Anforderung ist ein Fehler aufgetreten.“

Meine Installation auf der DS218:
DSM7
Webstation-installiert
Apache http Server 2.4-installiert
PHP 7.4- installiert
PHP 8.0-installiert
phpMyAdmin-installiert
MariaDM10-installiert

Konfiguration:
\Web (Standardverzeichnis von der Webstation)

\web\ordner-1\
\web\ordner-2\

(In diesen Ordnern sollen die unterschiedlichen Webanwendungen laufen)

Im Webdienstportal der Webstationen habe ich jeweils:

Virtueller Host ordner-1 Port 80/443
Virtueller Host ordner-2 Port 80/443

eingerichtet.
In den Skript-Spracheinstellungen unter Erweiterungen sämtliche Häkchen gesetzt.

Gruppenrechte:

Für den Webordner sind die Gruppenrechte http auf „lesen & schreiben“ gesetzt

IP-Adresse der Diskstation 192.168.1.17

Scheinbar liegt es an den Einstellungen oder ich muss noch irgendetwas übersehen haben.

Wenn ich eine einfache indes.html in eines der Verzeichnisse kopiere und dann lokal über den Webbrowser aufrufe funktioniert es
192.168.1.17/ordner-1 oder
192.168.1.17/ordner-2

Sobald ich jedoch eine Installationsroutine einer Webanwendung in einem der Ordner aufrufe klappt es nicht und die Fehlermeldung 500 erscheint.

In beiden Ordnern habe ich es mit unterschiedlichen Webanwendungen versucht und nun hänge ich an dieser Stelle fest.

Vielleicht hat jemand noch eine Idee.

 

[Styler]

Hallo, ich habe so ziemlich das gleiche Problem. Ich installiere gerade ein neues 1CRM Release auf einer neu aufgesetzten DS918+ mit DSM 7.1.1-42962 Update 4 Das alte Release funktioniert, beim Neuen erhalte ich auch den error 500. Die einfache HTLM funktioniert auch prima. Es ist auch egal ob nginx oder apache. Die Installation im /web Hauptverzeichnis funktioniert auch nicht. Kann mich wohl mit DSM7 nie anfreunden.

Welche Anwendung ist es bei Dir?

Verrückt auch, warum finde ich im DSM7 ohne installiertes PHP-Paket in /bin ein echtes Programm in der Version 7.3.3 !??
/bin/php --version
PHP 7.3.3 (cli) (built: Oct 7 2021 06:18:21) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.3.3, Copyright (c) 1998-2018 Zend Technologies

Getestet habe ich PHP 7.4 und leider nur die PHP 8.0
Die Anforderungen bei mir sind:

Systemkomponente	Anforderungen 1CRM
Webserver	Apache oder NGINX
Datenbank	MariaDB oder MySQL
PHP-Version	PHP 7.4 - 8.1
PHP-Module	PHP-XML Modul PHP-GD Modul PHP-SOAP Modul MBstring cURL LDAP IMAP

 

[Uli-Stefan]

Versucht habe ich es zunächst mit einer CRM "Dolibarr" und als nächstes das LMS "ILIAS"
Beide geben beim Aufruf der Installationsroutine oder der Startseite die Meldung 500 aus. An den Anwendungen kann es wohl nicht liegen und auch bei den Rechten sehe ich nicht das Problem.
Ich habe genau die gleiche DSM Version und Update 4 drauf laufen wie Du.

 

[Styler]

Ich habe zwei Versionen für die CRM-Installation bekommen. Ich glaube, die neue, die nicht funktioniert, ist für die Cloud.
Die andere läuft ja On Premise auf der Syno. 1CRM sieht sonst prima und sehr vollständig aus.

Bei Dolibarr hatte ich noch gefunden:
Create an empty htdocs/conf/conf.php file and set write permissions for your web server user (write permission will be removed once install is finished)

 

[Styler]

Nun habe ich es auch unter DSM7.0-42218 ausprobiert, negativ. Einen Tag sinnlos mit Ausprobieren verbracht.
ERP-/CRM-Software etc. läuft anscheinend nur auf DSM6.2.4, wie auch beide Versionen von 1CRM.

 

[Styler]

Hallo zusammen,

Folgende Situation: ich möchte zu Testzwecken verschiedene Webseiten (verschiedene Ordner) auf dem Webserver ans Laufen zu bringen und bekomme beim Aufruf der Seiten ständig die Fehlermeldung „500 Bei der Verarbeitung dieser Anforderung ist ein Fehler aufgetreten.“

Meine Installation auf der DS218:
DSM7
Webstation-installiert
Apache http Server 2.4-installiert
PHP 7.4- installiert
PHP 8.0-installiert
phpMyAdmin-installiert
MariaDM10-installiert

Konfiguration:
\Web (Standardverzeichnis von der Webstation)

\web\ordner-1\
\web\ordner-2\

(In diesen Ordnern sollen die unterschiedlichen Webanwendungen laufen)

Im Webdienstportal der Webstationen habe ich jeweils:

Virtueller Host ordner-1 Port 80/443
Virtueller Host ordner-2 Port 80/443

eingerichtet.
In den Skript-Spracheinstellungen unter Erweiterungen sämtliche Häkchen gesetzt.

Gruppenrechte:

Für den Webordner sind die Gruppenrechte http auf „lesen & schreiben“ gesetzt

IP-Adresse der Diskstation 192.168.1.17

Scheinbar liegt es an den Einstellungen oder ich muss noch irgendetwas übersehen haben.

Wenn ich eine einfache indes.html in eines der Verzeichnisse kopiere und dann lokal über den Webbrowser aufrufe funktioniert es
192.168.1.17/ordner-1 oder
192.168.1.17/ordner-2

Sobald ich jedoch eine Installationsroutine einer Webanwendung in einem der Ordner aufrufe klappt es nicht und die Fehlermeldung 500 erscheint.

In beiden Ordnern habe ich es mit unterschiedlichen Webanwendungen versucht und nun hänge ich an dieser Stelle fest.

Vielleicht hat jemand noch eine Idee.

Gelöst!

Es scheint, unter DSM7 sind von Synology Anwendung ohne "Paket basiertes Profil" irgendwo/irgendwie ausgeschlossen.

Daher habe ich es nun auch hinbekommen, indem ich vtigerCRM installiert habe (nur bis zum erstmaligen Aufruf der Seite), und an dessen Stelle im Verzeichnis /volume1/web_packages/vtigercrm meine neue Anwendung platziert habe.

1. vtigerCRM im Paketzentrum stoppen
2. cd /volume1/web_packages/vtigercrm
3. rm -R *
4. über die FileStation die neue Anwendung ohne Unterverzeichnis in /volume1/web_packages/vtigercrm entpacken
5. chown -R vtigerCRM:vtigerCRM *
6. vtigerCRM im Paketzentrum starten
7. Anwendung im Browser über DeinSynoName/vtigercrm aufrufen
8. weiter machen in der neuen Anwendung

Es ist erstmal ein Workaround, aber man kann ja jetzt herausfinden, was über das Webdienstportal anders geregelt ist.

Sehr unschön, aber
Das ist der Weg!

P.S. vielleicht ist es auch nur diese Sache die zu setzen ist (probiere ich gleich mit roundcube 1.5.3 aus):

 

[Uli-Stefan]

Bei meiner Konstellation kann ich diese Vorgehensweise so nicht vornehmen. Dlibarr & ILIAS laufen nicht als Anwendungen über das Paketzentrum.
Im Verzeichnis /.../web_packages/
befindet sich bei mir nur das Unterverzeichnis /.../web_packages/phpadmin
Vielleicht kann man hier was ähnliches hinbekommen.

 

[Ulfhednir]

web_packages ist ja auch genau für die Pakete aus dem Paketzentrum. Eigene Installationen gehören nach /web.
Das war tatsächlich auch eine Neuerung von DSM 7.

 

[Styler]

Bei meiner Konstellation kann ich diese Vorgehensweise so nicht vornehmen. Dlibarr & ILIAS laufen nicht als Anwendungen über das Paketzentrum.
Im Verzeichnis /.../web_packages/
befindet sich bei mir nur das Unterverzeichnis /.../web_packages/phpadmin
Vielleicht kann man hier was ähnliches hinbekommen.

Genau, deshalb habe ich vtigerCRM installiert, und es als "Hülle" für die neue Anwendung genommen.

 

[Styler]

web_packages ist ja auch genau für die Pakete aus dem Paketzentrum. Eigene Installationen gehören nach /web.
Das war tatsächlich auch eine Neuerung von DSM 7.

Dort läuft aber nichts.

 

[Uli-Stefan]

O.K. Diesen Trick werde ich mal ausprobieren. Also praktisch die andere Anwendung drüberbügeln. Mal sehn ob das klappt.

 

[Styler]

Nur den Inhalt des Verzeichnisses löschen und dann, wenn die neue Software dort abgelegt ist, die Rechte auf vtigerCRM setzen.

 

[Ulfhednir]

@Styler das ist dann aber auch nur ein schmutziger Workaround. Ich habe jetzt mal zwischenzeitlich probiert OSSN einzurichten. Meine Webstation hatte Nginx als Backend. Beim Apache 2.4 erhalte ich auch eine 500er Meldung. Ursache ist eine .htaccess, welche veraltete Befehle verwendet, die unter Apache 2.4 nicht mehr unterstützt werden.

/var/services/web/ossn/.htaccess: Invalid command 'order', perhaps misspelled or defined by a module not included in the server configuration

Apache 2.2
Order allow,deny Allow from all

>>

Apache 2.4
Require all granted


Im Kern also eher ein Kompatibilitätsproblem. Ich könnte jetzt mal mutmaßen, dass das bei dir auch zutreffen könnte.
Schau mal hier, ob du etwas verdächtiges auffinden kannst:
/volume1/@appdata/Apache2.4/log

 

[Styler]

Die .htaccess, die von der schmutzig funktionierenden Anwendung nun in /web_packages/vtigercrm erstellt wurde, sieht so ganz anders aus:

# BEGIN 1CRM RESTRICTIONS - DO NOT EDIT
RedirectMatch 404 ^/vtigercrm/(.*)\.log(\.[0-9]+)?$
RedirectMatch 404 ^/vtigercrm/data/(.*)$
RedirectMatch 404 ^/vtigercrm/examples/(.*)$
RedirectMatch 404 ^/vtigercrm/include/(.*)\.php$
RedirectMatch 404 ^/vtigercrm/modules/(.*)\.php$
RedirectMatch 404 ^/vtigercrm/soap/(.*)$
RedirectMatch 404 ^/vtigercrm/themes/(.*)\.php$
RedirectMatch 404 ^/vtigercrm/cache/(.*)\.php$
RedirectMatch 404 ^/vtigercrm/custom/(.*)\.php$
RedirectMatch 404 ^/vtigercrm/files/backups/(.*)$
RedirectMatch 404 ^/vtigercrm/files/spinner.gif$
RedirectMatch 404 ^/vtigercrm/files/email/(.*)$
RedirectMatch 404 ^/vtigercrm/files/reports/(.*)$
RedirectMatch 404 ^/vtigercrm/files/upload/(.*)$
RedirectMatch 404 ^/vtigercrm/files/index.html$
<IfModule pagespeed_module>
  <IfModule mod_env.c>
    SetEnv PAGESPEED 1
  </IfModule>
</IfModule>
<IfModule mod_env.c>
    SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1
</IfModule>
<IfModule !mod_env.c>
    <IfModule mod_rewrite.c>
        RewriteEngine On
        RewriteCond %{HTTP:Authorization} ^(.*)
        RewriteRule .* - [e=HTTP_AUTHORIZATION:%1]
    </IfModule>
</IfModule>
# END 1CRM RESTRICTIONS

Was mir noch aufgefallen ist, die funktionierende "vtigerCRM-Installation" basiert ja auf den Apachen. Da ich vorher immer nur den nginx versucht
hatte, ist vielleicht dort das Problem zu suchen. Auf DSM6 läuft es unter dem nginx ohne Probleme. Er soll ja auch einiges schneller sein, wie auch PHP8.1 .... wenn wir es mal bekommen würden.

In der Anlage die .htaccess der funktionierenden Installation auf DSM6 unter nginx, die aber nicht auf DSM7 im /web funktioniert (Fehler 500).

 

[Holger1974]

Ich habe einen Abschnitt in der.htacces bei OSSN gefunden, der sieht wie folgt aus:

<Files "error_log">
order allow,deny
deny from all
</Files>

<Files ".user.ini">
order allow,deny
deny from all
</Files>

<FilesMatch "(nginx|htaccess).dist">
order allow,deny
deny from all
</FilesMatch>

Muss ich da jetzt was ersetzen? wenn erwünscht, stelle ich morgen mal das ganze Skript als Anhang zur Verfügung.

 

[Styler]

Funkt es denn bei Dir @Holger1974
oder klappt auch nichts? Welches DSM hast Du denn?

 

[Ulfhednir]

Liege schon in der Koje. Du musst nur die order allow,... inkl. deny mit Require all granted ersetzen. Allerdings an allen Stellen.

 

[Styler]

@Ulfhednir , Du hast Recht, .htaccess ist der Trick

Es hat nun auf einer DSM_7.0.1-42218 Neuinstallation in /web schonmal mit der .htaccess der DSM6-nginx-Installation geklappt.
Jetzt muss ich es nur noch auf 7.1.1-42962-4 testen.

Vielen Dank Euch für die Tipps zur Lösung.

 

[Holger1974]

guten Morgen, bin grad aufgewacht..was ja sonst nicht meine Art ist...Benutze DSM 7.1. Habe die Befehle oben in der .htaccess geändert.. nichts nach dem Eingabe von Datenbank, E-Mail etc.. bekomme ich einen weißen Bildschirm, wenn ich auf "Install" klicke. Datenbankname, Benutzer und Mail stimmen.

 

[Holger1974]

Hier mal das geänderte Script.