mgutt

From outside like mobile connection If yes: Check your logs.

Kann es sein, dass er gar nicht ssh, sondern den rsync daemon ansprechen möchte? Also ist rsync;// wirklich richtig? Dein rsync server spricht aktuell nur ssh.

In deinem Screenshot ist der Port in einem separaten Feld oder passt sich dieser String dadurch an? Ansonsten würde ich erstmal über die Kommandozeile von OMV probieren. Also: ssh -p 5533 root@tower Wobei Host key denke ich der Fingerprint ist. Soll heißen OMV kennt "Tower" bereits, aber mit einem anderen Fingerprint. Erlaubt OMV nicht das akzeptieren eines neuen Fingerprint?!

Keine Ahnung warum ich da nicht schon vorher drauf gekommen bin: - M920x - PCIe Adapter - M.2 Adapter - M.2 ASM1166 - 5V irgendwo abgreifen Ergebnis: 7x SATA 3x M.2 Mein erster Versuch erfolgte über die USB Buchse: Eigentlich ist die USB Buchse dafür gar nicht geeignet, da deren Limit eigentlich 0.9A sind und die SATA SSD laut Typenschild bis zu 1.5A ziehen kann, aber hey, sie lebt noch ^^ Ich habe auch schon ein bisschen gemessen und auf dem Board gibt es diese Buchse: Das dort genannte Stromkabel 01YW371 konnte ich in einem Shop für knapp 20 € finden (war leider nur eins auf Lager). Man bekommt es auch manchmal im Set mit der Sunnix Serial RS-232 SER6456LV Karte: https://www.ebay.com/itm/325747510407 Die Idee wäre es die zwei 5V Adern dieses Kabels auf Molex zu adaptieren und da dann 6x SATA SSDs dran zu packen. Das wären dann allerdings bis zu 60W. Eventuell sollte man also noch eine Stelle suchen, wo man 5V abgreifen kann. Jedenfalls erreicht das Setup (2x SATA SSD, 2x 16GB RAM) aktuell C7 und verbraucht 7.3W. Kein Bestwert verglichen mit anderen ITX/mATX Boards, aber doch schon ein guter Verbrauch.

