parazit

Yes, all test that I have done so far were with a disk share. I am using blackmagic disk speed test for the tests. Edit: Sorry, I thought I was using a disk share but it was a user share. So I have did a test by writing and reading directly into the cache drive and the result is way better write: 500mbs read: 800-950mbs

I have swapped the SATA SSDs with 2x M.2 SN770 1TB but the result is still the same, which is very weird. It actually doesn't matter if primary storage of a share is set to cache or not - the speeds are almost equal. Any ideas, what the bottleneck could be?

Well that's weird, but if that's normal, I won't do any more tests, because I want to upgrade the SATA SSDs anyway. I will get 2x SN770 tomorrow and post the results. Would you recommend btrfs or zfs for a cache pool? Here is the screenshot of a 1gb file.

thank you for your answer. Yes, the speeds look good but I still think there is something wrong. Before I changed hardware the speeds were better. When I was testing the speed using blackmagic disk speed test, I go following results. Old hardware: write 500-550mbs / read 600-650mbs New hardware: write 300mbs / read 600mbs

Hi, I did the iperf test and these are the results. Also what I see is that are writes and reads every 5-10 seconds to the cache disk. Is that a normal behaviour?

Hello Unraid-Community! I have recently upgraded my motherboard, CPU and RAM and I have noticed that the cache write speed over 10 GbE is slower than it used to be. Old hardware: write 500-550mbs / read 600-650mbs New hardware: write 300mbs / read 600mbs I have tried to find a solution, but no luck so far. Really appreciate if anyone could look into my diagnostics, to help me find a solution. unraid-diagnostics-20241102-0108.zip

yes i do. I checked them and they are still the same.

