saber1

Nur kurz zur Info, wollte nicht extra den Support-Thread spammen: Ich nutze unRaid seit 2019 und der Share für die ISO-Dateien existierte per default. Konkret: isos (< klein geschrieben) Dort abgelegte ISO-Dateien werden ganz normal nach einem Klick auf "ADD ISO FILE SHARE" und dem darauf folgenden Dialog gelistet.

Was ja nicht, nach was Du bisher gesucht hast. Ohne es getestet zu haben, findet sich z.B. auf Reddit ein Thread dazu:

I know it's an old thread. But if you're using Firefox you can do that: about:config > image.animation_mode http://kb.mozillazine.org/Animated_images

Das "alte" Thema. USB 3.X nicht wirklich empfohlen für UnRaid. Warum soll es unbedingt ein 3.X-Stick sein?

@warp760 Du brauchst das PlugIn User Scripts. Im PlugIn dann einen neuen Job anlegen. Rsync How to: https://www.atlantic.net/vps-hosting/how-to-use-rsync-copy-sync-files-servers/

Ich hatte das auch vor ein paar Monaten. Zwei, drei Container waren angeblich "nicht verfügbar". Habe dann von der Basic in die Advanced view umgeschaltet und ein "force update" gemacht. Dann waren sie wieder "verfügbar". Was genau das Problem war, kann ich nicht sagen. Bisher nicht wieder aufgetreten...

Das Problem hatte ich auch. Wenn Nextcloud von Linuxserver verwendet wird, muss im NPM als Scheme https eingestellt sein. In diesem Post ist auch ein Video dazu verlinkt:

Das ist ein Argument.

Weil ich möchte, das beim Aufruf der Seite noch nicht ersichtlich ist, was den User erwartet. Danke Dir. Leider ja schon recht lange geöffnet dieser Bug. Aber gut, dann besteht ja Hoffnung. 😉

Eine weitere Frage habe ich zu den Access Lists im Nginx Proxy Manager. Neben Nextcloud habe ich noch eine weitere Subdomain für BookStack (Wiki) angelegt. Mittels einer Access List ist es ja möglich eine User/Passwort Abfrage vor dem eigentlichen Erreichen der Oberfläche zu schalten. Dies funktioniert wohl mittels htaccess, nehme ich an? Jedenfalls klappt das für BookStack auch einwandfrei. Leider aber nicht für Nextcloud. Es scheint, als ob die Access List einfach ignoriert wird. Muss dafür eventuell auch noch etwas in der config.php von NC konfiguriert werden?

Welche IP trägt man denn hier ein? NPM läuft im Bridge-Mode. Also nur die unraid-IP wird wohl nicht reichen. Welcher Port soll es noch sein? 80? 443?

Das ist seine Signatur. 😉

Ich kann Erfolg vermelden: Ich hatte mir auch noch Dein Video zu dem Thema angesehen. Habe im NPM einen neuen Host angelegt. Und das Entscheidende war, das https beim Scheme gewählt werden muss. Da ich doch wieder den Linuxserver Container nutze.

Okay. Also die IP vom NPM eintragen. So sagt es ja auch die Nextcloud Doku... 🙈 Heute Nachmittag kann ich mich dem wieder widmen... Oben mein Screenshot vom NPM "Edit Proxy Host". In dem von mir geschwärzten Feld ist meine subdomain.domain.com eingetragen. Es gib für HSTS dann aber ja zwei Optionen. Eben auch extra eine für Subdomains. Oder wird es so sein, wenn im Feld bereits eine Subdomain eingetragen wurde, muss halt die Option HSTS Subdomains nicht noch extra aktiviert sein?

