flinx01

Schau dir mal Syncthing an, nutze ich zwar mit Android, gibt es meines Wissens auch für das Iphone

Hello, the error has occurred again, again when copying a large file, enclosed is the current diagnostics. bigone-diagnostics-20220422-2244.zip

Sorry, I did not have time. The mounting is done with the FSTAB: #### NFS#### 192.168.0.51:/mnt/user/Bilder /home/lukas/Bilder nfs auto,rw,users,_netdev 0 0 192.168.0.51:/mnt/user/callibre /home/callibre nfs auto,rw,users,_netdev 0 0 192.168.0.51:/mnt/user/Musik /home/lukas/Musik nfs auto,rw,users,_netdev 0 0 192.168.0.51:/mnt/user/lukas /home/lukas/data nfs auto,rw,users,_netdev 0 0 192.168.0.51:/mnt/user/download /home/lukas/usenet nfs auto,rw,users,_netdev 0 0 192.168.0.51:/mnt/user/Video /home/lukas/Videos nfs auto,rw,users,_netdev 0 0 Since the day before yesterday there was no connection failure. Is like at the dentist , when you are there , no pain.

Sorry i forgot ... bigone-diagnostics-20220417-1411.zip

Ok dann werde ich einen Bug melden. Danke

Hallo zusammen und frohe Ostern ... ich bin letzte Woche auf die Unraid Version 6.10 gewechselt, da ich häufig Probleme mit NFS hatte (Linux Mint hat NFS 4.0 aber Unraid hat eine kleinere Version), diese Kombination führte häufig zu Problemen, fast Täglich gingen die Zufriffe auf die NFS Freigaben verloren. Seit dem Wechsel habe ich zwar weniger Probleme, aber nach größeren Fileoperationen funktioniert der Zugriff auf die NFS Laufwerke des Unraid Servers nicht mehr . Im System Log stehen folgende Meldungen: Apr 15 20:24:03 bigone emhttpd: read SMART /dev/sdd Apr 15 20:25:15 bigone emhttpd: read SMART /dev/sdb Apr 15 20:33:17 bigone kernel: shfs[27786]: segfault at 10 ip 00001544dc2484f1 sp 00001544db1e0ba0 error 4 in libfuse3.so.3.10.5[1544dc244000+19000] Apr 15 20:33:17 bigone kernel: Code: e8 44 c9 ff ff 8b 85 00 01 00 00 85 c0 0f 85 b6 01 00 00 4c 89 f6 48 89 ef 31 db e8 19 dc ff ff 4c 89 ef 45 31 ed 48 8b 40 20 <4c> 8b 70 10 e8 86 c2 ff ff 48 8d 4c 24 18 45 31 c0 31 d2 4c 89 f6 Apr 15 20:33:17 bigone kernel: ------------[ cut here ]------------ Apr 15 20:33:17 bigone kernel: nfsd: non-standard errno: -103 Apr 15 20:33:17 bigone kernel: WARNING: CPU: 15 PID: 5624 at fs/nfsd/nfsproc.c:886 nfserrno+0x4c/0x54 [nfsd] Apr 15 20:33:17 bigone kernel: Modules linked in: rpcsec_gss_krb5 macvlan xt_nat xt_tcpudp veth xt_conntrack nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat br_netfilter xfs xt_MASQUERADE ip6table_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nfsd auth_rpcgss oid_registry lockd grace sunrpc md_mod nct6775 hwmon_vid ip6table_filter ip6_tables iptable_filter ip_tables x_tables bonding wmi_bmof x86_pkg_temp_thermal intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel crypto_simd cryptd rapl intel_cstate intel_uncore nvme i2c_i801 i2c_smbus igc nvme_core i2c_core ahci input_leds led_class libahci wmi thermal fan tpm_crb video tpm_tis tpm_tis_core backlight tpm button acpi_tad acpi_pad Apr 15 20:33:17 bigone kernel: CPU: 15 PID: 5624 Comm: nfsd Tainted: G W 5.15.30-Unraid #1 Apr 15 20:33:17 bigone kernel: Hardware name: ASUS System Product Name/PRIME Z590-A, BIOS 1402 01/27/2022 Apr 15 20:33:17 bigone kernel: RIP: 0010:nfserrno+0x4c/0x54 [nfsd] Apr 15 20:33:17 bigone kernel: Code: ff c0 48 83 f8 23 75 e1 80 3d c0 00 05 00 00 41 bc 00 00 00 05 75 15 48 c7 c7 0d 61 40 a0 c6 05 aa 00 05 00 01 e8 c8 17 3e e1 <0f> 0b 44 89 e0 41 5c c3 48 83 ec 18 31 c9 ba ff 07 00 00 65 48 8b Apr 15 20:33:17 bigone kernel: RSP: 0018:ffffc900008d7b50 EFLAGS: 00010282 Apr 15 20:33:17 bigone kernel: RAX: 0000000000000000 RBX: 0000000000000002 RCX: 0000000000000027 Apr 15 20:33:17 bigone kernel: RDX: 0000000000000003 RSI: ffffc900008d79d8 RDI: ffff88883bddc550 Apr 15 20:33:17 bigone kernel: RBP: ffffc900008d7db8 R08: ffffffff820b4d28 R09: ffffffff82044d08 Apr 15 20:33:17 bigone kernel: R10: 00007fffffffffff R11: ffffffff8263a83e R12: 0000000005000000 Apr 15 20:33:17 bigone kernel: R13: ffff88814958c238 R14: 00000000ffffff99 R15: 000000000010011a Apr 15 20:33:17 bigone kernel: FS: 0000000000000000(0000) GS:ffff88883bdc0000(0000) knlGS:0000000000000000 Apr 15 20:33:17 bigone kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Apr 15 20:33:17 bigone kernel: CR2: 00001473039eee38 CR3: 000000000200a006 CR4: 00000000007706e0 Apr 15 20:33:17 bigone kernel: PKRU: 55555554 Apr 15 20:33:17 bigone kernel: Call Trace: Apr 15 20:33:17 bigone kernel: <TASK> Apr 15 20:33:17 bigone kernel: nfsd4_encode_fattr+0x11ee/0x1220 [nfsd] Apr 15 20:33:17 bigone kernel: ? kvmalloc_node+0x53/0xa0 Apr 15 20:33:17 bigone kernel: ? override_creds+0x21/0x30 Apr 15 20:33:17 bigone kernel: ? nfsd_setuser+0x185/0x1a1 [nfsd] Apr 15 20:33:17 bigone kernel: ? nfsd_setuser_and_check_port+0x76/0xb0 [nfsd] Apr 15 20:33:17 bigone kernel: ? nfsd_setuser_and_check_port+0x76/0xb0 [nfsd] Apr 15 20:33:17 bigone kernel: nfsd4_encode_getattr+0x28/0x2a [nfsd] Apr 15 20:33:17 bigone kernel: nfsd4_encode_operation+0xa9/0x1e6 [nfsd] Apr 15 20:33:17 bigone kernel: nfsd4_proc_compound+0x271/0x508 [nfsd] Apr 15 20:33:17 bigone kernel: nfsd_dispatch+0x181/0x21a [nfsd] Apr 15 20:33:17 bigone kernel: svc_process+0x484/0x69c [sunrpc] Apr 15 20:33:17 bigone kernel: ? nfsd_svc+0x2bc/0x2bc [nfsd] Apr 15 20:33:17 bigone kernel: ? nfsd_shutdown_threads+0x77/0x77 [nfsd] Apr 15 20:33:17 bigone kernel: nfsd+0xee/0x145 [nfsd] Apr 15 20:33:17 bigone kernel: kthread+0xdc/0xe3 Apr 15 20:33:17 bigone kernel: ? set_kthread_struct+0x32/0x32 Apr 15 20:33:17 bigone kernel: ret_from_fork+0x1f/0x30 Apr 15 20:33:17 bigone kernel: </TASK> Apr 15 20:33:17 bigone kernel: ---[ end trace 6dcc3502a1993bb2 ]--- Wie geschrieben diese Fehlermeldungen treten alle paar Tage, nach intensiven Kopier Operationen auf, ich dachte das Problem wäre mit NFS4 behoben. Gibt es hier einen Patch oder ähnliches ???? Danke Lukas

