SMB-Freigabe: Dateiname bleibt nach löschen gesperrt, Permission denied

    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,

    Code
    "Permission denied"

    kommt.


    Jetzt noch mal komplett mit Code:


    1. Auf dem Mac wird eine neue Datei angelegt.

    Code
    [auf dem Mac-Book]
$ cd /Volumes/freigabe/tmp
$ pwd
/Volumes/freigabe/tmp
$ >xx

    Damit ist eine Datei xx angelegt.


    2. Diese wird jetzt auf dem NAS gelöscht.

    Code
    [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 xx


    3. Jetzt ist es auf dem Mac nicht mehr möglich, erneut eine Datei desselben Namens anzulegen.

    Code
    [auf dem Mac-Book]
$ >xx
-bash: xx: Permission denied


    Die Meldung

    Code
     "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?

    Zitat von Anthracite

    MacBook mit High Sierra 10.13.6.

    Noch jemand mit so einem alten Mac unterwegs. :)


    Ist das Problem auch mit dem Finder reproduzierbar?


    So spontan würde ich sagen, dass das "Inhaltsverzeichnis" nicht aktualisiert wird. In den Dateibrowsern gibt es dafür ja die Funktion "Aktualisieren" bzw. "Neuladen". Weiß jetzt gerade nicht, ob dies der Finder auch hat.

    Zitat von Mavalok2

    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.

    Neuladen / aktualisieren im Finder hilft nicht?


    War das Problem auch schon in der vorherigen QTS Version? Meine Test-NAS sind im Moment eine Version zurück oder eine davor (5.1.0 Beta). Dann müsste ich erst mal Updaten. Aber das zurück ist ein ARM. Downgrade möchte ich eher vermeiden. Werde es mal mit dem ARM versuchen - oder auch zusätzlich mit der Beta. Wird aber vermutlich Dienstag oder Mittwoch werden - Nachtschicht in der Firma steht an, sprich Rollout von Software.

    Zitat von Mavalok2

    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".

    Zitat von Mavalok2

    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.

    Moin!


    Ich bin jetzt auch einmal dazu gekommen diesen Test auszuführen.

    Umgebung: Mac mini M1 mit macOS 13.3.1, QNAP TS 453-D mit 5.0.1.2346


    auf dem Mac im Terminal:

    cd /Volumes/Medien (per SMBv3 gemountete Freigabe vom QNAP)

    >xx (und dann CTRL-C)

    Datei ist angelegt und ich sehe als Rechte: 700 für mich.


    auf dem QNAP (über das Mac Terminal mit ssh angemeldet):

    cd share/Medien

    die Datei ist dort mit den Rechten 666 für meinen admin Benutzer

    rm xx (klappt problemlos)


    auf dem Mac:

    ls -al

    Datei ist nicht da.

    >xx (und dann wieder CTRL-C)

    Datei ist wieder mit den gleichen Rechten wie oben angelegt


    Also hier gibt es überhaupt keine Probleme mit der ganzen Sache. Was mir aber auffällt, ist, daß oben die Fehlermeldung von einer "bash" ist. Das Standard-Terminalprogramm vom Mac ist eigentlich seit ein paar Versionen die "zsh".


    Ich habe das Gleiche auch mit meinem Lieblingsbefehl zum Erzeugen von neuen Dateien "touch xx" ausprobiert und komme zum gleichen Ergebnis.

    Auch mit dem Finder passiert bei mir genau das Gleiche. Die Datei ist weg und der Name kann sofort wieder benutzt werden.

    carsten_h

    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. :cursing: )


    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?

    6 Mal editiert, zuletzt von Anthracite ()

    Anthracite

    Habe Dein Szenario mal nachgestellt, mit MacBook HighSierra 10.13.6 und TS-328 und QTS 5.0.1.2277 (also die vorletzte Version). Selbes Problem wie bei Dir. Ist also nicht mit der aktuellen QTS 5.0.1 Version aufgetaucht, noch auf ein bestimmtes NAS-Modell begrenzt - TS-328 ist ein ARM Modell. Scheint wirklich am MacOS zu liegen.


    Ein "Aktualisieren" scheint es beim Finder übrigens nicht so geben. Ein Unmount mit anschließendem Mount hilft allerdings. Äh, hmm?


    Um das Ganze noch etwas - ähm - spannender zu machen, betrifft dies Ordner jedoch nicht. Ordner können ohne Problem gelöscht und wieder hergestellt werden. Ist jedoch eine Datei in diesem Ordner, wird zwar der Ordner erstellt, aber die Datei darin nicht. Äh, hä??? Wer bei Apple hast sich denn diesen Gag einfallen lassen. :rolleyes:


    Also wenn Du nach jedem Löschen die Netzwerkfreigabe neu mappst, würde es theoretisch auch mit SMB funktionieren. 8)

    Mavalok2

    Danke für deine Tests.

    Dann weiß ich schon mal, dass es nicht an einer vermurksten Einstellung bei mir liegt, sondern allgemein so ist.

    Zitat von Mavalok2

    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.

    Ich habe den Verdacht, dass MacOS das Verzeichnis nicht wirklich aktualisiert, auch wenn es im Finder oder auch auf der Konsole so aussieht.

    Zitat von Anthracite

    Na da ist dann AFP doch das geringere Übel.

    NFS wäre ja auch noch. Das funktioniert unter MacOS auch und vermutlich besser als das veraltete AFP. Bei AFP wurde die Entwicklung vor 11 Jahren eingestellt.

    Apple Filing Protocol – Wikipedia

    Zitat von Mavalok2

    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.

    Zitat von Anthracite

    und NFS funktioniert unter Windows nicht befriedigend

    Schon länger nicht mehr versucht. Werden wohl auch wenige von Windows zu Windows benutzen.

    Zitat von Anthracite

    Das gleiche Verzeichnis sowohl per NFS als auch per SMB freizugeben, macht nur Ärger mit den Rechten.

    Hmm, habe ich bei den meisten NAS bei mir so eingerichtet. Allerdings kein zeitgleicher Zugriff von NFS und SMB. Finde NFS von Linux nach Linux geht einfach besser. Aber stimmt, die Rechte die können schon mal etwas dabei zicken.

    Zitat von Anthracite

    AFP und SMB vertragen sich hingegen gut.

    Schon lange kein AFP mehr verwendet, auch mit MacOS. Ich glaube, das war das letzte Mal noch mit der 9er Version von MacOS und auf Mac-Server. Ja, es gab mal Zeiten, da gab es so etwas. Und nicht einfach ein MacMini mit Ordnerfreigabe-Funktion oben darauf geklatscht. War ein eigenes Server Betriebssystem. Aber sind wir mal ehrlich, war damals schon Server für Arme für viel Geld. :D