hawihoney

Wird m.W. vor dem Formatieren abgefragt. Diese Entscheidung kann Dir niemand abnehmen. Ich nutze beides. XFS für system-relevante Daten, NTFS für eigene Daten. Eine unserer drei NTFS Backup-Platten mit den eigenen Daten liegt im Sheldon-Notfall-Koffer Wenn alles abfackelt werde ich mit Sicherheit nicht mehr neu anfangen. Dann benötige ich ohnehin nur noch das wirklich, wirklich, wirklich Wichtige.

... und die Sicherung des USB-Sticks nicht vergessen ...

Beim Array eigentlich nicht da jede Daten-Platte (außer die Parity-Platten) ein eigenes Dateisystem besitzt. Du bekommst nur Probleme wenn Du im Parity-gestützten Array Parity- und Daten-Platten vertauschst und dann den Sync startest.

Ja und ja. Die Lizenz ist an den USB-Stick gebunden sowie an die Anzahl der Platten je nach gekaufter Lizenz. Ein Wechsel des SATA Ports spielt keine Rolle, da Unraid ohnehin intern mit den IDs der Platten arbeitet. Sollte Unraid wider Erwarten die Platten nicht direkt erkennen und zuordnen können, dann wird Unraid den Start verweigern. Anschließend korrigierst Du in der GUI die Zuordnung der Platten. Deshalb sollte man immer einen Screenshot der Hauptseite von Unraid archivieren. Damit kennt man im Falle eines Falles die Zuordnung der Platten.

Google ist Dein Freund: https://www.gieseke-buch.de/windows/smart-festplatten-interpretieren Das hat nichts miteinander zu tun. Meine Array Platten sind quasi immer im Spin-Down - außer sie werden im Moment genutzt. Der Server ist aber trotzdem rund um die Uhr an. Meine Pools hingegen sind rund um die Uhr im Spin-Up. Die Pools werden aber auch permanent benötigt. Container, VMs, rund um die Uhr laufende Tools. Muss man das halt auf die eigene Nutzung des Systems balancieren.

Guck Dir mal die Power on hours und Start Stop count an. Die Platten starten teilweise sehr oft (schlecht für die Lebensdauer) und haben nur wenige Monate gelaufen (gut für die Lebensdauer). UDMC=1 ist pillepalle. Und ja, das geht nicht mehr weg. Meine Einschätzung oben (schlecht/gut) basiert auf meinen eigenen Erfahrungswerten. Ich nutzte zwei in den USA gekaufte original Unraid-Server seit 2008/2009. Bis 2020 wurden die jede Nacht heruntergefahren. In diesen ~12 Jahren war mindestens einmal im Monat eine Platte kaputt (von insgesamt 30 Platten). Seit 2020 laufen die Server in Supermicro Gehäusen durch. Nicht eine einzige Platte ist bisher kaputt gegangen. Ob das ausschließlich an den Gehäusen oder den unterschiedlichen Backplanes liegt wage ich zu bezweifeln. MBs und HBAs blieben zunächst die selben. Wie gesagt: Das sind eigene Erfahrungswerte. Solange die Platten noch in der Garantie/Gewährleistung sind ist das kein Problem. Außerhalb von Garantie und Gewährleistung ist das ein simpler mathematischer Dreisatz um zu ermitteln ob es nicht besser ist einen Server (!!!) 24/7 laufen zu lassen (bei einem 40 Cent Stromdeckel o.ä.). Bei Deinen Platten sehe ich jedenfalls im Moment kein Problem.

Die für einen "Alarm" relevanten Werte sind alle in Ordnung. So olle Dinger wie die Hitachi 721010 habe ich hier selbst noch. Die sind lahm, rattern und werden warm. Aber Probleme sehe ich aktuell nicht bei Dir. Die Werte sind in dem von Dir verwendeten Tool verkürzt dargestellt. Aber Du hast überall Value=0. Das bedeutet keine Fehler. Mir fehlt der UDMA-CRC-Error-Count. Dieser würde Verkabelungsprobleme offenbaren. Such diesen Wert mal in den SMART-Werten. Das machst Du am besten über die Unraid GUI.

