NFS wäre ja auch noch. Das funktioniert unter MacOS auch und vermutlich besser als das veraltete AFP.
Auf das Verzeichnis wird auch von einer VM mit Windows Server zugegriffen, und NFS funktioniert unter Windows nicht befriedigend, braucht also SMB. Das gleiche Verzeichnis sowohl per NFS als auch per SMB freizugeben, macht nur Ärger mit den Rechten. AFP und SMB vertragen sich hingegen gut. Also bleibt AFP.
Auch wenn das nicht direkt die Frage beantwortet:
Kodi gibt es als eigenes Paket auf qnapclub.eu direkt für das NAS. Damit bräuchtest du die Linux-Station nicht mehr und dein Problem könnte gelöst werden.
Ich selbst kenne das Kodi-Package nicht, aber ich denke, es ist einen Versuch wert.
Danke für deine Tests.
Dann weiß ich schon mal, dass es nicht an einer vermurksten Einstellung bei mir liegt, sondern allgemein so ist.
Also wenn Du nach jedem Löschen die Netzwerkfreigabe neu mappst, würde es theoretisch auch mit SMB funktionieren.
Na da ist dann AFP doch das geringere Übel.
Mir ist auch aufgefallen, dass die Dateinamen irgendwann doch wieder verwendet werden konnten. Ich hatte auch schon mit den Einstellungen zum SMB-Cache herumgespielt, aber die hatten keine Auswirkungen.
Systemsteuerung -> Netzwerk und Dateidienste -> Netzwerkpapierkorb
Läuft die Multimedia-Console?
Sind dort die Verzeichnisse konfiguriert?
Ist DLNA eingeschaltet?
Sind die erweiterten Einstellungen (= Mediastreaming Addon) korrekt? Wenn ich mich richtig erinnere, war hier irgendeine Einstellung in den Voreinstellungen falsch.
erhalte ich die Meldung, dass es bereits ein BackUp gibt und ob ich das verwenden möchte.
Wenn du weißt, dass dieses Backup vor nicht zu langer Zeit mit demselben Mac erstellt worden ist, dann kannst du die Frage abnicken.
und dort gebe ich die erwähnten Einträge aus dem Dienst "TimeMachin" in der HBS ein, oder ist das grundsätzliche Login bei der Anmeldung auf dem NAS gefragt?
Auf dem NAS hast du einen User angelegt, der für die TM-Backups benutzt wird. Dies kann ein spezieller User nur für Backups sein (das würde ich empfehlen), es kann dein normaler User sein, mit dem du z. B. die Freigaben des NAS auf dem Mac mounten kannst, und es kann auch der Admin sein (würde ich nicht machen). Name und Passwort dieses Users musst du angeben.
Ohne Garantie auf Richtigkeit, da ich selbst keine SED-Verschlüsselung nutze:
zu
1.
Das sollte so sein, aber das Passwort wirst du für die neue SED festlegen müssen.
2.
Davon ist auszugehen.
3.
Nein, sonst wäre die ganze Verschlüsselung sinnlos.
4.
Keine Probleme. Aus der Sicht des Backup-Programmes ist die Verschlüsselung transparent. Das kriegt davon nichts mit.
Ob die Selbstverschlüsselung in der Praxis funktioniert, hängt wegen der Punkte 1. und 2. entscheidend davon ab, wie qts diese Selbstverschlüsselung unterstützt. Ich würde keine SEDs nehmen, die nicht von QNAP offiziell mit diesem Feature unterstützt wird.
Mit modernen Prozessoren, welche Hardwareunterstützung für die Verschlüsselung anbieten, ist der Geschwindigkeitsverlust durch die Verschlüsselung in Software derart gering, dass ich auf Hardwareverschlüsselung durch die SSD verzichte. Damit handelt man sich eher Probleme ein. Softwareverschlüsselung hat den Vorteil, überall gleich zu sein und ist deswegen besser getestet.
Mir ist das jetzt hier auch aufgefallen, und zwar mit der neuesten Version 5.0.1.2346.
Es sieht so aus, als sei bei "Synchronisation" die Logik hinter der Checkbox genau vertauscht. Bei "Sichern und Wiederherstellen" ist hingegen die Logik korrekt.
Ich synchronisiere mit einem externen NAS über das rsync-Protokoll. Es kann sein, dass andere Sicherungsziele dieses Verhalten nicht zeigen.
Ursprünglich war "Dateiinhalte prüfen" ausgewählt. Das ist wohl Vorgabe bei der Neuanlage eines Synchronisationsjobs.
Am 15. 4. habe ich die Checkbox abgewählt, damit die Synchronisierung schneller geht. Danach wurden dann alle Daten übertragen mit dem Ergebnis, dass der Job viel länger dauert (ich habe noch einen anderen Job mit dem 1000-fachem Volumen, der dann mehrere Tage bräuchte).
Heute, d. h. am 17. 4., habe ich "Dateiinhalte prüfen" wieder angekreuzt, und damit sind die Übertragensvolumina und -zeiten wieder normal.
elvislein hatte also Recht in seiner Beobachtung.
Kann noch jemand das Problem nachvollziehen? Dann würde ich den Fehler dem Support melden.
Danke für das Testen.
Dann muss ich mal mit Monterey booten und testen, ob ich da auch dieses Verhalten habe. Dann ist das schon mal ein Hinweis, ob das an der BS-Version liegt oder irgendwas auf meinem System. (Allerdings kann ich den TEst nicht sofort machen, weil ich dazu meinen Arbeitsplatzrechner brauche.)
An bash/zsh liegt es nicht. Geht der Zugriff nicht über die Shell, tritt das Problem auch auf.
Antwort 18. 4.:
Ich habe mittlerweile noch einige Tests vorgenommen.
Test an einem anderen Rechner mit High Sierra => Fehler tritt auf.
Test mit Monterey und SMB => funktioniert
Test mit High Sierra und AFP => funktioniert.
Es scheint an Apples SMB-Implementation in High Sierra zu liegen. Wobei das nicht sicher ist, es kann auch eine seltsame Konfiguration sein, beide High-Sierra-Rechner stammen von derselben Basis ab.
Ich werde das Problem lösen, indem ich die fragliche Freigabe mit AFP einbinde. Mit Monterey laufen ein paar wichtige Programme nicht. (Ich hasse Apple dafür, immer wieder so viele alte Zöpfe anzuschneiden. 
)
Falls doch noch jemand eine Lösung für High Sierra und SMB kennt, her damit.
P. S.: Wie kann man verhindern, dass das Forum ungefragt Beiträge zusammenfügt?
Neuladen / aktualisieren im Finder hilft nicht?
Nein. Im Finder sieht man sogar (ohne aktualisieren), wie die Datei verschwindet, wenn sie auf qts-Seite gelöscht wird.
Davon abgesehen kommt der Finder in dem Problemszenario nicht vor. Zum Tragen kommt das in einem proprietären Programm, aber genauso beobachten lässt es sich, wie im Eingangsbeitrag gezeigt, im Terminal. Dort lässt sich mit ls auch feststellen, dass die Datei nicht existiert, und doch kommt bei der Neuanlage "Permission denied".
War das Problem auch schon in der vorherigen QTS Version?
Unbekannt. Die Anwendung, bei der das Problem Ärger macht, nutze ich erst, nachdem die letzte qts-Version installiert wurde. Ich denke aber nicht, dass es an der letzten qts-Version liegt, denn in dem Umfeld hat es keine Änderungen gegeben.
Ist das Problem auch mit dem Finder reproduzierbar?
Das Problem tritt mit jedem Programm auf, das versucht, die Datei mit dem gerade gelöschten Dateinamen zu beschreiben, also auch mit dem Finder.
Folgendes Problem: SMB-Freigabe am Mac gemounted, Datei wird erst am Mac erzeugt, dann auf dem NAS gelöscht. Danach ist es nicht möglich, erneut eine Datei mit demselben Namen anzulegen,
"Permission denied"kommt.
Jetzt noch mal komplett mit Code:
1. Auf dem Mac wird eine neue Datei angelegt.
[auf dem Mac-Book]
$ cd /Volumes/freigabe/tmp
$ pwd
/Volumes/freigabe/tmp
$ >xxDamit ist eine Datei xx angelegt.
2. Diese wird jetzt auf dem NAS gelöscht.
[auf dem Qnap NAS]
$ cd /share/freigabe/tmp
$ pwd
/share/freigabe/tmp
$ ll xx
-rwxrwxrwx 1 User everyone 0 2023-04-15 18:07 xx
$ rm xx3. Jetzt ist es auf dem Mac nicht mehr möglich, erneut eine Datei desselben Namens anzulegen.
[auf dem Mac-Book]
$ >xx
-bash: xx: Permission deniedDie Meldung
"Permission denied"ist Unsinn, denn an den Rechten liegt es nicht. In Schritt 1 ging es ja.
Wähle ich einen anderen Namen, geht es weiterhin.
Verwendete Systeme:
MacBook mit High Sierra 10.13.6.
Qnap TS-877 mit QTS 5.0.1.2346
Wenn ich in Schritt 2. die Datei nicht auf dem NAS, sondern über Linux oder Windows (wo die Freigabe ebenfalls gemounted ist) lösche, tritt der Fehler ebenfalls auf.
Wenn ich in Schritt 2. die Datei auf dam Mac selbst lösche, tritt der Fehler nicht auf.
Wenn ich in Schritt 1. und 3. keinen Mac, sondern Linux oder Windows verwende, tritt der Fehler nicht auf.
Kann ein Mac-Besitzer dieses Verhalten reproduzieren?
Hat jemand eine Idee, woran es liegt?
Mod: Unnötiges Direktzitat entfernt! 
Forenregeln beachten und Die Zitat Funktion des Forums richtig nutzen
Das ist genau falsch. Die TB-Bridge muss vor dem Wlan sein.
Welche IP-Adressen und Subnetze hast du denn für die beiden Anschlüsse vergeben?
am pc ist eine 5gbit karte drin. Wird auch als 5gbit angezeigt wenn es im 10gbit Switch steckt.
Dennoch sieht es so aus, als hätten Switch und Karte nur Gigabit ausgehandelt.
Dies kann ein Kabelproblem sein, aber es kann auch eine Inkompatibilität zwischen Switch und PC-Karte bzgl. 5GbE sein.
iperf3 ist ein Programm, welches es auf qnapclub.eu (im App-Center als anderen Store hinzufügen) gibt. Dies misst die reine Netzwerkgeschwindigkeit ohne Einfluss durch Festplatten/SSDs.
Üblicherweise wird die Datenübertragung vom Client (= Mac/PC) aus angestoßen. Also muss auch dort die Auswahl des Netzwerkadapters erfolgen. Vielleicht gibt es auch Switche, die das können. Das NAS selbst kann das nicht, sondern das muss den Adapter bedienen, von dem die Daten kommen (die könnten ja in verschiedenen LANs hängen).
mit extremen Durchhangeln zu den Ordnern
Das liegt dann aber an dem Medienserver.
DLNA "mochte" ich noch nie, [...]
Deswegen bin ich bei Emby gelandet
DLNA hat den Vorteil, dass es ein Standard ist. Wenn da eine Komponente (Programm oder Gerät) eine Funktion nicht hat, sucht man sich eine andere Komponente, welche die gewünschte Funktion hat. So bietet (so wie ich das sehe) Emby keine Möglichkeit, Musik-Streaming von Qobuz zu machen. Mit DLNA findet man hingegen ein Programm, welches das kann.
Emby ist ein geschlossenes System. Solange man nur Emby-Komponenten hat, funktioniert das dafür problemloser. Fremdkomponenten können oft nicht angebunden werden, außer Emby bietet das an (und da nutzt Emby dann auch DLNA).
In der Praxis sieht das mit DLNA leider nicht so rosig aus, wie es klingt. Der Standard ist lange nicht so sauber implementiert, wie man sich das wünscht. Man braucht ziemlich lange, bis man ein System hat, das vernünftig funktioniert, und da meine ich schon so scheinbar triviale Funktionen wie Abspielen der Titel in der richtigen Reihenfolge, Positionierung innerhalb eines Titels, Übergang der Titel ohne vorzeitigen Abbruch und ohne störende Lücke.
(Hinweis: Ich nutze DLNA für Musikwiedergabe, mit BubbleUpnp und gmrender-resurrect auf dem Mac, Anschluss per DAC an die Stereoanlage, Streaming von Qobuz und einem Qnap-Medienserver und Fernsteuerung mit Linn Kazoo auf dem Android-Tablet. Funktioniert gut, aber es hat ziemlich gedauert, all diese Komponenten zu finden - ich musste viel experimentieren.)
Nur wie lösch ich die Sachen jetzt?
Ohne genaue Fehlermeldung kann da niemand was zu sagen.
dass man regelmäßig den Netzwerkpapierkorb leeren soll um genug Speicher zu haben. Sollte das nicht automatisch überschrieben werden?
Nein, der wird nicht automatisch überschrieben. Die Dateien bleiben im Papierkorb, bis du diesen entleerst.
Du kannst alternativ auf den Papierkorb verzichten, dann werden die Dateien sofort gelöscht. (Das mache ich, mich nervt die Papierkorbfunktion nur.)
DLNA ist per se ein sehr unsicheres Protokoll, da es keinerlei Autorisierung zwischen Server und Client vorsieht.
Ich könnte ohne jede Probleme meinem Vater, der ein Stockwerk tiefer wohnt, auf seinen Internetradioempfänger "Best of Death Metal" schicken, und seine einzige Möglichkeit, sich dagegen zu wehren, bestünde darin, den Stecker zu ziehen.
Umgekehrt kann jeder hier im LAN sämtliche Musikstücke von meinem DLNA-Server hören und runterladen, ohne dass ich es verhindern kann, es sei denn, ich schalte den Server ab.
In einem geschlossenen LAN, in dem alle Nutzer einander vertrauen, kann man aber mit den Einschränkungen leben und DLNA nutzen. Letztlich werden Musik- und Videodateien übertragen, die in dem Umfeld idR. keine Geheimnisse enthalten. Wenn jemand jedoch Fotos oder Videos hat, die selbst der Partner nicht sehen darf, ist DLNA nicht zur Freigabe geeignet.
Ein echtes Sicherheitsproblem hätte man, wenn es über eine fehlerhafte Implementierung eines DLNA-Servers oder -Clients möglich wäre, auch auf andere nicht freigegebene Dateien des Gerätes zuzugreifen. Das wäre aber keine Lücke von DLNA selbst, sondern ein Fehler einer konkreten Implementierung. Solche Fehler sind mir nicht bekannt, was aber nichts heißt.
Ob Plex & Co. diesbezüglich besser sind, weiß ich nicht. Ich habe mich mit den DLNA-Alternativen nicht beschäftigt. Der Vorteil von DLNA ist, dass DLNA ein Standard ist und kein proprietäres Protokoll.
.... Trotzdem wieder ein Ding was gestartet und gestoppt werden will, wenn reboot ansteht...
Warum? Lass es doch immer gestoppt, dann wird es auch nach Reboot nicht gestartet. Das habe ich mit der Helpdesk-App auch gemacht.
