Geschwindigkeit bei smb Datenübertragung auf NAS (spez.: kleine Files)

[lisanet]

Nein, ich erkläre nichts, auch nicht deine smb.conf.

Nur soviel:

Der Auslöser für das Nicht-Löschen-Können des Archivs ist die Kombination von fruit:nfs_aces=yes und der Art wie Samba die effektive Rechte aus Unix und acl ermittelt beim Anlegen von Dateien/Ordnern

Setzt du fruit:nfs_aces=no, dann tritt das nicht auf und das zip kann via Finder entpackt werden, da die effektiven Rechte nun vorliegen. (die restlichen Rechte + acl müssen natürlich stimmen)

ABER: dann tritt folgendes Problem auf -> https://lisanet.de/qnap-smb-macos-und-das-problem-mit-rwx-rechten/

Solltest du beide Dinge lösen können, her damit.

 

[jteschner]

Danke für deine Mühen!
Ich erkenne an: mir fehlt Wissen (und ich weiß gar nicht ob ich so tief in den Samba-Tanz einsteigen will)
Und: ich lese was du schreibst und verstehe es oberflächlich , denke ich zumindest :-/ - und erwarte auch gar nicht, dass du mir alles haarklein erklärst.
Alles gut.

Nur so für dich als Info (da mir das nie Ruhe lässt):
Ich habe für die "Freigegebenen Ordner" in OMV Posix Rechte (RW) für mich gesetzt (hatte ich vorher gar nicht) und die ACL Rechte ebenfalls für mich (RW) eingestellt.
Zumindest bleiben beim Hin-und herkopieren MBP<->OMV die Rechte immer gleich - was ja gut ist.

Eine Auffälligkeit habe ich noch bemerkt:
1. ein zip, das ich aus einem Ordner erstellt habe, der von Synology Drive "behandelt" ist, kann ich auf dem NAS zwar entpacken, aber das "ausgepackte" über den Finder nicht mehr löschen
2. ein zip aus einem anderen "Nicht-Synology-Drive-Ordner" ist dagegen nach dem entpacken auf dem NAS durch den Finder löschbar ...

Dies ist keine Aufforderung mir das zu erklären ...
Ich lebe nun einfach damit und habe wenigstens etwas gelernt

(heute kommt noch mein Hub - ich werde ausschließlich Erfolg vermelden und keine Frage stellen )

 

[oktagon]

Ich hatte neulich mit smb auch minimale Transfergeschwindigkeiten vom NAS bei kleinen Bildern. Habe dann wieder auf afp umgestellt und hatte sofort den Maximalspeed.

Mac os sonoma.

 

[picollo]

Das wird nicht an macOS liegen. Mit meinen RaspberryPi 4B habe ich recht hohe Übertragungsgeschwindigkeiten auf selbst konfigurierte SMB-Shares. Und der Pi gilt nun nicht als Wunder in Sachen Geschwindigkeit. Die Ursache werden sicherlich die NAS sein - oder mangelnder Support.

 

[lisanet]

Das Thema mit dem nicht löschbarem Ordner und der Entweder-Oder-Konfikt mit fruit:nfs_aces hat mir keine Ruhe gelassen und ich habe mir daher mal die source codes zum Sambe-Moduel vfs_fruit angesehen.

Der erste Eindruck:

Das ganze Problem könnte meines Erachtens an Samba liegen und nicht am Finder / macOS.

Die source zu vfs_fruit stammen aus einer relativ alten Version von Samba. Sie werde z.B. immer noch unter "source3" geführt, obwohl seit Jahren bereits Samba 4 aktuell ist. In Samba 3 waren noch "security-masks" implementiert, welche bei den Rechten mit berücksichtigt wurden. Das war damals sehr restriktiv. Das x-Bit (für ausführbar) wurde z.B. immer entfernt. Das x-Bit bedeutet aber bei Verzeichnissen nicht "ausführbar" sondern "betretbar".

Der Ordner "Archiv" der beim Entpacken entsteht, hat nun aber eben dieses x-Bit nicht, sprich man kann den Ordner nicht betreten. Beim Löschen muss aber ein Ordner erst mal betreten werden, damit erkannt wird, ob darin was ist. Sind darin weitere Unterordner werden auch die erst betreten und nachgesehen. Erst auf unterster Ebene beginnt dann der Löschvorgang. Folge davon: Man kann den Ordner nicht betreten und daher nicht löschen, obwohl man Schreibrechte darauf hat.

Die source codes zu vfs_fruit beinhalten noch immer die damaligen Funktionen zu den security masks, so dass es für mich aussieht, dass diese das ganze Problem auslösen.

