Anzeige:
Ergebnis 1 bis 3 von 3

Thema: Mountpunkt eines Samba andere Dateirechte zuweisen

  1. #1
    @SlopePointNZ Avatar von craano
    Registriert seit
    Jul 2004
    Beiträge
    1.313

    Mountpunkt eines Samba andere Dateirechte zuweisen

    Hallo,

    ich mount unter einem Kubuntu 10.4 ein Samba Share.

    Die Freigabe ist ein Gastzugang im lokalen Netz, auf die jeder zugreifen dürfen soll.
    Code:
    [Gast]
            comment = Gastfreibe ohne Passwort
            path = /sambagast
            read only = No
            create mask = 0777
            force create mode = 0777
            directory mask = 0777
            force directory mode = 0777
            guest ok = Yes
    Welche Dateirechte gesetzt werden sollen, wenn eine neue Datei erstellt wird, kann ich mit den Maskierungseinstellungen im obigen Beispiel festlegen.
    Aber wie kann ich es bestimmen, welche Dateirechte der Mountpunkt selbst bekommt?
    Code:
    sudo mount -t cifs //10.8.1.1/Gast /mnt/cifs/ -o guest,umask=0000
    Leider wird die umask Option "ignoriert" und der Mountpunkt bekommt immer 755er-Rechte.
    [CODE]
    Hallo,

    ich mount unter einem Kubuntu 10.4 ein Samba Share.

    Die Freigabe ist ein Gastzugang im lokalen Netz, auf die jeder zugreifen dürfen soll.
    Code:
    [Gast]
            comment = Gastfreibe ohne Passwort
            path = /sambagast
            read only = No
            create mask = 0777
            force create mode = 0777
            directory mask = 0777
            force directory mode = 0777
            guest ok = Yes
    Welche Dateirechte gesetzt werden sollen, wenn eine neue Datei erstellt wird, kann ich mit den Maskierungseinstellungen im obigen Beispiel festlegen.
    Aber wie kann ich es bestimmen, welche Dateirechte der Mountpunkt selbst bekommt?
    Code:
    sudo mount -t cifs //10.8.1.1/Gast /mnt/cifs/ -o guest,umask=0000
    Leider wird die umask Option "ignoriert" und der Mountpunkt bekommt immer 755er-Rechte.
    Code:
    craano@kubuntu-laptop:/mnt$ ls -l
    insgesamt 8
    drwxr-xr-x 5 nobody nogroup    0 2011-01-26 16:44 cifs
    Ein nachträgliches chmod hilft zwar:
    Code:
    $ ls -l
    insgesamt 8
    drwxrwxrwx 5 nobody nogroup    0 2011-01-26 16:44 cifs
    Doch leider ist das sehr umständlich, wenn ich per fstab beim Systemstart boote.

    Weiß jemand, wie man mount beibringen kann die Rechte des Mountpunktes anders zu setzen?

    Eigentlich möchte ich die obigen Maskierungen in der smb.conf nicht verwenden, weil dann alle Dateien mit vollen Rechten angelegt werden. Aber ohne die kann ich auf der Konsole leider keine Dateien anlegen. Wenn ich allerdings mit Dolphin >10.8.1.1 > Gast anbrowse, dann kann ich den Inhalt der Freigabe sehen und auch Dateien anlegen. Diese Dateien haben dann die folgende Rechte
    Code:
    $ pwd
    /mnt/cifs
    craano@kubuntu-laptop:/mnt/cifs$ ls -l
    insgesamt 0
    drwxr-xr-x 2 nobody nogroup 0 2011-01-26 17:04 Neuer Ordner
    Dabei habe ich vorher alle Maskierungen in der smb.conf auskommentiert und Samba neugestartet.
    Wie kann ich dieses Verhalten von Dolphin beim mounten auf der Konsole immitieren?

    [EDIT]
    Der Windows Explorer (WinXP) verhält sich genauso wie Dolphin.
    Die Dateien werden als nobody.nogroup mit 755 angelegt, obwohl keine Maskierungsregeln in der smb.conf vorhanden sind.
    Kann ich irgendwie das Share auf der Konsole mounten, dass unter einem normalen User angelegte Dateien genauso angelegt werden wie unter den grafischen Tools?
    [/EDIT]

    Grüße.
    craano
    Geändert von craano (26.01.11 um 16:41 Uhr)

  2. #2
    Banned
    Registriert seit
    Dec 2010
    Beiträge
    354
    Ein nachträgliches chmod hilft zwar:
    [...]
    Doch leider ist das sehr umständlich, wenn ich per fstab beim Systemstart boote.
    Ein Workaround wäre, den chmod nochmals automatisch z.B. per /etc/rc.local ausführen zu lassen, wenn das nachträglich noch reicht (ggf. passende Remount-Zeile nachschieben).

    Aber das ist natürlich keine saubere, dauerhafte, wie von dir gewünschte "full-featured" Lösung!

    Eine gute SAMBA-Lösung überlasse ich den erfahreneren Netzwerk- und Samba-Kennern, doch bis dahin...
    Geändert von Dodobo.reloaded (26.01.11 um 17:25 Uhr)

  3. #3
    @SlopePointNZ Avatar von craano
    Registriert seit
    Jul 2004
    Beiträge
    1.313
    Zitat Zitat von Dodobo.reloaded Beitrag anzeigen
    Ein Workaround wäre, den chmod nochmals automatisch z.B. per /etc/rc.local ausführen zu lassen, wenn das nachträglich noch reicht (ggf. passende Remount-Zeile nachschieben).
    Natürlich kann ich bei Debian basierten Distributionen die rc.local verwenden und die Verzeichnisrechte neu setzen. Seltsamerweise merkt sich Kubuntu soger das chown, denn beim nächsten mount stehen die Rechte dann auf 777.
    Es handelt sich auch nur um eine handvoll Rechner hier bei mir zu Hause. Das Problem ist damit allerdings nur halb gelöst.
    Ich verstehe nicht, wie Dolphin/WinExplorer das machen als ein User (craano) in ein Verzeichnis (755) zu schreiben und dann Dateien unter dem anderen User (nobody.nogroup) Dateien anzulegen. Gut das nobody.nogroup erklärt sich durch das Samba bad user mapping. Aber die Konsole verweigert sämtliche Schreibrechte in / an den "bad user gemapppten" Ordner / Dateien.

    Grüße
    craano

Ähnliche Themen

  1. Samba - Dateirechte
    Von rolandul00 im Forum Linux als Server
    Antworten: 7
    Letzter Beitrag: 20.05.10, 05:59
  2. Linux-Win Netzwerk per Samba
    Von g@Me|mX im Forum Linux in heterogenen Netzen
    Antworten: 3
    Letzter Beitrag: 07.05.05, 18:00
  3. samba dateirechte
    Von msi im Forum Linux in heterogenen Netzen
    Antworten: 8
    Letzter Beitrag: 18.08.03, 11:48
  4. Dateirechte unter Samba
    Von Montague im Forum Linux in heterogenen Netzen
    Antworten: 2
    Letzter Beitrag: 23.02.02, 17:56
  5. Dateirechte unter Linux und Samba
    Von Montague im Forum Linux Allgemein
    Antworten: 2
    Letzter Beitrag: 15.07.99, 18:28

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •