Problems with Web Interface on the administrative sites: "Apps" and "Users"

michai · January 17, 2019, 8:47am

I want to keep the bottom discussion on, because I had the similar problem with the unwanted automatically logout.

Fortsetzung der Diskussion von Bug with Nextcloud Web Interface: automatically unwanted logout:

After I set the session save path in the php.ini file it seems to works fine. Files were automatically created for the individual settings in the temp folder and I had no unwanted logout and the error at all.

But with these settings I can’t access these sites as administrator over the top menu:
nextcloud/index.php/settings/apps
nextcloud/index.php/settings/users

There is always the error:

“Es ist ein Fehler bei der Anfrage aufgetreten. Es kann nicht fortgefahren werden.”

I think in english:

“An error occurred during the request. It can not be continued.”

No actual content will be loaded after this error. When I claim out the configuration about the session path in the php.ini this error doesn’t exist, but I have the first problem about the logout.

My enviroment:
Shared Hosting by 1&1 IONOS
Nextcloud Version: 15.0.2
PHP Version: 7.2.13
OPcache is enabled with the options in the nextcloud documentation
Memory cache is disabeld

In the Nextcloud logs doesn’t appear any information about that so far.

Does somebody has any idea?

michai · January 17, 2019, 12:19pm

This is the error statement from the firefox developer tools:

Madnax · March 29, 2020, 4:15pm

@michai I am facing the same issue. Have you found any solution / workaround in the meantime?

michai · April 1, 2020, 12:06pm

@Madnax Nope. We are now on Nextcloud 18.0.1 with PHP 7.4.3 but the problems are still the same. If I’ve got important changes or new users I delete the “session.save_path (…)” settings for a short time from the php.ini file. Then I can make the changes in the settings and set the php.ini back.

I am still looking for a complete solution…

Madnax · April 1, 2020, 4:58pm

@michai Thanks a lot for the quick response. I guess
there will be no other solution than setting and unsetting the
session.save_path within the php.ini. Just for interest: are you hosting the
NextCloud instance on managed host like 1and1? Until a solution will we
available, apps and users can be managed via the command line tool ‘occ’ as
well. I guess I will create a GitHub issues in order to priorise this topic. Furthermore
I recommend to update to 18.0.3. Some days ago, an urgent patch (18.0.2) has
been published without any release notes. I have diffed the zip files 18.0.2
and 18.0.3 and I found a huge security risk within the remote wipe functionally…

michai · April 2, 2020, 6:39am

@Madnax Thank You as Well.
Your intention regarding a GitHub issue is great. Let me know the Link to the Case then I will support it as well.
I’ve got an “old” hosting package called " 1&1 Unlimited Plus". So it’s basically shared Webhosting.
Thanks for the note. I will check the update in the next days…

Madnax · May 9, 2020, 3:11pm

@michai nachdem mir der 1und1 Support nicht weiterhelfen konnte, habe ich selbst ziemlich viel mit der PHP-Konfiguration herumgespielt… Wenn ich in meinem NextCloud Ordner innerhalb der php.ini den session.save_path beispielsweise auf /kunden/homepages/4/KUNDEN_NUMMER/htdocs/tmp gesetzt habe, liefert phpinfo() no value zurück. Daher bin ich davon ausgegangen, dass der Standardwert /tmp angezogen wird. Wenn ich via SSH ein ls -lsah /tmp mache liegen im /tmp Ordner allerdings keine PHP Sessions Files. Dort ist mir allerdings der Ordner /tmp/.priv aufgefallen, welcher durch den Root-User geownet wird. Da der /tmp/.priv Ordner durch den Root-User geowned wird konnte ich leider nicht verifizieren, dass dort die PHP Sessions gespeichert werden. Führe ich phpinfo() bzw. die CLI-Version /usr/bin/php7.3-cli -info | grep session.save_path in einem Workspace OHNE php.ini aus, liefert mir der session.save_path den Wert /tmp/.priv! Problem gelöst!

Ich verwende aktuell folgenden php.ini, welche unter anderem die NextCloud Instanz durch einen OPcache beschleunigt:

zend_extension=opcache.so;
opcache.enable=1
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=10000
opcache.memory_consumption=128
opcache.save_comments=1
opcache.revalidate_freq=1
opcache.file_cache=/kunden/homepages/4/KUNDEN_NUMMER/htdocs/.opcache;
opcache.file_cache_only=1;
memory_limit=512M;
session.save_path = /tmp/.priv

