hawihoney

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. root@Tower:~# 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/ root@Tower:~# 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? root@Tower:~# 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/ root@Tower:~# 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)?

Ich habe das schon dutzende Male an meinem System gehabt. Ich besitze drei Backup-Platten die, je nach dem welche Platte gerade dran ist, an einen USB-Anschluss am Motherboard gesteckt werden. Dann starte ich ein User Script (rsync) zum Befüllen. Wenn das Skript fertig ist, klicke ich innerhalb des Unassigned Devices Plugin auf "unmount". Alle Nase lang klappt das nicht - selbst wenn ich noch einige Stunden nach Abschluss des User Scripts warte. Den "Hänger "bekomme ich ohne Reboot dann auch nicht mehr weg. Ich ziehe dann die Platte ab. Die Platte ist dann völlig in Ordnung und hat alle Übertragungen sauber abgeschlossen. Wenn dieser Fall eintritt, dann sieht das bei mir genau so aus. Die Platte steht noch im System - oder auch nicht. Und es werden 100 % Auslastung angezeigt - oder auch nicht. Ich habe schon vor langer Zeit aufgegeben darüber nachzudenken. Du bekommst diesen Rest einfach nicht aus dem System. Reboot hilft dann immer. Meines Wissens nach hatte ich beim ersten Auftreten sogar einen Bug Report los getreten. Da kam außer Reboot aber auch nix bei rum. Kurzer Nachtrag: Die Ordner und Dateien sind in dem Fall nie zu sehen - nur die Platte. So weit ist das dann abgeschlossen. Wie oben auf dem Screenshot im Dynamix File Manager zu sehen ist dann die Platte zu erkennen aber sonst nix mehr.

Durch einen Reboot ist das garantiert weg. Dich stören die 100 % Auslastung. Kann ich verstehen. Ist aber unkritisch. Im ersten Screenshot/Listing steckt die Disk drin, im zweiten ist sie raus. Ist wohl was hängen geblieben o.ä.

/mnt/disks/ (lokale Platten) und /mnt/remotes/ (entfernte Shares) sind vom Unassigned Devices Plugin. /mnt/addons/ ist neu und für eigene Mountpoints des Users vorgesehen. Bereinigen? Am besten in Unassigned Devices prüfen. So sieht das zum Beispiel bei mir aus: root@Tower:~# ls -la /mnt/addons/ total 0 drwxrwxrwt 3 nobody users 60 Apr 14 10:50 ./ drwxr-xr-x 30 nobody users 600 Mar 4 06:34 ../ drwxrwxrwx 1 root root 0 Apr 14 10:51 gdrive/ root@Tower:~# ls -la /mnt/disks/ total 0 drwxrwxrwt 4 nobody users 80 Mar 21 17:11 ./ drwxr-xr-x 30 nobody users 600 Mar 4 06:34 ../ drwxrwxrwx 3 nobody users 20 Nov 15 2021 NVMe2/ drwxrwxrwx 3 nobody users 21 Mar 9 20:44 pool_ssd/ root@Tower:~# ls -la /mnt/remotes/ total 0 drwxrwxrwt 46 nobody users 920 May 2 10:11 ./ drwxr-xr-x 30 nobody users 600 Mar 4 06:34 ../ drwxrwxrwx 2 nobody users 0 Sep 29 2021 192.168.178.101_disk1/

/mnt/user/ - alle Dateien eines User-Shares auf Array (AKA Secondary Storage) und Cache bzw. Pool (AKA Primary Storage). /mnt/user0/ - alle Dateien eines User-Shares auf Array ohne die Dateien auf Cache bzw. Pool. Wenn Du einen Cache bzw. Pool vorgeschaltet hast, dann werden dort neue Dateien und Ordner abgelegt bevor sie durch den Mover weitergereicht werden. /mnt/user0/ zeigt diese neuen Dateien und Ordner nicht an. /mnt/user/ hingegen zeigt die kombinierte Sicht auf den User-Share.

@trurl hat das sehr gut aufgebröselt in diesem Post:

I just asked because I am already confused. And as somebody who helps here since over a decade I should use correct naming. So the array is still the array and pools are still pools. And the cache is gone with that RC4 release. Got it now.

"unRAID pool" is the new name of the old unRAID array? And other pools are just "pools"?

Legt diese Vorgehensweise (Share anlegen) nicht einen Root Ordner auf der entsprechenden Array-Disk an - und der wird dann nicht genutzt?

Geht leider auch nicht - gerade probiert. Es werden logischerweise nur meine Array Devices als "included Disk(s)" zur Auswahl angeboten (Disk1...22). Der Pool taucht nicht auf. Ich müsste ein Array Device auswählen, den Pool als Cache auswählen und dann den Pool auf "Only" stellen. Da merkt man die Herkunft des alten Unraid im neuen Unraid. Ein solches Konstrukt gefällt mir einfach nicht. Ich lasse es einfach so wie es ist.

Nein. Wobei mich gerade wundert warum die User Shares grün sind. Denn ich habe nur einen Single Device XFS Pool... Da ist wohl etwas kaputt bei mir - läuft aber erste Sahne seit einem halben Jahr oder so..

Nein tut es nicht. Ich hänge gleich hier noch zwei Screenshots an ...

Ich hatte mir vor einigen Jahren eine eigene Struktur ausgedacht. Die läuft seit Jahren astrein. Jetzt kommen aber neue Automatismen/Regeln die nicht zu meiner Struktur passen. Mein /mnt/pool_nvme/system/appdata/ taucht noch nicht mal bei den Shares auf. Klar, wäre nicht notwendig. Werde wahrscheinlich nach dem Einbau von Multiple Arrays alles neu strukturieren.