Die Routinen sind auch so restriktiv gehalten, dass sie "ACCESS_DENIED" enthalten und das z.B. für die Gruppen-Rechte setzen. Die Rechte für "other" (everyone) werden sogar überhaupt nicht mehr zurück geliefert, wenn die Datei gelesen wird.

Folge hiervon: das rwx------ Problem, das ich in meinem Blog beschrieben habe.

Da jetzt so langsam die Zeit anfängt, wo man outdoor wenig unternehmen kann, werde ich mir mal Samba vornehmen und selbst kompilieren und versuchen einen Patch zu entwickeln, der dieses Rechte-Problem angeht. Die Ideen dazu habe ich ja durch obige Ausführungen beschrieben. Allerdings ist Samba ein riesiges Projekt und da ist es recht aufwendig, da neu einzusteigen und die Wechselwirkungen zu erkennen und vor allem zu verstehen.

Mal sehen was ich hin kriege. Mein Forschungsdrang ist zumindest mal geweckt und einen "freien" Entwicklungs-Rechner habe ich auch noch rum stehen.

 

[lisanet]

@jteschner und alle anderen

Ich habe eine kleine Automator-App geschrieben, welche anstelle des standarmäßig eingestelleten Entpackers fürs entpacken von zip-Files verwendet werden kann.

Damit kann man dann auch Archive auf smb-Freigaben (und auch auf dem Mac) problemlos entpacken und natürlich auch wieder löschen.

Einziger Wermutstropfen: es gibt bei Automator-Apps keinen Fortschrittsbalken. Lediglich in der Menuleiste sieht mal solange die App läuft ein sich drehendes Zahnrad-Icon.

Wenn Interesse besteht, kann ich das mal posten.

Nochwas: Einen Geschwindigkeitsvorteil bei smb-Freibagen gibt's damit nicht, da das Entpacken ja immer noch über smb abläuft.

 

[jteschner]

@jteschner und alle anderen

Ich habe eine kleine Automator-App geschrieben, welche anstelle des standarmäßig eingestelleten Entpackers fürs entpacken von zip-Files verwendet werden kann.

Damit kann man dann auch Archive auf smb-Freigaben (und auch auf dem Mac) problemlos entpacken und natürlich auch wieder löschen.

Einziger Wermutstropfen: es gibt bei Automator-Apps keinen Fortschrittsbalken. Lediglich in der Menuleiste sieht mal solange die App läuft ein sich drehendes Zahnrad-Icon.

Wenn Interesse besteht, kann ich das mal posten.

Nochwas: Einen Geschwindigkeitsvorteil bei smb-Freibagen gibt's damit nicht, da das Entpacken ja immer noch über smb abläuft.

Interesse auf jeden Fall - kann ich ja mal testen.
Inzwischen habe ich zwar alle Daten bereits auf dem Raspi-NAS, aber wer weiß schon was noch geschieht ...
Könntest du ja auch über deinen Blog zur Verfügung stellen

Ergänzung: mein Fokus liegt gerade auf einem angepassten Backup-Konzept, denn OMV ist ja doch etwas anders als Synology. Und in MergerFS bin ich auch etwas eingestiegen (was einen seltsamen Effekt auf Plex hat, den ich noch nicht ganz verstehe, aber einen Workaround habe)

 

[lisanet]

(was einen seltsamen Effekt auf Plex hat, den ich noch nicht ganz verstehe, aber einen Workaround habe)

was ist das für ein Effekt?

 

[lisanet]

Könntest du ja auch über deinen Blog zur Verfügung stellen

Dafür ist es mir zu einfach

Eher werde ich einen Artikel schreiben, wie man das gesamte Plex-Verzeichnis (das unter /var/lib/plexmediaserver) aufs NAS kriegt und dass dann auch stabil läuft ohne Probleme und somit auch die SD-Karte vom großen Cahe und den Metadaten "befreit"

Also hier nun die alternative unzip-App:

• starte Automator -> neues Dokument -> und wählt Programm aus
• links aus der Rubrik "Dienstprogramme" ziehe dann "Shell-Skript ausführen" nach rechts ins Fenster
• rechts dann das "Eingabe übergeben" einstellen auf "Als Argumente"

• nun den Text, der in der Aktion "Shell-Skript ausführen" steht komplett löschen und durch das nachfolgende script ersetzen (am besten mit copy&paste)
• speichere nun das ganze am besten mit dem Namen "myUnzip" im Programme-Ordner

Nun nimm ein zip-Archiv -> markieren ->