Hello everybody! My Unraid NAS was working without any problems until yesterday and suddenly, i couldn't reach my docker containers through the internet anymore. It looks like everything is working - docker containers are up and running, i can reach my files but only through my home network, not through the internet. Unfortunately find a solution to this problem and wanted to ask in the forum. Does anybody know, what could be the problem? Unraid version: 6.11.5 (edit: updated to 6.12.3 - problem persists) Jul 20 22:23:21 Unraid kernel: docker0: port 4(veth4b51b07) entered forwarding state Jul 20 22:23:21 Unraid avahi-daemon[7805]: Joining mDNS multicast group on interface br-02641c16abe3.IPv6 with address fe80::42:c8ff:fe9b:27e. Jul 20 22:23:21 Unraid avahi-daemon[7805]: New relevant interface br-02641c16abe3.IPv6 for mDNS. Jul 20 22:23:21 Unraid avahi-daemon[7805]: Registering new address record for fe80::42:c8ff:fe9b:27e on br-02641c16abe3.*. Jul 20 22:23:21 Unraid avahi-daemon[7805]: Joining mDNS multicast group on interface vethe2cd57e.IPv6 with address fe80::d4e2:c2ff:fe00:7fd4. Jul 20 22:23:21 Unraid avahi-daemon[7805]: New relevant interface vethe2cd57e.IPv6 for mDNS. Jul 20 22:23:21 Unraid avahi-daemon[7805]: Registering new address record for fe80::d4e2:c2ff:fe00:7fd4 on vethe2cd57e.*. Jul 20 22:23:21 Unraid rc.docker: mariadb: started succesfully! Jul 20 22:23:21 Unraid kernel: docker0: port 5(vethc21bcf6) entered blocking state Jul 20 22:23:21 Unraid kernel: docker0: port 5(vethc21bcf6) entered disabled state Jul 20 22:23:21 Unraid kernel: device vethc21bcf6 entered promiscuous mode Jul 20 22:23:21 Unraid kernel: docker0: port 5(vethc21bcf6) entered blocking state Jul 20 22:23:21 Unraid kernel: docker0: port 5(vethc21bcf6) entered forwarding state Jul 20 22:23:22 Unraid kernel: docker0: port 5(vethc21bcf6) entered disabled state Jul 20 22:23:22 Unraid kernel: eth0: renamed from veth38e0a0e Jul 20 22:23:22 Unraid kernel: IPv6: ADDRCONF(NETDEV_CHANGE): vethc21bcf6: link becomes ready Jul 20 22:23:22 Unraid kernel: docker0: port 5(vethc21bcf6) entered blocking state Jul 20 22:23:22 Unraid kernel: docker0: port 5(vethc21bcf6) entered forwarding state Jul 20 22:23:22 Unraid rc.docker: Redis: started succesfully! Jul 20 22:23:22 Unraid kernel: br-02641c16abe3: port 2(veth3b5b586) entered blocking state Jul 20 22:23:22 Unraid kernel: br-02641c16abe3: port 2(veth3b5b586) entered disabled state Jul 20 22:23:22 Unraid kernel: device veth3b5b586 entered promiscuous mode Jul 20 22:23:22 Unraid kernel: br-02641c16abe3: port 2(veth3b5b586) entered blocking state Jul 20 22:23:22 Unraid kernel: br-02641c16abe3: port 2(veth3b5b586) entered forwarding state Jul 20 22:23:22 Unraid avahi-daemon[7805]: Joining mDNS multicast group on interface veth4b51b07.IPv6 with address fe80::7849:bff:fe55:cf65. Jul 20 22:23:22 Unraid avahi-daemon[7805]: New relevant interface veth4b51b07.IPv6 for mDNS. Jul 20 22:23:22 Unraid avahi-daemon[7805]: Registering new address record for fe80::7849:bff:fe55:cf65 on veth4b51b07.*. Jul 20 22:23:23 Unraid kernel: br-02641c16abe3: port 2(veth3b5b586) entered disabled state Jul 20 22:23:23 Unraid kernel: eth0: renamed from veth2b1e54e Jul 20 22:23:23 Unraid kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth3b5b586: link becomes ready Jul 20 22:23:23 Unraid kernel: br-02641c16abe3: port 2(veth3b5b586) entered blocking state Jul 20 22:23:23 Unraid kernel: br-02641c16abe3: port 2(veth3b5b586) entered forwarding state Jul 20 22:23:23 Unraid rc.docker: nextcloud: started succesfully! Jul 20 22:23:23 Unraid kernel: br-02641c16abe3: port 3(vethced977a) entered blocking state Jul 20 22:23:23 Unraid kernel: br-02641c16abe3: port 3(vethced977a) entered disabled state Jul 20 22:23:23 Unraid kernel: device vethced977a entered promiscuous mode Jul 20 22:23:23 Unraid kernel: br-02641c16abe3: port 3(vethced977a) entered blocking state Jul 20 22:23:23 Unraid kernel: br-02641c16abe3: port 3(vethced977a) entered forwarding state Jul 20 22:23:24 Unraid kernel: br-02641c16abe3: port 3(vethced977a) entered disabled state Jul 20 22:23:24 Unraid avahi-daemon[7805]: Joining mDNS multicast group on interface vethc21bcf6.IPv6 with address fe80::1ce3:f6ff:fe57:b05a. Jul 20 22:23:24 Unraid avahi-daemon[7805]: New relevant interface vethc21bcf6.IPv6 for mDNS. Jul 20 22:23:24 Unraid avahi-daemon[7805]: Registering new address record for fe80::1ce3:f6ff:fe57:b05a on vethc21bcf6.*. Jul 20 22:23:24 Unraid kernel: eth0: renamed from vethec4677f Jul 20 22:23:24 Unraid kernel: IPv6: ADDRCONF(NETDEV_CHANGE): vethced977a: link becomes ready Jul 20 22:23:24 Unraid kernel: br-02641c16abe3: port 3(vethced977a) entered blocking state Jul 20 22:23:24 Unraid kernel: br-02641c16abe3: port 3(vethced977a) entered forwarding state Jul 20 22:23:25 Unraid rc.docker: OnlyOfficeDocumentServer: started succesfully! Jul 20 22:23:25 Unraid kernel: br-02641c16abe3: port 4(veth3a3f803) entered blocking state Jul 20 22:23:25 Unraid kernel: br-02641c16abe3: port 4(veth3a3f803) entered disabled state Jul 20 22:23:25 Unraid kernel: device veth3a3f803 entered promiscuous mode Jul 20 22:23:25 Unraid kernel: br-02641c16abe3: port 4(veth3a3f803) entered blocking state Jul 20 22:23:25 Unraid kernel: br-02641c16abe3: port 4(veth3a3f803) entered forwarding state Jul 20 22:23:25 Unraid kernel: br-02641c16abe3: port 4(veth3a3f803) entered disabled state Jul 20 22:23:25 Unraid avahi-daemon[7805]: Joining mDNS multicast group on interface veth3b5b586.IPv6 with address fe80::8886:23ff:fe26:468b. Jul 20 22:23:25 Unraid avahi-daemon[7805]: New relevant interface veth3b5b586.IPv6 for mDNS. Jul 20 22:23:25 Unraid avahi-daemon[7805]: Registering new address record for fe80::8886:23ff:fe26:468b on veth3b5b586.*. Jul 20 22:23:26 Unraid avahi-daemon[7805]: Joining mDNS multicast group on interface vethced977a.IPv6 with address fe80::2441:26ff:fe6e:7e1. Jul 20 22:23:26 Unraid avahi-daemon[7805]: New relevant interface vethced977a.IPv6 for mDNS. Jul 20 22:23:26 Unraid avahi-daemon[7805]: Registering new address record for fe80::2441:26ff:fe6e:7e1 on vethced977a.*. Jul 20 22:23:27 Unraid kernel: eth0: renamed from vethda209d1 Jul 20 22:23:27 Unraid kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth3a3f803: link becomes ready Jul 20 22:23:27 Unraid kernel: br-02641c16abe3: port 4(veth3a3f803) entered blocking state Jul 20 22:23:27 Unraid kernel: br-02641c16abe3: port 4(veth3a3f803) entered forwarding state Jul 20 22:23:27 Unraid rc.docker: transmission: started succesfully! Jul 20 22:23:28 Unraid kernel: atlantic 0000:04:00.0 eth0: atlantic: link change old 0 new 10000 Jul 20 22:23:28 Unraid kernel: br0: port 1(eth0) entered blocking state Jul 20 22:23:28 Unraid kernel: br0: port 1(eth0) entered forwarding state Jul 20 22:23:29 Unraid avahi-daemon[7805]: Joining mDNS multicast group on interface veth3a3f803.IPv6 with address fe80::1871:4ff:fe78:26bb. Jul 20 22:23:29 Unraid avahi-daemon[7805]: New relevant interface veth3a3f803.IPv6 for mDNS. Jul 20 22:23:29 Unraid avahi-daemon[7805]: Registering new address record for fe80::1871:4ff:fe78:26bb on veth3a3f803.*. Jul 20 22:23:30 Unraid kernel: atlantic 0000:04:00.0 eth0: atlantic: link change old 10000 new 0 Jul 20 22:23:30 Unraid kernel: br0: port 1(eth0) entered disabled state Jul 20 22:23:33 Unraid ntpd[1124]: Deleting interface #2 br0, 192.168.178.28#123, interface stats: received=24, sent=24, dropped=0, active_time=63 secs Jul 20 22:23:33 Unraid ntpd[1124]: 216.239.35.0 local addr 192.168.178.28 -> <null> Jul 20 22:23:33 Unraid ntpd[1124]: 216.239.35.4 local addr 192.168.178.28 -> <null> Jul 20 22:23:33 Unraid ntpd[1124]: 216.239.35.8 local addr 192.168.178.28 -> <null> Jul 20 22:23:33 Unraid ntpd[1124]: 216.239.35.12 local addr 192.168.178.28 -> <null> Jul 20 22:23:45 Unraid kernel: atlantic 0000:04:00.0 eth0: atlantic: link change old 0 new 10000 Jul 20 22:23:45 Unraid kernel: br0: port 1(eth0) entered blocking state Jul 20 22:23:45 Unraid kernel: br0: port 1(eth0) entered forwarding state Jul 20 22:23:45 Unraid unassigned.devices: Using Gateway '192.168.178.1' to Ping Remote Shares. Jul 20 22:23:45 Unraid unassigned.devices: Waiting 5 secs before mounting Remote Shares... Jul 20 22:23:46 Unraid ntpd[1124]: Listen normally on 3 br0 192.168.178.28:123 Jul 20 22:23:46 Unraid ntpd[1124]: new interface(s) found: waking up resolver unraid-diagnostics-20230720-2241.zip