So sieht die config.php aus: <?php $CONFIG = array ( 'memcache.local' => '\\OC\\Memcache\\APCu', 'datadirectory' => '/data', 'instanceid' => 'xxxxxxxxxx’, 'passwordsalt' => 'XXXXXXXXXXXXX', 'secret' => 'XXXXXXXXXXX', 'trusted_domains' => array ( 0 => '10.0.1.7:444', 1 => 'nextcloud.domain.com', ), 'trusted_proxies' => array ( 0 => 'nginx', ), 'dbtype' => 'mysql', 'version' => '25.0.1.1', 'overwrite.cli.url' => 'https://nextcloud.domain.com/', 'overwritehost' => 'nextcloud.domain.com', 'overwriteprotocol' => 'https', 'dbname' => 'nextcloud_db', 'dbhost' => '10.0.1.7:3307', 'dbport' => '', 'dbtableprefix' => 'oc_', 'mysql.utf8mb4' => true, 'dbuser' => 'xxxxxx', 'dbpassword' => 'XXXXXXXX', 'installed' => true, 'mail_smtpmode' => 'smtp', 'mail_smtpsecure' => 'ssl', 'mail_sendmailmode' => 'smtp', 'mail_from_address' => 'xxxxxxxx', 'mail_domain' => 'nextcloud.domain.com', 'mail_smtpauthtype' => 'LOGIN', 'mail_smtpauth' => 1, 'mail_smtphost' => 'smtp.domain.com', 'mail_smtpport' => '465', 'mail_smtpname' => '[email protected]', 'mail_smtppassword' => 'XXXXXXXXXXX', 'default_phone_region' => 'DE', ); Wie genau prüfe ich, ob der Header "da" ist? Hatte einfach mit einem Header Checker online geprüft. Welche Domain gibt man eigentlich im SSL-Certificate Feld an? Die Domain? domain.com Oder die Subdomain? nextcloud.domain.com Weil es ja auch eine Option HSTS Subdomains gibt...

Scheint übernommen worden zu sein: Zur Sicherheit nochmal die SSL-Einstellungen im NPM. HSTS nicht aktiviert, wegen eventuellem überschreiben der Advanced Regel. Aber auch bei hier aktiviertem HSTS bleibt die Warnung:

Dann wird zwar der Header gesetzt, aber die Warnung bleibt. Irgendwas noch nicht ganz korrekt in der config.php von NC?

Wird er nicht.

Ja, hatte ich. Auch nach dem Deaktivieren dieser Option und einem Neustart (NPM & Nextcloud) bleibt die Warnung leider.

Läuft alles wunderbar jetzt. Gerne würde ich nun noch die einzige verbliebene Warnung wegbekommen: Habe wie im Thread NEXTCLOUD SICHERHEITS- & EINRICHTUNGSWARNUNGEN BEHEBEN von @Anym001 die entsprechenden Zeilen im Nginx Proxy Manager eingetragen: Leider bleibt die Warnung bestehen. Irgendeine Idee?

Ich schätze, das mir das, wenn ich Nextcloud schon länger nutzen würde, auch aufgefallen wäre. Da ich aber nun mit Version 25 einsteigen wollte, ist es schon etwas unglücklich. Sollten man die Jungs und Mädels vom NC-Team darauf aufmerksam machen?

Das werde ich jetzt auch erstmal so halten. Danke an Alle für Eure Unterstützung. 🤗

@mgutt Tatsache. Da Du es auf einem Testserver installiert hattest, habe ich es ebenfalls jetzt mal auf meinem Backup-Server probiert. 25er Version. Alles auf default. Dann Deinen letzten Post gelesen. Bin am Mac > Safari Ist für seine "Sicherheits"-Features bekannt. Also mal direkt jetzt mit Firefox probiert: 😁

Nein File Manager ist installiert. Lösche immer alle Pfade per CLI rm -r Echt wahnsinn. Habe eben erneut die 25er Version installiert. Diesmal ebenfalls alles so gelassen. Also user usw... SQLite Freeze beim Anlegen eines Benutzers

So ist es. Wegen den 4 TB: Der obere ist der vom Container erstellte. Die anderen beiden sind bestehende Shares. @Archonw Ja, hatte ich ja. user zu cache dürfte nicht das Verhalten erklären.