bin auf 6.9.2, das mit dem Stick werde ich morgen mal ausprobieren. wobei ich seit Donnerstag ruhe habe ...., aber beim vorletzten mal sind auch etliche Tage vergangen....

Hallo, die Nvidia wird von keinem Docker genutzt, übrigends auch keine VM im einsatz. Die Grafikarte ist übrigens eine GeForce GT 610, also Asbach Uralt. Übrigens scheint noch mehr im Argen gelegen zu haben, ich habe vorhin versucht das System per shutdown -h now bzw. einfach mit einem Reboot per shell neu zu starten, das hat nicht geklappt, ich musste einen harten neustart mit dem Power Schalter durchführen ... Den Server habe ich jetzt neu gestartet, keinerlei Fehler, auch im Syslog allles OK .....

Hallo zusammen, ich habe seit einiger Zeit das Problem, das sich der Unraid Server ab und zu nicht per WEB ansprechen ließ . Docker Ja, gesharte Laufwerke Ja, aber sonst keine Möglichkeit, auch Konsole nicht. Heute morgen hatte ich erneut dieses Verhalten, konnte mich jedoch per SSH anmelden. Ich habe mir sofort das Syslog angesehen und das ist voll von Meldungen wie die folgende, sagt das jemandem etwas ?? Mein System : ASUS Prime Z590-A , Intel Core i7-10700KF, 64 GB , NVIDIA Grafikkarte (alt und ganz einfach) Auszug Syslog, diese Meldungen wiederholen sich ständig. Please Help 😬🤔 Jan 27 04:40:41 bigone dhcpcd[1980]: br0: Router Advertisement from fe80::464e:6dff:fe27:c93c Jan 27 04:41:04 bigone kernel: rcu: INFO: rcu_sched self-detected stall on CPU Jan 27 04:41:04 bigone kernel: rcu: 8-....: (38759995 ticks this GP) idle=db2/1/0x4000000000000000 softirq=3580472/3580472 fqs=9024818 Jan 27 04:41:04 bigone kernel: (t=38760646 jiffies g=24340385 q=4300891) Jan 27 04:41:04 bigone kernel: NMI backtrace for cpu 8 Jan 27 04:41:04 bigone kernel: CPU: 8 PID: 1603 Comm: python3 Tainted: G D W 5.10.28-Unraid #1 Jan 27 04:41:04 bigone kernel: Hardware name: ASUS System Product Name/PRIME Z590-A, BIOS 1007 07/08/2021 Jan 27 04:41:04 bigone kernel: Call Trace: Jan 27 04:41:04 bigone kernel: <IRQ> Jan 27 04:41:04 bigone kernel: dump_stack+0x6b/0x83 Jan 27 04:41:04 bigone kernel: ? lapic_can_unplug_cpu+0x8e/0x8e Jan 27 04:41:04 bigone kernel: nmi_cpu_backtrace+0x7d/0x8f Jan 27 04:41:04 bigone kernel: nmi_trigger_cpumask_backtrace+0x56/0xd3 Jan 27 04:41:04 bigone kernel: rcu_dump_cpu_stacks+0x9f/0xc6 Jan 27 04:41:04 bigone kernel: rcu_sched_clock_irq+0x1ec/0x543 Jan 27 04:41:04 bigone kernel: ? trigger_load_balance+0x5a/0x1ca Jan 27 04:41:04 bigone kernel: update_process_times+0x50/0x6e Jan 27 04:41:04 bigone kernel: tick_sched_timer+0x36/0x64 Jan 27 04:41:04 bigone kernel: __hrtimer_run_queues+0xb7/0x10b Jan 27 04:41:04 bigone kernel: ? tick_sched_do_timer+0x39/0x39 Jan 27 04:41:04 bigone kernel: hrtimer_interrupt+0x8d/0x15b Jan 27 04:41:04 bigone kernel: __sysvec_apic_timer_interrupt+0x5d/0x68 Jan 27 04:41:04 bigone kernel: asm_call_irq_on_stack+0xf/0x20 Jan 27 04:41:04 bigone kernel: </IRQ> Jan 27 04:41:04 bigone kernel: sysvec_apic_timer_interrupt+0x71/0x95 Jan 27 04:41:04 bigone kernel: asm_sysvec_apic_timer_interrupt+0x12/0x20 Jan 27 04:41:04 bigone kernel: RIP: 0010:native_queued_spin_lock_slowpath+0x79/0x18a Jan 27 04:41:04 bigone kernel: Code: c1 e0 08 89 c2 8b 07 30 e4 09 d0 a9 00 01 ff ff 74 0c 0f ba e0 08 72 1a c6 47 01 00 eb 14 85 c0 74 0a 8b 07 84 c0 74 04 f3 90 <eb> f6 66 c7 07 01 00 c3 48 c7 c0 0 0 30 02 00 65 48 03 05 f0 8e f8 Jan 27 04:41:04 bigone kernel: RSP: 0000:ffffc90001f13e38 EFLAGS: 00000202 Jan 27 04:41:04 bigone kernel: RAX: 0000000000400101 RBX: 0000000000000255 RCX: 000ffffffffff000 Jan 27 04:41:04 bigone kernel: RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffea001eed9ba8 Jan 27 04:41:04 bigone kernel: RBP: ffff888223ea3140 R08: ffff8883acc85d60 R09: 0000000000000000 Jan 27 04:41:04 bigone kernel: R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 Jan 27 04:41:04 bigone kernel: R13: 000055653580a6a4 R14: ffff88810116dd80 R15: 8000000000000065 Jan 27 04:41:04 bigone kernel: ? pmd_pfn+0x13/0x3a Jan 27 04:41:04 bigone kernel: queued_spin_lock_slowpath+0x7/0xa Jan 27 04:41:04 bigone kernel: handle_mm_fault+0x759/0xec3 Jan 27 04:41:04 bigone kernel: exc_page_fault+0x259/0x373 Jan 27 04:41:04 bigone kernel: ? asm_exc_page_fault+0x8/0x30 Jan 27 04:41:04 bigone kernel: asm_exc_page_fault+0x1e/0x30 Jan 27 04:41:04 bigone kernel: RIP: 0033:0x14f8cf366d24 Jan 27 04:41:04 bigone kernel: Code: ff 4c 8b 05 fe f8 21 00 49 83 c0 01 4c 89 05 f3 f8 21 00 4c 89 43 18 eb a5 0f 1f 44 00 00 48 3d ff ff 00 00 0f 8f 49 3d f3 ff <66> 42 89 0c 6e 4c 8d 0c 47 49 01 f 1 4d 89 31 4c 8b 73 28 49 89 69 Jan 27 04:41:04 bigone kernel: RSP: 002b:00007ffd88d919e0 EFLAGS: 00010293 Jan 27 04:41:04 bigone kernel: RAX: 0000000000000100 RBX: 000014f8cee0ebc0 RCX: 0000000000000096 Jan 27 04:41:04 bigone kernel: RDX: 000014f8cf564940 RSI: 000055653580a4f8 RDI: 0000000000000e10 Jan 27 04:41:04 bigone kernel: RBP: 000014f8c95eb3b0 R08: 00000000000000ff R09: 0000000000000e10 Jan 27 04:41:04 bigone kernel: R10: e4483959ad49c4d6 R11: 0000000000000000 R12: 000014f8c953a340 Jan 27 04:41:04 bigone kernel: R13: 00000000000000d6 R14: e4483959ad49c4d6 R15: 000055653580a4d0 Jan 27 04:41:17 bigone dhcpcd[1980]: br0: Router Advertisement from fe80::464e:6dff:fe27:c93c Jan 27 04:41:19 bigone dhcpcd[1980]: br0: Router Advertisement from fe80::464e:6dff:fe27:c93c

