mount von smb share funktioniert nicht mehr

    Hallo zusammen,


    ich mounte seit Jahren vom meinem Raspi ein SMB Share auf der QNAP für die tägliche Datensicherung.


    Seit dem Update auf die Version 5 funktioniert das nicht mehr, Fehler ist ein "Permission denied".


    Bis dato verwende ich hier einen von mir angelegten Serviceaccount svc-script (Domänenbenutzer), der Rechte auf dem Share hat.


    Mit dem admin funktioniert das mounten noch, mit dem Serviceaccount leider nicht mehr.


    Welche Rechte könnten hier fehlen?

    Freigaberechte und Filerechte nicht, das habe ich überprüft.


    Applikationsrechte habe ich temporär alle gegeben, auch das bringt keine Änderung.


    Schon mal Danke für Eure Tipps im Voraus.


    Gruß

    Warum mountet man ein QNAP share auf einem Pi mit SMB!?

    Beides ist Linux basiert, warum nicht per nfs mounten?


    Mein Pi greift per nfs auf einen QTS 5 share und hat keine Probleme damit.

    SMB müsste ich testen, sehe aber, wie o.a. keinen Sinn darin.


    Gruss


    Edit: Möglicherweise meinst Du es genau umgekehrt, SMB Share auf dem Pi? Der Satz ist leider etwas "unscharf" formuliert und läßt beide Interprettionen zu.

    Aber auch dann: warum nicht per nfs?

    Weil ich SMB sowieso für den Zugriff von den PCs verwende.


    Somit müsste ich nur für die Datensicherung noch NFS einrichten und Rechte verwalten.


    Das macht keinen Sinn...

    Ok, mein Edit hat sich mit der Antwort überschnitten.

    Also das Share ist auf der QNAP?


    Gruss


    Edit: Ich muss es leider bestätigen, ein SMB mount mit einem "Nicht-admin" User ist zwar möglich, aber schreiben oder löschen nicht.

    Das endet jeweils mit "Permission denied". Mit einem NAS, auf dem QTS 4.3.4 läuft, tritt dieser Fehler nicht auf.

    Das Filesystem selbst wird als "rw" ausgewiesen, es sind also die individuellen User Rechte, die unter QTS 5.0 anders sind.

    Dabei ist es egal, ob man mit SMB v3 oder v1 mountet.


    Edit2: Interessanter Nebeneffekt:

    Als "admin" gemountet und einen touch test gemacht, dann umount und als "normaler" user wieder gemountet.

    Mit vi kann die Datei test nun bearbeitet und gespeichert(!) werden, aber weder umbenannt noch gelöscht.

    Scheint, das hier einige nfs/SMB Inkompatibiltäten vorliegen. Das ist mir wieder mal ein Ticket wert. :(

    4 Mal editiert, zuletzt von FSC830 ()

    Ich sicher meinen Raspi auf einem Share auf der QNAP. D.h. der mount wird auf dem Raspi ausgeführt und mountet ein SMB Share auf der QNAP

    Und womit sicherst Du den Pi (ist jetzt zwar OT, aber interessiert mich dennoch)?


    Gruss

    So, nachdem ich endlich Zeit hatte, mich um das in #4 genannte Problem zu kümmern, das sich bis heute permanent durchgezogen hat, muss ich leider sagen, es lag offenbar nicht direkt am QTS 5.0.


    Nachdem das Problem auch nach dem heutigen Update auf 5.0.0.1932 vorhanden war, habe ich das Share (nicht die Daten) kurzerhand gelöscht und wieder angelegt.

    Danach habe ich die identischen Einstellungen/Berechtigungen wie zuvor gemacht, und nun konnte ich auf dem Pi problemlos Dateien anlegen. löschen, umbenennen.

    Also gleiches Verhalten wie auf dem Share von QTS 4.3.4.

    Offenbar ist beim ersten Anlegen des Shares irgendwo ein "Bit gekippt"...:huh:


    Fazit: man kann ein SMB share als User - der nicht zur Admin Gruppe gehört - mounten und auch Dateien schreiben/löschen.

    Der o.a. Fehler tritt nicht mehr auf.

    Darauf gekommen, das es kein allgemeines Problem ist, bin ich dadurch das auf einem anderen (auch schon länger existierendem) Share mit identischen Einstellungen alles ging.

    Danach war klar, das es am Share lag, warum auch immer. Die Geheimnisse der Bits und Bytes 8).


    Gruss