Du mischst hier zwei Dinge. Konzentrieren wir uns zunächst auf den USB-Stick. Der beinhaltet das Unraid Betriebssystem, die zum USB-Stick passende Lizenz sowie alle Einstellungen zum Betriebssystem. Diesen Stick (Flash) sicherst Du über die Unraid GUI. Das erzeugt eine ZIP Datei. Wenn dieser Stick defekt wird, dann erstellst Du einen neuen Stick mit dem USB Creator Tool von Unraid und dieser von Dir gesicherten ZIP Datei. Danach startest Du den Server und Du wirst aufgefordert Deine Lizenz auf den neuen USB-Stick zu übertragen. Das erzeugt eine neue Lizenz, die alte Lizenz wird "geblacklistet" und alles ist wieder wie es war. Alle Docker Container und VMs legen zusätzlich eigene Einstellungen und Dateien ab. Den Ablageort hast Du selbst angegeben. Unraid bot Dir standardmäßig einen Ablageort passend zu Deinem System an, das konntest Du aber ändern. Dort wo Du die Ordner appdata, domains, isos hingelegt hast, dort liegen üblicherweise diese zusätzlichen Einstellungen. Diese Ordner solltest Du zusätzlich sichern für den Fall, dass dieser Datenträger - ob im Array oder im Pool - abraucht. Alle anderen Ordner, Shares und Dateien sind Deine eigenen Daten. Ob die für Dich relevant sind entscheidest Du selbst. Daraus ergeben sich mindestens drei verschiedene Backup Quellen und Ziele. Dafür gibt es im Unraid Appstore diverse Lösungen und hier im Forum bestimmt hunderte suchbare Threads. Das alles gleichzeitig abraucht ist i.d.R. durch den Benutzer selbst verursacht. Ich persönlich habe jedenfalls noch nie von so etwas gehört.

Switch to "XML view" in VM declaration and try with bus:device instead of vendor:product. E.g. # Instead of something like this ... <hostdev mode='subsystem' type='usb' managed='no'> <source> <vendor id='0x0930'/> <product id='0x6544'/> </source> [...] </hostdev> # try something like this: <hostdev mode='subsystem' type='usb' managed='no'> <source> <address bus='1' device='2'/> </source> [...] </hostdev> In your case these are vendor:1a86 product:55d4 vs. bus:2 device:5 and bus:2 device:6. ***EDIT*** Removed non-relevant code lines from above to avoid confusion.

Klar hat jeder. Unraid und seine Applications bzw. Plugins stellen aber für die große Mehrheit der Nutzer hier - achte auf die Fragen - einen großen Mehrwert dar. Mit dem User Scripts Plugin z.B. erübrigt sich die Frage nach dem Problem des Reboots oder der Sicherung.

Es ging um Backup-Skripte ...

Unter Unraid bietet sich hierfür das User Scripts Plugin an. Bash Skript reinkopieren, Schedule angeben - oder auch nicht. Die Skripte werden dann beim Sichern des Unraid-Sticks (Flash) automatisch mitgesichert.

Bin am Wochenende über einen Artikel zu Star Trek Strange New Worlds gestoßen. Was für ein Krampf mit den Streaming Diensten. Da ist jede Scheibe - selbst remuxed - haushoch überlegen: https://www.golem.de/news/star-trek-strange-new-worlds-neue-star-trek-serie-gibt-es-nur-auf-disc-in-4k-aufloesung-2305-174449.html

Ach so, genau andersrum, sorry. Ich bin ebenfalls mit der Qualität nicht ganz zufrieden, aber es gibt IMHO keine allumfassende Alternative. Trotzdem haben die meinen Respekt. So viele verschiedene Klienten ...