• CM + I für den Infodialog
• unter "Öffnen mit" dann die ComboBox öffen und "Andere..." wählen, ggf. noch die Box Aktiveren auf "Alle Programme" stellen und die soeben gespeichert App "myUnzip" auswählen -> auf "Hinzufügen" klicken
• auf "Alle ändern" klicken und den Dialog bestätigen
• Info-Dialog schließen

Ab nun wird mit Doppelklick auf ein zip-Archiv diese Automator-App verwendet. Das Entpacken funktioniert dann auch auf smb-Servern wenn fruit:nfs_aces auf yes steht und natürlich auch sonst auf dem Mac.

Hier das script für die obige Aktion:

dir=$(/usr/bin/dirname "$1")
base=$(/usr/bin/basename "$1")
cd "$dir"
/usr/bin/unzip "$base"
rm -rf "__MACOSX"

 

[jteschner]

was ist das für ein Effekt?

Nicht ganz einfach zu beschreiben- ich versuch es:

Setup:
- Plex ist "nativ" installiert (neben OMV)
- in OMV sind zwei SSD mit ihren FS eingebunden
- diese sind über mergerfs zusammengefasst zu "pool"
- über diesen pool laufen nun auch meine Freigaben (hier relevant: "video")
- in der Freigabe "video" gibt es zwei Ordner: "filme" und "serien"

Nun der Punkt:
- in Plex lege ich eine Mediathek "Filme" an und muss dann natürlich angeben, wo diese liegen
- normal wollte ich als Pfad angeben: pool->video->filme
- "filme" ist aber nicht selektierbar (sondern ausgegraut)
- selektier ich pool->video , so werden von Plex keine Filme oder Serien gefunden -> offensichtlich kein Zugriff o.ä.
- nehme ich als Pfad jedoch <device>->video->filme (also Pfad direkt und ohne mergerfs) so geht das einwandfrei.

Für mich der Schluss: Plex kommt irgendwie nicht mit mergerfs und dem "pool" zurecht. Die Zugriffsrechte stimmen (Posix und ACL). Das habe ich 5 mal geprüft und der Plex-User hat auch in der ACL eigene Rechte bekommen.

Ich kann durchaus damit leben, würde aber doch ganz gern wissen woran das liegt. Denn über die Shell kann ich problemlos auf die Freigaben über den pool zugreifen - genauso wie über smb vom MBP aus.

Nebenbei: Wegen einer anderen mergerfs Geschichte (Policy "Most Free Space" und deren Funktionsweise) hatte ich auch bereits Kontakt mit dem Entwickler. Da stimmt nämlich deren tatsächliche Funktionsweise nicht mit der Beschreibung im User-Guide auf omv-extras.org überein. Wo ich dann dachte ich hätte irgendwas falsch gemacht. War aber nicht so. Die Beschreibung im User-Guide ist falsch/misverständlich und wird vom Entwickler überarbeitet.

 

[lisanet]

hhmmm, seltsam. Das klingt für mich einfach nach einem Rechte-Problem.

So auf die Schnelle:

Wenn du für irgendwelche shares Rechte vergibst, dann gelten die erst mal nur für smb, nicht fürs Dateisystem. Plex greift aber übers Dateisystem zu, nicht übr smb. Über smb macht ja keinen Sinn, wenn beides, das Programm das Daten will und der Speicherplatz, auf dem gleichen Rechner sind.

Wenn du jetzt so die Standards von omv genommen hast, dann werden die shares im Dateisystem mit owner=root und group=users angelegt. users hat dabei rwx

Dein User mit dem du dich einloggst ist ja auch in group users. Plex aber nicht. Ergo: nimm den user "plex" in dir group "users" auf.

Geht ganz einfach im Terminal direkt auf dem NAS mit dem Konsoleneditor 'nano'

sudo nano /etc/group

Einfach mit den Cursortasten die Zeile mit 'user:x:.....' suchen. Wenn dein normaler account jteschner lautet steht dort dann

users:x:100:jteschner

einfach ein Komma dahinter, keine Leerzeichen und dann 'plex', also

users:x:100:jteschner,plex

Abspeichern geht in nano mit CTRL + O (der Buchstabe) und anschließendem RETURN. Verlassen geht mit CTRL + X

Dann noch den Server neu starten, damit plex auch in die Gruppe users aufgenommen wird. Nun kann Plex alle die Verzeichnisse lesen, die eben für die group=users angelegt sind. Auch die von mergerfs

Nur noch was zu mergerfs

Du nimmst aber schon mergerfs, nicht mergers-folders, ja?