Hallo, habe es leider erst gerade gelesen. Klar habe ich die Datei: autossh-1.4g-x86_64-1_slonly.txz

🙄 nicht fragen .... Aber ich habe die CPU zu einem sehr guten Preis bekommen, da war mir die IGPU nicht so wichtig .. mein Meister 😆

Hallo zusammen, kurze Frage, ich werde meine aktuelle Unraid Hardware (Motherboard Gigabyte X570 AORUS MASTER und CPU AMD Ryzen 7 3700X ) austauschen, hat leider einen sogenannten Cold Boot Bug. Ich werde auf folgende Hardware wechseln: Asus ‎PRIME Z590-A und Intel Core i7-10700KF . Muss ich da irgend etwas beachten (außer Backup und so .. ☺️) oder reicht es neue Hardware rein + Platten + USB Stick wieder einstecken und starten .? Danke

Gott sei danke habe ich ein Backup, heute Vormittag hat sich die Samsung SSD verabschiedet 😬. Ich konnte den Cachepool manuell wieder einbinden und habe anschließend alle Shares auf das Array umgestellt und MOVE laufen lassen, um die Daten auf das Array zu schieben. Danach habe ich das System runtergefahren, die beiden SSD's entfernt und zwei SSD M.2 eingebaut. und als Cache Pool Konfiguriert. Server wieder da, aber meine Docker sind weg, kann ich die irgendwie wieder einfach restaurieren oder muss ich die Einzeln wieder Installieren ?? Danke ....