Heute morgen gab es eine neue Android Version, vielleicht klappte es deshalb nach der Neuinstallation. Und vom Server gibt es heute eine neue Beta: https://forums.plex.tv/t/plex-for-android/29115/470 Wir selbst gucken hauptsächlich auf zwei Plex Plattformen - AFTV 4K Ultra (Android) und LG (WebOS). In der Summe können beide alles. Der LG kann sogar mehr als der AFTV. Ich habe auch das Gefühl, dass die WebOS Entwickler gewissenhafter arbeiten. In der Android Version schleichen sich immer wieder Probleme rein die schon mal behoben waren. Von unseren Samsung Benutzern höre ich nie Klagen. Bei unseren Apple Benutzern ist aber dauernd etwas. Zusätzlich gibt es immer wieder Content, der läuft standardmäßig auf einem der Geräte nicht. Mal liegt es am Video-Stream, mal am Audio-Stream. Was ich in letzter Zeit aber häufiger erfolgreich getestet habe ist, das Runterschrauben der Bandbreite in den Wiedergabeeinstellungen des Content oder die Wahl eines anderen Audio-Streams - sofern vorhanden. Das Ändern der Bandbreite scheint etwas beim Transcoder auszulösen. Bei uns ist alles verkabelt, daran kann es also beim lokalen Playback nicht liegen. Gerade heute war wieder so ein Fall. Ein stinknormaler Content, nix Besonderes. Der Kringel drehte sich endlos. Spaßeshalber von ~ 30 Mbit Original Qualität etwas runter geschraubt und schon lief es. Da es bei Dir nach der Neuinstallation klappte, passt meine Antwort nicht ganz. Probier das aber mal beim nächsten Problem. Vielleicht hilft es.

remmina --> https://remmina.org/ (Remote Desktop Client) sakura --> http://www.troubleshooters.com/linux/sakura.htm (Terminal Emulator) If the software is not included in stock Unraid, perhaps the conf files are included by accident then?

Man kann doch selbst löschen, warum sollte man jemand anderes bitten das für einen zu übernehmen? Das schafft eine emotionale Hürde. Wenn sich jemand entschließt einen eigenen Beitrag zu löschen, dann ist das seine Angelegenheit. Er muß sich nicht erklären. Klingt harsch ist aber nicht so gemeint.

Hm, ich habe in der Vergangenheit schon mal 1-3 eigene Beiträge versteckt, da ich sie im Nachhinein für nicht mehr angemessen hielt - aus welchen Gründen auch immer. Nach 15 Jahren hier im Forum gab es auch 2 alte Beiträge von denen ich schlicht und ergreifend nicht mehr will, dass sie jemand sieht (kompromitierend, o.ä.). Unhide sollte IMHO immer nur in Absprache mit dem jeweiligen Poster erfolgen. Wenn dieser nicht mehr erreichbar ist oder zustimmt: Bitte, bitte, nicht unhide auf eigene Faust.

Just a question before staying with 6.11.5 forever: Does that "Exclusive Shares" thing affect all kind of shares or is it just shares below /mnt/user/ that are affected? I use three docker containers that have access to everything. They have access to: - Local disks (e.g. /mnt/disk1/Share/ ...) - Local pools (e.g. /mnt/pool_nvme/Share/ ...) - SMB remote shares via Unassigned Devices (e.g. /mnt/remotes/192.168.178.101_disk1/Share/ ...) - Own mount points (e.g. /mnt/addons/gdrive/Share/ ...) - Local external disks via Unassigned Devices (e.g. /mnt/disks/pool_ssd/ ...) - But no /mnt/user/ So I gave these three containers access to everything because there are 75 access points involved: - /mnt/ --> /mnt/ (R/W/slave) for two containers - /mnt/ --> /mnt/ (R/slave) to the third container It would be a huge intervention to change that because changing that would require 75 additional path mappings for every container of these three. My box is running happily that way for years because it was free from User Shares and their performance impact under some circumstances in the past. Can please somebody shed some light for me on that special and new share treatment: - Is it /mnt/user/ only that is affected or does it affect all kinds of shares (disk, disks, remotes, addons) ? - Can I switch that off globally (Exclusive share - symlink) ? - Will I see problems with these symlinks within containers when using /mnt/ -> /mnt/ without /mnt/user/ involved ? And yes, all Path Mappings have trailing '/' applied Many thanks in advance.

Und "/mnt/user/EinShare/" liegt dann unter "/mnt/user/mnt/user/EinShare/" ? Soll das für LuckyBackup wirklich so sein? Was spricht gegen: /boot/ --> /boot/ /mnt/ --> /mnt/

Oh, I do have a perfect reason to use Disk Shares. A Plex instance with access to several Unraid boxes (Unraid VMs). Using User Shares is a killer for that. I use Disk Shares instead. Plex can handle those more than 100 library folders perfectly. You access Plex content that is stored on VM01/Disk 12 - only that Disk spins up. In the beginning, several years ago, I tried it once with User Shares and it was a really, really, really bad experience. I doubt that it has something to do with that. All User Shares work but this single "system" one. Perhaps there is a hidden rule to avoid that name ... But wait, both root folders on that pool don't work. When 6.12 stable is in the wild I will try to disable Disk Shares just for a test. So everything in the settings shown above looks ok? shareUser="e" is really valid?

