d00p

Please use GitHub for bug reports, provide as much details as possible as well as log files and exact steps to reproduce.

Also, you might want to check the migration-guides, depending on from which version of froxlor you are upgrading: https://docs.froxlor.org/latest/general/migration-guide/

you can safely run the full-upgrade and re-configure your services (beware of you customizations!) with "froxlor-cli config-services -c" and it should all be good

That is because these are let's encrypt certificates, just disable let's encrypt in the domain to remove it

Wenn das ein debian ist und du das via apt installiert hast sind die sachen vermutlich nur via alias verfügbar, je nachdem wie das paket das macht. Das kann funktionieren, aber bei einem standard froxlor setup mit php-fpm z.B. wird das so nicht funktionieren (berechtigungen u.A.). Entweder manuell installieren, z.B. für einen dafür angelegten Kunden mit eigener (Sub-)domain oder in /var/www/html/froxlor packen und via froxlor domain drauf zugreifen. "Kompliziertere" Variante wär dann die config des Aliases (sofern vorhanden, kenne jetzt die zwei pakete nicht adhoc) entsprechend z.B. mit dem php-fpm socket von froxlor zu bestücken und berechtigungen anzupassen, ist aber dann ggfls nich update-sicher

Löst die domain denn korrekt auf die im vhost gezeigten IP adressen auf? Es hat sich nix "bahnbrechendes" geändert wie der webserver funktioniert... Na wirst du wirklich UMGELEITET (http redirect) oder landet die domain in einem anderen docroot? großer unterschied

Okay, was wars denn jetzt?

mach mal ein nginx restart (nicht reload). Das sieht doch eigentlich alles okay aus. Ansonsten komm uns doch bitte im Discord besuchen, da ist der austausch etwas zügiger und wir können uns das mal anschauen

dann schau doch mal bitte wie die einträge in der ftp_groups tabelle aussehen bevor wir hier ewig rumsuchen

na lief denn der cronjob auch schon? Zur not mal forcieren (damit er die extrausers neu schreibt): `bin/froxlor-cli froxlor:cron -fd`

um gottes willen, mach doch so sachen nicht.... Froxlor macht das was in den Einstellungen steht, schau doch in deinen webserver settings mal nach was du da als Webserver user-name/group-name angegeben hast, das sollte www-data sein und dann prüfe in den froxlor vhost settings das für "Local user to use for PHP-FPM (Froxlor vHost)" (und natürlich auch gruppe) dein "froxlorlocal" user angegeben ist (wenn der so heisst)

nicht manuell an permissions rumspielen... Läuft der nginx dienst denn auch unter "www-data"? da fehlt der www-data, das trägt froxlor eigentlich in die ftp_groups tabelle ein für jeden user

Do you by any chance have nscd (still) installed from a previous libnss-mysql configuration or similar? if yes, remove it and restart apache. The permissions and users seem fine

so does the .htaccess belong to web33 and does it have at least 0640 ?

seems to look fine. Whats the exact error message from your opening post you are receiving from apache?

And the output of `id www-data`? You can adjust the webserver user in froxlor -> Settings -> Webserver settings -> Webserver user-name / group-name, validate that it's correct

froxlor usually adds the virtual users to the group. You can validate by entering the command `id www-data` and see if the group `web33` is in there. Also please provide information about how you integrate php (mod_php, fcgid or fpm) and whether you have libnss-extrausers in use (which you should)

Ich sehe gerade, dass betrifft wohl aktuell nur die bookworm config-templates - hier wollten wir eine 99-froxlor.conf erstellen statt alle files einzeln anzupassen wie bei den anderen...wie sich herausstellt ist dann natürlich PAM authentifizierung aktiviert (default, wie du sagst). Es gibt leider keine Direktive die uns erlaubt das in der 99-froxlor.conf wieder zu deaktivieren. Das sollte aber fixbar sein. So ist das was du jetzt gemacht hast auch exakt das, was wir schon die ganze zeit machen und in bookworm ist es nicht korrekt.

Wir orientieren uns eigentlich immer an den distributions-defaults von den diensten um so wenige änderungen wie möglich zu haben. Ich gebe dir allerdings recht, ich denke auch nicht das da jemand groß pam-auth nutzen dürfte

Die aktuelle implementierung ist sehr alt und funktioniert auch nur wenn du einen eigenen nameserver betreibst und einen (sehr alten) dkim-filter. Wir überarbeiten das aktuell komplett für die Version 2.2 mittels rspamd (auch ohne eigenen nameserver, einträge müssen natürlich dennoch gemacht werden). Ich kann dir leider kein genaues Release-Datum für 2.2 geben, wir peilen Sommer 2024 an. Orientieren wird sich die Lösung grob an diesem Beitrag: - vllt hilft es dir ja schon jetzt - aber keine Garantie für user-contributed code

Als admin die domain bearbeiten, dort gibt es ein flag: "Bearbeiten der Domain erlauben"

Wenn du als admin den Kunden bearbeitest kannst du ihm recht weit unten im formular alle php-configs zuweisen die er nutzen darf (diese kann er dann eigenständig pro domain wählen, sofern das bearbeiten der domain erlaubt ist)

mal cache/cookies im browser geleert?

Oder halt einfach goaccess aus deren offiziellem repo nutzen: https://goaccess.io/download#official-repo

ubuntu bugreport? für was? Bisschen mehr kontext vllt?