Habe den langen Smarttest mit beiden SSD's durchgeführt, komischerweise sehr unterschiedliche Laufzeiten, obwohl beide ca. 500 GB haben: - Crucial ca. 10 Minuten : keine Fehler - Samsung ca. 60 Minuten : aber ebenfalls keine Fehler Mal schaun ich werde wohl die Samsung austauschen, ist auch die älteste SSD, ich meine ich habe noch eine 2. Crucial rumliegen. Gibt es irgendetwas zu beachten wenn ich die SSD tausche ?

Ach ja, der Smart short Selftest hat auch keinen Fehler ergeben.

Uhps hatte ich vergessen , sorry 😁 bigone-diagnostics-20211019-1606.zip

Hallo zusammen, nachdem bei mir Unraid inzwischen läuft, und das Array seit ca. 10 Tagen online war, musste ich das System einmal runterfahren. Mit dem Ergebnis das die Cache SSD Laufwerke (1 * Crucial CT480BX500 + 1 * Samsung_SSD_860_EVO_500GB in einem Raid 0) mit der Fehlermeldung bigone root: mount: /mnt/cache: wrong fs type, bad option, bad superblock on /dev/sdb1, missing codepage or helper program, or other error, sich nicht mehr mounten ließen. Ich habe den Fehler beheben können indem ich FSCK /dev/sdc1 ausgeführt habe, danach funktionierte das Raid wieder. Nun meine Frage: würdet Ihr der SSD noch trauen ? Es gibt keinerlei weitere Fehler (SMART etc .. nichts) oder gleich eine neue SSD kaufen ?