Could you ever get this to work? I have added the user id of my user --uid 1000 --gid 100 and i got write permission in that folder, that means i can paste files in that folder (even though an error message pops up) but i can't delete or overwrite a file.

Ja genau. Bei Nextcloud sind es zwar Apps, ich nehme sie aber immer Plugins, sorry Kannst du mir vielleicht sagen, wie bei dir die Shares eingebunden sind?

Den Share habe ich zuerst im Container gemappt und dann in Nextcloud über External Storages den Share über "local" eingebunden

Ich verwende den Linuxserver Container, welchen verwendest du?

So wie du es umgesetzt hast mit den User-Ordner als eigene Shares, wollte ich zuerst auch machen. Wurde mir aber von einem Bekannten abgeraten, weil man ein Indexierungsproblem hat und evtl. sogar mehr Schaden anrichten kann. In External über Nextcloud zu schreiben ist kein Problem, aber auf einen Share zb. über einen PC zu schreiben und dann in Nextcloud aufzurufen ist ein Problem, weil Nextcloud die neuen Dateien nicht sofort aktualisiert. Man kann den Vorgang entweder selber triggern oder warten bis Nextcloud es selber macht. Damit habe ich aber eigentlich kein Problem. MIr geht es eher darum, dass die Integration der "Externen Shares" ohne Probleme läuft und das tut dieses Plugin nicht. Egal ob per SMB oder als local - immer ist irgendetwas. Da sind wir nicht die Einzigen. Wenn man die Nextcloud nur als Cloud ohne der Externen Shares verwendet, läuft einwandfrei. Aber für meinen Workflow möchte ich beides, deswegen werde ich mir in den nächsten Tagen "Filerun" installieren. Dort sollte die Einbindung der Externen Shares + Indexierung von Haus aus laufen. Nachteile: nicht Open-Source und nur 10 User wenn man seinen Server registriert.

Nein, ohne Komma. Ich habe es schon sicher 20x probiert Nach viel Recherche, habe ich auch noch von anderen Nextcloud Usern gelesen, dass sie den gleichen Fehler haben. Eine Lösung gab es leider nie.

Genau, test ist der zu löschende Ordner. Habe es jetzt gerade nochmal getestet. Fall 1: Ordner über die Nextcloud WebGUI erstellt / Rechte: drwxr-xr-x 1 nobody users Habe dann diesem Ordner alle Rechte gegeben "drwxrwxrwx" Danach habe ich den Ordner in der Nextcloud WebGUI gelöscht. Gleiches Verhalten und der gleiche Fehler Fall2: Ordner im Share erstellt / Rechte: drwxrwxrwx Diesen Ordner über die Nextcloud WebGUI gelöscht Fehler bleibt gleich Es liegt also meiner Meinung nach nicht an den Rechten, weil ja der Ordner trotzdem gelöscht wird, auch wenn man die GUI aktualisieren muss. Im Share ist der Ordner sofort gelöscht.