mgutt

Moderators
  • Posts

    5540
  • Joined

  • Last visited

  • Days Won

    50

Everything posted by mgutt

  1. Gibt es sonst nichts. Nur der Nachfolger (W480M) wäre noch eine Option. Bei Bedarf kann ich noch mal 10 Boards nachfordern, das würde ich aber nur noch in Form einer Sammelbestellung machen und 5 Leute müssten schon zusammen kommen.
  2. Mich wundert, dass die das bei Amazon immer noch nicht im Griff haben. Da regen sich die Kunden ja schließlich schon seit vielen Jahren drüber auf. Und so schwer ist das ja nicht, die Platten zb erst in einen Karton und den Karton in noch einen Karton zu stecken (wenn man jetzt nicht unbedingt HDD Transporthüllen anschaffen will). Mit genug Füllung wäre das jedenfalls immer noch 10x besser, als das was die jetzt machen.
  3. Da ich keine Parity im Einsatz habe, kann ich dazu keine nützliche Antwort geben. Erst bei einem Parity Check hätte man ja eine Vollauslastung. Sollte aber denke ich gehen, wenn man vorne zwei kleine und nicht einen großen Lüfter montiert.
  4. I'm confused. If this is the complete same behavior if you access the container through your domain (NPM container) or the local IP (YouTube container), what do you expect to happen through your domain instead?
  5. This should be the reason. Do not forget. Every traffic that is forwarded through a proxy, is coming from a local ip without any hostname (domain). This means nextcloud sees only one "visitor" with the IP of NPM, although thousands of visitors could open the domain while reaching NPM (the proxy). Because of that Nextcloud allows changing several settings: https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/reverse_proxy_configuration.html The very first setting would be to add the IP of NPM as a trusted proxy. Then repeat the curl command to verify, that you are able to reach Nextcloud. Please use "curl --insecure https://<nextcloud-ip:port>". By that curl does not validate the certificate if the nextcloud container. This is important as linuxserver's container includes only a local / private certificate which can't be verified. Alternatively you could use the original Nextcloud container, which is maintained in unRAID through Knex666. Add a new port like 80:8666 to use it in bridge mode and add use http in NPM as you've done with the WordPress container and it will work out of the box. But note: it needs an external database container like mariadb.
  6. Ok. Then back to these tests. The first test fails because the WordPress container itself has no valid ssl certificate or does not even support https. As I did not found any information regarding https, ssl or 443 on the docs, I think it supports only http: https://hub.docker.com/_/wordpress This means you must use http to reach this container through NPM. Now repeat curl <wordpress-ip:port> What is the result? In your last post there was no result?!
  7. Don't need to. Instead you create a new cnf file: https://forums.unraid.net/topic/110019-support-mariadb-official/?do=findComment&comment=1024598 Note this post: https://forums.unraid.net/topic/110019-support-mariadb-official/?do=findComment&comment=1039530
  8. Please open an issue. This not related to something which I'm able to fix.
  9. Dh wenn man das beim Container einstellt wird es 777 und wenn man den Server neu startet, dann 755? Dann müsste das auch passieren, wenn man den Container stoppt, den Unterordner löscht und ihn wieder startet. Das wäre dann quasi ein Bug in Docker oder unRAID. Also wer auch immer den Ordner erstellt.
  10. I don't know if it's active by default, but try to disable binary logging: https://geekflare.com/disable-binary-log-mariadb/ Regarding my research it can help to solve this issue. Other people solved it by re-installing. Maybe you try to export the database, reinstall and import the database ?!
  11. Please temporarily allow local connections to be able to debug the problem.
  12. What happens if you open this in your browser? Did you try a port above 1024? Everything smaller is usually used by a different service: https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers#Well-known_ports
  13. Nach einem Neustart ist der Ordner /tmp leer und Unterordner werden vom Container/Docker neu erstellt. Also egal ob Crash oder nicht, die Ordner müssten dann ja immer nach einem Neustart die falschen Rechte haben?!
  14. Why are you testing both? Every container has a documentation (should have). As an example the original Nextcloud container supports only http: https://hub.docker.com/_/nextcloud "This setup provides no ssl encryption and is intended to run behind a proxy." While linuxserver's version supports only https: https://hub.docker.com/r/linuxserver/nextcloud "Parameter Function -p 443 WebUI" Another method would be to check which internal port is used by the container. 80 is http and 443 is https. So step by step. 192.168.1.101:8083 is nextcloud? Does 8083 forward to 443 or 80? Open the container config, edit this port and check the internal port. And of course tell me the repository name of the container. I was talking about the error "ACE; could not convert string to UTF-8" returned by curl. Your typed in IP address contained wrong chars. You forget "curl"
  15. Ich hatte das auch gerade wegen atop. Allerdings hat der Holzhammer nicht geholfen bzw war falsch. Denn ich habe einfach das gemacht: rm /var/log/atop/* Danach habe ich atop aus dem Nerd-Pack gelöscht und trotzdem zeigte er mir im Dashboard fast 100% volle Logs an. Daraufhin habe ich das untersucht und festgestellt, dass ich wohl atop aufgehangen habe, in dem ich einfach die Dateien gelöscht habe, während es noch lief. Erst als ich den Prozess gekillt habe, wurden der Speicherplatz wirklich erst freigegeben: root@thoth:~# df -h | grep /var/log tmpfs 128M 122M 6.2M 96% /var/log root@thoth:~# find /proc/*/fd -ls | grep deleted 79658297 0 l-wx------ 1 root root 64 Oct 5 19:38 /proc/26741/fd/1 -> /var/log/atop/daily.log\ (deleted) 79658298 0 l-wx------ 1 root root 64 Oct 5 19:38 /proc/26741/fd/2 -> /var/log/atop/daily.log\ (deleted) 79658300 0 l-wx------ 1 root root 64 Oct 5 19:38 /proc/26741/fd/4 -> /var/log/atop/atop_20210914\ (deleted) root@thoth:~# lsof | grep deleted atop 26741 root txt REG 0,2 206392 7411 /usr/bin/atop (deleted) atop 26741 root 1w REG 0,35 0 44 /var/log/atop/daily.log (deleted) atop 26741 root 2w REG 0,35 0 44 /var/log/atop/daily.log (deleted) atop 26741 root 4w REG 0,35 116779649 71 /var/log/atop/atop_20210914 (deleted) ^C root@thoth:~# pkill atop root@thoth:~# lsof | grep deleted ^C root@thoth:~# df -h | grep /var/log tmpfs 128M 11M 118M 9% /var/log root@thoth:~#
  16. You don't need to post the complete html source code. It's only for you to verify if "curl" is able to load the website.
  17. This sounds like the IP:Port contains special chars. Are you really using "normal" numbers, dots, slashes and colon? Maybe a copy & paste problem? Please try to type everything manually. Here is an example where the user accidentally used wrong quote chars: https://stackoverflow.com/questions/64841244/curl-put-request-content-type-header-is-not-supported But in your case it seems to be a different char, which is not in the ASCII format.
  18. Does the container only support https? And are you sure it needs 444? Usually the default port for https is 443. But it is kinda inefficient to use https for local traffic. Regarding the error: I was not able to find the reason. Maybe a missing cipher?! Please use "curl -v <IP>" to get more output.
  19. It does. "not found" is an answer of the container. Try a completely different port which is not used by any container and you will see an error instead. What happens if you open http://192.168.0.6:8282/ through your browser?
  20. Welchen Link hast du genau für die Installation verwendet und kann Unraid die Domain erreichen? Öffne das WebTerminal und versuche einen Ping: ping raw.githubusercontent.com Wenn das nicht geht, versuch einen Ping ins Internet, aber auf eine IP: ping 8.8.8.8 Wenn das erste nicht geht, aber das zweite, dann stimmt was nicht mit deinen DNS Einstellungen. Geht beides nicht, dann hat dein Server keinen Internetzugang.
  21. As I said. You have to check if the containers are able to reach each other. Open the console of NPM and execute this for example: curl http://192.168.0.6:8282 With this command you should be able to see the HTML source code of the Unraid Login-page: curl http://192.168.0.6/login
  22. Maybe you have a conflict with a VM, because 6000 is usually used by X11. Try 5000/5001 as I mentioned in my manual.
  23. If a container runs in the host network it uses it's default ports. This is a usual behavior of all containers. Did you accidentally change both ports, internal and external? This is not visible in the screenshot. Only if you edit the entry. Finally it would be interesting to see what it looks like after the container has been started.
  24. Try a different virtio version. Maybe something is wrong with your ISO file.
  25. Are you sure 8282 is correct as in your SWAG code you are using 8080. Did you check if the NPM container is able to reach the YT container (console and using curl)?