Uhps , ich würde ohne DB Dateien ja alles auf Cache : JA stehen lassen, aber diese Einstellung führt dazu das das Array ununterbrochen läuft. Und zweitens nach der Erstanlage landen DB Dateien Permanent auf dem Array. Aber: wenn auf Prefer , dann sind diese permanent auf dem Cache, aber wenn der mover läuft dann transferiert der alle Daten auf das Cache, richtig ? Wen ja ist das eine Katastrophe, es würden z. B alle Datenbanken überschrieben ! Ich habe gerade den Mover zur Sicherheit vollständig deaktiviert .... bis ich weiss was ich einstellen muss. Soll ich die Datenbanken alle auf ein extra Laufwerk verschieben, so das Mover Aktionen ungefährlich sind ? Für normale Dateioperationen ist das klar: alle betroffenen Freigaben auf JA. Aber für alle Dateien , die ständig geändert werden und DIE nicht bei jeder Änderung neuangelegt werden, ist eine Einstellung wie PREFER tödlich ...., weil die werden aus dem Array überschrieben ; Arghhh Für mich heißt das , entweder alles auf Cache : JA und ich vergesse das mit dem Stromsparen , bleibe also bei über 80 Watt oder ich lagere die Datenbanken aus...... Was aber bedeutet das Unraid Array Prinzip ist für Datenbanken ungeeignet , außer die Einstellungen NO oder ONLY Habe ich das jetzt richtig verstanden ? Ein etwas erschrockener Lukas 😳