Ich hoffe, dass session.save_path = /tmp/.priv auch deine Probleme löst!

michai · May 26, 2020, 11:00am

Hallo @Madnax,
du bist brilliant. Vielen, vielen Dank - das hat bei mir ebenfalls hervorragend geholfen.

Sorry, für die etwas späte Antwort. In den letzten Tagen war viel los. Ich habe die Lösung aber bereits vor einer Woche zwischen Tür und Angel in der php.ini hinterlegt und nun eine Woche äußerst positiv getestet.

Bei weiteren Themen sollten wir in Kontakt bleiben.

michai · June 15, 2020, 8:10am

Hey @Madnax,
nachdem ich nun seit einigen Wochen deine php.ini ausprobiere fallen mir noch kleinere Unstimmigkeiten auf. Es kommt des öfteren vor, das oben rechts die Meldung “Verbindung zum Server verloren” erscheint oder ich einfach komplett abgemeldet werde.
Kannst du ähnliche Phänomene bestätigen?

Madnax · June 16, 2020, 8:09am

Hallo @michai,

ja, ich hatte selbiges Problem und ich habe tatsächlich eine Lösung gefunden, welche ich gestern implementiert und auf drei bei IONOS betriebenen NextCloud Instanzen erfolgreich getestet habe. Resultat: keine nachvollziehbaren Logouts und keine Problem loading page, reloading in X seconds Meldungen mehr.

Der sessions.save_path=/tmp/.priv war schon sehr nah dran. Leider habe ich festgestellt, dass IONOS die PHP Session Garbage Collection deaktiviert hat (session.gc_probability=0) und diese höchstwahrscheinlich über ein Cronjob oder ähnliches durchführt. Hierbei habe ich die Vermutung, dass ab und zu aktive PHP Sessions gelöscht werden, welche nicht gelöscht werden sollten…

Also benötigen wir doch ein NextCloud spezifischen Ordner für die PHP Sessions:
session.save_path = /kunden/homepages/SERVER_NUMMER/KUNDEN_NUMMER/htdocs/.phpsessions.

Dank dem 1und1 Setup Beitrag habe ich festgestellt, dass eine php.ini Datei im Root Verzeichnis der NextCloud nicht ausreicht. Die php.ini Datei, beziehungsweise ein symbolischer Link dazu muss in jedem NextCloud Ordner liegen, in welchem mindestens eine *.php Datei liegt.

Hierfür habe ich ein ähnliches Setup wie @berho:

Erstelle den .opcache und .phpsessions Ordner im /kunden/homepages/SERVER_NUMMER/KUNDEN_NUMMER/htdocs/ Home Directory:
```
mkdir .opcache
mkdir .phpsessions
```

Erstelle eine php.ini Datei im /kunden/homepages/SERVER_NUMMER/KUNDEN_NUMMER/htdocs/ Home Directory:

cat << EOF > /kunden/homepages/SERVER_NUMMER/KUNDEN_NUMMER/htdocs/php.ini
memory_limit=512M
zend_extension=opcache.so
opcache.enable=1
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=10000
opcache.memory_consumption=128
opcache.save_comments=1
opcache.revalidate_freq=1
opcache.file_cache=/kunden/homepages/SERVER_NUMMER/KUNDEN_NUMMER/htdocs/.opcache
opcache.file_cache_only=1
session.save_path =/kunden/homepages/SERVER_NUMMER/KUNDEN_NUMMER/htdocs/.phpsessions
EOF

Erstelle in jedem NextCloud Ordner, welcher mindestens eine *.php Datei enthält einen symbolischen Link auf die php.ini Datei im Home Directory:
```
 cd nextcloud
 find . -type f -name '*.php' -printf '%h\n' -execdir ln -s ~/php.ini $(dirname "{}")/php.ini \;
```
Einziger Haken besteht darin, dass vor jedem NextCloud Update die symbolischen Links wie folgt gelöscht werden müssen:
```
 cd nextcloud
 find -name "php.ini" -type l -exec rm {} \;
```

@berho Vielen Dank für deinen 1und1 Setup Beitrag, welcher erheblich zur Lösung unseres Problems beigetragen hat!