Did you enable caching for this host? Another reason could be proxy_request_buffering, which is by default on: https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_request_buffering That's why I'm using this advanced setting for my nextcloud (which even solved timeouts while moving huge files and timeouts while uploading huge files): location / { add_header Strict-Transport-Security "max-age=15552000; includeSubdomains; preload;"; client_body_buffer_size 512k; client_max_body_size 32G; proxy_request_buffering off; proxy_read_timeout 600s; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection $http_connection; proxy_http_version 1.1; # Proxy! include conf.d/include/proxy.conf; }

It's not an error. Only a warning. I don't know why this message is returned recently. It is only confusing for the user. It has nothing to do with Debian containers. It's returned if the container uses the setting "--memory xGB" (which limits the ram usage if the container = warning it could be cause crashing the container as no swap exists = which is perfectly ok I think as the container should crash if it is going crazy in RAM usage).

Only after update? Any other containers or unRAID itself listening to Port 80? Check output of: ss -tulpn | grep ":80"

Nothing can write to swap except the Linux Kernel which calculates how important the used memory is and then moves really rare used blocks to the swap partition. This article is "pro" swap (which I'm not as an unRAID server usually has more than enough ram installed or do you have 4GB installed?), but describes how it works: https://chrisdown.name/2018/01/02/in-defence-of-swap.html PS: I tested swap under Unraid in the past and it is rarely/not used. In contrast all files written to /dev/shm are alreadx written to the ram as this is by default in Linux a ram disk (tmpfs = ram): tmpfs 32G 0 32G 0% /dev/shm As you can see my unraid server uses 0% of it after month of uptime. And there is no need to mount /dev/shm to /dev/shm in the container configuration as /dev/shm is by default a RAM disk in ALL containers: https://docs.docker.com/engine/reference/run/ Example: adguard - sh /opt/adguardhome/work # df -h Filesystem Size Used Available Use% Mounted on overlay 3.6T 2.4T 1.3T 65% / tmpfs 64.0M 0 64.0M 0% /dev shm 64.0M 0 64.0M 0% /dev/shm More details about the "shm" filesystem: https://unix.stackexchange.com/a/124788/101920 Regarding the Kingston page: Windows bullshit. Not comparable with Linux. There is no special "support" needed as it replaces a default docker path against a ram disk as explained in my first post: https://forums.unraid.net/topic/136087-ram-disk-for-docker-statuslog-files/#comments Means: It is used by ALL containers. If you want to check if it is running: Check your logs as mentioned in my first post. It depends if limetech changes the files which are manipulated by the script. Sometimes yes, sometimes not. If not: it returns an error message in the logs. If you like to receive notifications in this case I can recommend this script:

Did you paste it maybe twice or similar? So it changes the file and then it tries to do it again which causes the error message?

My script moves files which are NOT in /dev/shm and/or in the swap partition, into a ram disk. All of them are doing completely different things. You COULD in addition use shm-size for your containers, but I think 99% of the containers won't benefit, as I never faced a container, which permanently writes to /dev/shm. Does anyone know some? And you should NOT think about a swap partition if you have enough ram. The main reason for a swap partition is to avoid going out of ram. You won't gain any benefits from a swap disk, instead it produces more wear on your SSD (which is the opposite of the target if this thread).

Open the command line of Plex and compare the paths of a movie media info: to the one you see inside the container. Example: Try with ls -l or stat "/path/to/movie.mkv" To obtain file details: So you can be sure the movie file is accessible through the container.

Open the movie library view and use the not assigned filter. Are they maybe found, but not assigned? Or try to rename one of the movie folders to ".movie name" and back to "movie name". Does Plex then find the movie?

Disconnect all Ethernet ports and test with a display. Test even with Ubuntu and without any USB devices.

Which one?

Your database file is corrupt. Repair it or restore a backup.

Naja, du kannst ja jederzeit das Skript von Hand starten. Also warum bis 3 Uhr warten?!

Da das Skript einfach nur die Container stoppt und nach dem Erstellen der Kopie von appdata startet, kann ich da gedanklich keinen Zusammenhang herstellen. Hier das Kommando, was nichts anderes ist, als wenn du im Menü dir Container alle stoppst: echo "Stop containers:" docker container stop "${container_ids[@]}" Ich denke du solltest mal die Logs von Nextcloud prüfen. Dass der Server überlastet ist, dürfte auch kaum der Fall sein. Wo hast du das ermittelt? Im Dashboard? Das zeigt nicht die echte CPU Last an. Nimm stattdessen das Kommando htop im Terminal. Wobei es schon deswegen nicht sein kann, weil rsync nur einen CPU Kern nutzen kann.

Bitte im Terminal das ausführen: find /mnt/user/isos -ls Ergebnis?

Yes. Read this post:

I found a new container which permanently wrote to my SSD:

@binhex Could you please add this path to the default config to reduce wear on the SSD: Sab is permanently writing to these files: root@thoth:~# find /tmp/sabnzbd/ /tmp/sabnzbd/ /tmp/sabnzbd/tmp /tmp/sabnzbd/tmp/vpngatewayip /tmp/sabnzbd/tmp/vpnip /tmp/sabnzbd/tmp/getiptables /tmp/sabnzbd/tmp/watchdog-script-stderr---supervisor-jgbmg455.log /tmp/sabnzbd/tmp/watchdog-script-stdout---supervisor-dva2j1vt.log /tmp/sabnzbd/tmp/start-script-stderr---supervisor-5i8155s4.log /tmp/sabnzbd/tmp/start-script-stdout---supervisor-whva770j.log /tmp/sabnzbd/tmp/endpoints And by using /tmp this are written to unRAID's RAM disk.

This won't interfere, but you already avoid writing several log files. Maybe those are useful for you? Then you can now enable them by removing "--log-driver none" and "--log-driver syslog --log-opt syslog-address=udp://127.0.0.1:541" parts. Even "--no-healthcheck" could be removed as well.

Could you change this in your post to "6.12.8 to 6.12.10"? The link in the first post was updated.

Nur mal als Info: Ich habe eine Samsung 990 Pro 4TB verbaut und jetzt auch die Logs voller AER Fehler. Also Samsung alleine reicht nicht als Empfehlung. Kommt also auch auf das jeweilige Modell an. Nervig 😒 Hier übrigens die Latenz-Tabelle der 990 Pro: Supported Power States St Op Max Active Idle RL RT WL WT Ent_Lat Ex_Lat 0 + 9.39W - - 0 0 0 0 0 0 1 + 9.39W - - 1 1 1 1 0 0 2 + 9.39W - - 2 2 2 2 0 0 3 - 0.0400W - - 3 3 3 3 4200 2700 4 - 0.0050W - - 4 4 4 4 500 21800 Ich versuche es jetzt mal mit der Kernel Option, um dem Einhalt zu gebieten: nvme_core.default_ps_max_latency_us=15000