Dein Pfad ist auch nicht ganz vollständig. Schreibe den lieber immer exakt so wie im Dateisystem. Da kann ich den evenutell einen Fehler erkennen. Der Pfad ist dann in omv sowas wie /srv/mergerfs/.....

 

[lisanet]

hhhmm ich muss das obige teilweise revidieren.

Ich habe historisch bedingt meine Medien auf einem RAID 0 in omv (ich habe mergerfs erst später installiert)

Ich habe nun auf einem mergerfs Volume einen Ordner angelegt. Den kann ich auch ohne weiters in Plex als Mediatheken-Ordner auswählen. Allerdings erkennt Plex die Videos darin nicht.

Sehr seltsam.

 

[jteschner]

hhhmm ich muss das obige teilweise revidieren.

Ich habe historisch bedingt meine Medien auf einem RAID 0 in omv (ich habe mergerfs erst später installiert)

Ich habe nun auf einem mergerfs Volume einen Ordner angelegt. Den kann ich auch ohne weiters in Plex als Mediatheken-Ordner auswählen. Allerdings erkennt Plex die Videos darin nicht.

Sehr seltsam.

ich ignoriere mal deinen Eintrag zuvor - ich habe natürlich nicht über smb geredet.
Plex HAT die Rechte für die Ordner - alles überprüft (Posix und ACL) - sonst könnte Plex ja ohne mergerfs auch nichts finden.

Genau: Plex erkennt die Videos nicht. Darüber bin ich erst auf das Problem gestoßen (und das hat mich echt Zeit gekostet)

Wenn du genauer einsteigen magst kann ich dir die genauen Details schicken. Oben das waren nur Beispiele um es einfacher zu machen - hat wohl nicht geklappt

 

[lisanet]

Echt seltsam. Jetzt geht es bei mir.

Folgender Pfad ist mein mergerfs-Dateisystem: /srv/mergerfs/Merger

darauf ist ein Share eingreichtet, Pfad ist dann /srv/mergerfs/Merger/UnimatrixZero

Dort habe ich vom Mac via smb einen Ornder Clips angelegt. Pfad also /srv/mergerfs/Merger/UnimatrixZero/Clips und darin ein Film (The Rock.mp4) abgelegt.

Dann eine Mediathek angelegt, als Typ Film und den Pfad von oben ausgewählt.

Das Video wird erkannt, eingelesen, erscheint mit cover, etc.

Und nein, ich habe für Plex keinerlei ACL gesetzt nur eben via /etc/group plex in die Gruppe Users aufgenommen. Da das share "UnimatrixZero" eben für users Schreib/Leserechte hat incl. Vererbung der Rechte, hat das auch der Ordner Clips.

Edit:

Ich habe immer mehr den Eindruck, dass das mit den ACL wegen fruit:nfs:aces nicht klappt. Wenn das auf yes steht, dann stimmt zwar alles von und zum Mac, aber die ACL werden irgendwie verbogen. Ich kann es nicht erllören, aber nach alledem was ich in den Samba source codes gelesen habe, habe ich das "Gefühl" dass das daran liegt. Wenn man sich die ACL der Ordner (welche vom Mac angelegt wurden) vom NAS aus ansieht, dann sehen die nicht gut aus, nämlich ohne read/write

drwxr-xr-x+  2 lisanet users 4096 Nov 11 18:15 Clips

lisanet@Spacestation:/share/UnimatrixZero $ getfacl Clips
# file: Clips
# owner: lisanet
# group: users
user::rwx
user:lisanet:rwx            #effective:r-x
group::--x
group:users:--x
mask::r-x
other::r-x
default:user::rwx
default:user:lisanet:rwx
default:group::rwx
default:group:users:--x
default:mask::rwx
default:other::r-x

 

[jteschner]

Echt seltsam. Jetzt geht es bei mir.

?? auf einmal??

Folgender Pfad ist mein mergerfs-Dateisystem: /srv/mergerfs/Merger

bei mir: /srv/mergerfs/pool

darauf ist ein Share eingreichtet, Pfad ist dann /srv/mergerfs/Merger/UnimatrixZero

bei mir: /srv/mergerfs/pool/video

Dort habe ich vom Mac via smb einen Ornder Clips angelegt. Pfad also /srv/mergerfs/Merger/UnimatrixZero/Clips und darin ein Film (The Rock.mp4) abgelegt.

bei mir: /srv/mergerfs/pool/video/Film

Dann eine Mediathek angelegt, als Typ Film und den Pfad von oben ausgewählt.