Jep, das hat funktionioert, die beiden appdata und system umgestellt auf cache prefer. Seitdem läuft es wie es soll. Danke alle die mir geholfen haben 😀

Bingo: Übeltäter gefunden: mariadb in Kombination mit baikal. MariaDB legt seine Datenbanken unter /mnt/user/appdata/mariadb/databases/baikal ab, es gibt zwar die Freigabe appdate die den Status Ja:Cache hat, aber wie bekommt es das System mit den Datenbankdateien hin ? Ich vermute mal die liegen nie auf dem Cache, sondern immer auf der Datendisk, da ja immer nur neue Dateien auf dem Cache abgelegt werden. Die Datenbanken sind ja nie neu, sondern werden ja von mariadb verwaltet. Deshalb wacht das Array auch alle paar Minuten wieder auf, da über baikal und einigen Clienten immer wieder der Status z. B. der Calender abgefragt werden. Wie macht Ihr das mit DB Dateien ? Werden diese immer auf dem Cache gelegt und von von dort nur gesichert ? Wie ist das mit sehr grossen Datenbanken, z. B. meine Photos (über 100.000) über digikam, alles auf den Cache und nur auf dem Cache ? Welche Erfahrungen habt ihr mit so etwas ? Danke für jeden Tipp ...

Tja, am liebsten alles ☺️, aber es reicht der Spindown. Ich habe gestern abend, das Docker Subsystem deaktiviert und siehe da, die Platten haben sich automatisch schlafengelegt. Ich denke, das ein Docker dort noch aktiv ist (habe keine VM aktiv), sprich ich werde heute abend überprüfen ob ein Docker auf den HDDs und nicht im Cache aktiv ist. Danke .....

Hmm, alle Platten haben eine Verzögerung von 15 Min. eingetragen, aber kein Effect. Ihc habe die Screenshots der Einstellungen angehängt. Wenn ich jedoch den Schalter SPin-Down unter Start bestätige, werden alle HDDs versucht in den Sleep Modus zu schicken, was aber nur mit der 2. Datenplatte funktioniert : ....

Sorry für die späte Rückmeldung, aber Urlaub ist leider vorbei 😞. Was für Einstellungen sind den notwendig, bzw., wo kann ich das nachlesen, welche Einstellungen notwendig sind um die HDDs in den Sleepmodus zu schicken ? Bis jetzt ist der Status der, das von den beiden Datenplatten nur die und auch nur selten in den Sleepmodus geht , welche praktisch nicht genutzt wir .... Ich habe auch alle Freigaben kontrolliert, die stehen alle auf : Ja: cache. Hat jemand eine Idee ??

So , ich habe alle Freigaben kontrolliert: Und auch die Einstellungen in den Disk Settings, dort stand allerdings das Delay auf nie ! Das habe ich jetzt auf 15 Minuten gesetzt. Die Einstellungen in den einzelnen Laufwerken steht Spin Down Verzögerung : Benutzte Standard. War das vielleicht der Fehler ? Ich werde das mal so laufen lassen und schauen ...