After reading the answers I'm completely lost now. As you can see on the screenshots below User Shares and Disk Shares are both enabled within Global Share settings. In addition the only setting for User Shares within the pool settings is enabled as well. Screenshots and listings above proof that there must be something wrong, but I have no idea what might be wrong. Adding the missing share "system" leads to a hanging "Starting services" for several hours. A reboot does not fix that. To make it clear: My really fat system runs perfect since a very long time but there was always that system thing that I never found a solution for. [email protected]:~# ls -la /mnt/pool_nvme/ total 0 drwxrwxrwx 4 nobody users 34 May 7 22:51 ./ drwxr-xr-x 30 nobody users 600 Mar 4 06:34 ../ drwxrwxrwx 2 root root 6 May 7 22:51 syslog/ drwxrwxrwx 6 root root 81 Dec 27 2021 system/ [email protected]:~# ls -la /mnt/pool_nvme/system/ total 1048576 drwxrwxrwx 6 root root 81 Dec 27 2021 ./ drwxrwxrwx 4 nobody users 34 May 7 22:51 ../ drwxrwxrwx 2 root root 55 Dec 25 18:50 ISOs/ drwxrwxrwx 11 root root 161 Mar 12 18:26 appdata/ drwx--x--- 15 root root 256 Feb 8 14:38 docker/ drwxrwxrwx 2 root root 6 Dec 5 07:12 domains/ -rw-rw-rw- 1 nobody users 1073741824 Feb 8 14:42 libvirt.img [...] S---------------t shareUseCache="no" # Share exists on disk8 system shareUseCache="no" # Share does not exist T--p shareUseCache="no" # Share exists on disk17 [...] BTW, I did download several diagnostics to check if there's something wrong with my settings. I found very interesting combinations. E.g.: shareUser="e" shareUser="-" shareUser="Auto" shareUser="No" ... Somebody should sync that to the most current values. Poor luck that this works? Just my 0.02 Cent.

AFAIK, it is set.

Yes my fault: /mnt/pool_nvme/ - exists /mnt/pool_nvme/system/ - exists /mnt/user/system/ - missing All other user shares do exist. If I try to add system under the shares tab a red text shows "Starting services" for several hours until the next morning. The new user share will not be created. Stick is ok and other changes will be stored. Did reboot several times. No change on this system thing. That looks weird from the ZIP: 1) The file system.cfg in /shares does exist but is not hidden. And the first line in that file says "# Share does not exist". 2) shareUser="e" in share.cfg. Is this correct? [email protected]:~# ls -la /mnt/pool_nvme/ total 0 drwxrwxrwx 4 nobody users 34 May 7 22:51 ./ drwxr-xr-x 30 nobody users 600 Mar 4 06:34 ../ drwxrwxrwx 2 root root 6 May 7 22:51 syslog/ drwxrwxrwx 6 root root 81 Dec 27 2021 system/ [email protected]:~# ls -la /mnt/pool_nvme/system/ total 1048576 drwxrwxrwx 6 root root 81 Dec 27 2021 ./ drwxrwxrwx 4 nobody users 34 May 7 22:51 ../ drwxrwxrwx 2 root root 55 Dec 25 18:50 ISOs/ drwxrwxrwx 11 root root 161 Mar 12 18:26 appdata/ drwx--x--- 15 root root 256 Feb 8 14:38 docker/ drwxrwxrwx 2 root root 6 Dec 5 07:12 domains/ -rw-rw-rw- 1 nobody users 1073741824 Feb 8 14:42 libvirt.img tower-diagnostics-20230513-0721.zip

Something that puzzles me since a long time: I do use a single device XFS pool called "pool_nvme". The root directory on this pool is called "system". This "system" directory is not shown under the shares tab. But the entry "pool_nvme" is shown there. So there's no /mnt/user/system/. There's only /mnt/user/pool_nvme. Why is it that way? I thought that all root folders become user shares - in the array and on pools? Is it because of this pool setting (Enable user share assignment)?