Das Video wird erkannt, eingelesen, erscheint mit cover, etc.

Und nein, ich habe für Plex keinerlei ACL gesetzt nur eben via /etc/group plex in die Gruppe Users aufgenommen. Da das share "UnimatrixZero" eben für users Schreib/Leserechte hat incl. Vererbung der Rechte, hat das auch der Ordner Clips.

Bei mir die Rechte von Ordner "Film" (NICHT ERSCHRECKEN - Ich war irgendwann verzweifelt )
getfacl Film

# file: Film/
# owner: jt
# group: users
# flags: -s-
user::rwx
user:plex:rwx
user:jt:rwx
group::rwx
group:plex:rwx
group:jt:rwx
mask::rwx
other::rw-
default:user::rwx
default:user:plex:rwx
default:user:jt:rwx
default:group::rwx
default:group:plex:rwx
default:group:jt:rwx
default:mask::rwx
default:other::rw-

ls -l

drwxrwsrw-+ 17 jt users 4096 Nov  9 22:17 Film

Ich habe es nun nicht nochmal probiert, aber gestern als ich die Mediathek aufsetzen wollte, konnte ich als Pfad
/srv/mergerfs/pool/video
auswählen und keine Filme wurden gefunden
/srv/mergerfs/pool/video/Film
konnte ich nicht auswählen (ausgegraut)

Evt mache ich morgen nochmal einen Test - heute ist schlecht, da ich gerade ein Full-Backup laufen habe.

 

[jteschner]

noch zwei Bilder aus Plex:

video lässt sich auswählen - und dann:

ausgegraut.
Nebenbei: ich habe die Videos nicht vom MBP übertragen, sondern direkt von der Syno nach Raspi
Kann natürlich sein, dass es was mit den ACLs zu tun hat.
Nur, was soll ich tun außer mit Plex nochmal neu zu beginnen ...
Nun gut, ich könnte die ACLs für video rekursiv rausnehmen, Plex in die user-Gruppe nehmen und die Posix Rechte geradebiegen
Hauptsache meine Mediatheken sind dann noch gefüllt ...

 

[lisanet]

Nur, was soll ich tun außer mit Plex nochmal neu zu beginnen ...

nichts neu beginnen, nichts rekursiv ändern, sondern in /etc/groups plex der group 'users' hinzufügen. Wenn deine Ordner "Film" etc auch alle ja die korrekten Unix-Rechte haben, also dem omv-Standard entsprechen "rwxrwsr-x", und Gruppe users ist, dann klappt das.

Das ist nun genau das, was ich eigentlich vermeiden wollte: Die Lösung ist da, aber wir schreiben ellenlang über ACL und Co, die nichts mit der Lösung zu tun haben.

 

[lisanet]

?? auf einmal??

yep. Das erinnert mich an alte bugs in Plex: wenn da mal ein File nicht gefunden wurde, dann war das in den Caches so enthalten und man hat da nr dann wieder zum laufen gebracht, wenn man die Caches geleert hat und Plex neu gestartet hat. Vielleicht ist davon immer noch was übrig. Bei 2. Test habe ich nämlich einen neuen Ordner angelegt und denn anders genannt. Vielleicht war es das.

 

[jteschner]

nichts neu beginnen, nichts rekursiv ändern,

Aber die Rechte sind doch so verbogen (s.o.). Sollte ich da nichts dran ändern?? zB was ich in der ACL "verbogen" habe (alle Ordner und Dateien in dem OMV-Freigegebenen-Ordner)

sondern in /etc/groups plex der group 'users' hinzufügen. Wenn deine Ordner "Film" etc auch alle ja die korrekten Unix-Rechte haben, also dem omv-Standard entsprechen "rwxrwsr-x", und Gruppe users ist, dann klappt das.

Ich habe ja den ls -l output oben gezeigt - das sieht alles andere als "richtig" aus.
Den plex-user kann ich natürlich in die Gruppe tun - kein Thema

Das ist nun genau das, was ich eigentlich vermeiden wollte: Die Lösung ist da, aber wir schreiben ellenlang über ACL und Co, die nichts mit der Lösung zu tun haben.

Verstehe ich sehr gut ... das ist auch alles andere als einfach

 

[lisanet]

Den plex-user kann ich natürlich in die Gruppe tun - kein Thema

Dann tu das bitte endlich.

Edit und letzte Hilfe:

prüfe die Unix-Rechte deiner Filem-Dateien. Nicht dass die noch durch das Kopieren von der Synology keine Gruppenrechte aufweisen (das könnte ich mir nämlich gut vorstellen)