Etch: Samba-Freigabe auf per NFS gemountetes Verzeichnis

[HeikoSch]

Hallo Miiteinander,

leider folgt eine ziemlich lange Problembeschreibung - schon einmal sorry dafür Nur möchte ich mich so exakt wie möglich ausdrücken ...

Folgende (zugegeben nicht optimale) Situation:

Server C:
eth0: 192.168.10.242
Ubuntu 6.06
NFS-Freigabe: /data/cover

/etc/exports

Code: Alles auswählen

/data/cover           192.168.10.0/255.255.255.0(sync,rw,no_root_squash)

Server S:
eth0: 192.168.10.200
Debian 4.0
NFS-Freigabe von Server C nach /data/cover gemountet
/etc/fstab:

Code: Alles auswählen

192.168.10.242:/data/cover  /data/cover   nfs rsize=8192,wsize=8192,hard,intr     0   0

Samba Freigabe:

Code: Alles auswählen

[global]
        workgroup = DEVELOP
        server string = HP ML350
        security = SHARE
        # security = user 
        # obey pam restrictions = Yes
        # passdb backend = tdbsam
        # passwd program = /usr/bin/passwd %u
        # passwd chat = *Enter\snew\sUNIX\spassword:* %n\n *Retype\snew\sUNIX\spassword:* %n\n .
        syslog = 0
        log file = /var/log/samba/log.%m
        max log size = 1000
        deadtime = 15
        socket options = TCP_NODELAY SO_SNDBUF=8192
        load printers = No
        show add printer wizard = No
        ldap ssl = no
        panic action = /usr/share/samba/panic-action %d
        invalid users = root
        wide links = No
        time server = Yes 
        share modes = yes
        wins support = yes
        guest account = nobody

[HP-Server]
        comment = Fileserver
        path = /data
        read only = No
        create mask = 0666
        directory mask = 0777
        guest ok = Yes
        hide dot files = No

Anmerkung
(1): user=share ist leider so gewünscht.
(2): Server C kann nicht als extra Share angeboten werden, da die Applikation, welche auf die Daten zugreifen soll, nur einen Laufwerksbuchstaben verwalten kann Ansonsten hätte ich auf dem Server C ein Samba installiert und fertig.

Problem
Bis Debian 3.1 lief alles wunderbar. Seit dem Update auf Debian 4.0 können die Windows XP User nicht mehr über die Samba-Freigabe etwas in das Verzeichnis "/data/cover/..." kopieren (lesen, löschen und das Anlegen/Löschen von Verzeichnissen funktioniert). Folgende Fehlermeldung erscheint bei den Windows XP-Clients:

Code: Alles auswählen

Der Prozess kann nicht auf die Datei zugreifen, da ein anderer Prozess einen Teil der Datei gesperrt hat.

Gesperrt ist definitiv nichts.

Folgendes habe ich bisher versucht:
* Windows XP-User: anlegen/löschen von leeren Dateien/Verzeichnissen in /data/cover -> keine Probleme
* Windows XP-User: löschen von Dateien in /data/cover -> keine Probleme
* Windows XP-User: direktes Editieren von Text-Dateien z.B. "/data/cover/test.txt" -> nachdem man eine Fehlermeldung weggeklickt hat, klappt es
* Samba-Freigabe mittels smbfs auf einem Linux-PC gemountet und über diesen Weg versucht Dateien in das Verzeichnis /data/cover zu kopieren -> keine Probleme
* NFS-Freigabe von einem anderen Linux-Server gemountet -> identisches Problem
* Mount von Server C nicht mittels NFS sondern smbfs -> identisches Problem
* Nachbau des Setups auf einem Debian 3.1, Ubuntu 6.06-Server -> keine Probleme

Zusammenfassung
Ich tippe auf ein Samba-Problem bei Debian 4.0. Am NFS-Mount kann es nicht liegen, da das Problem auch auftritt, wenn ich ein externes Verzeichniss mittels smbfs mounte. Die Samba-Version von Debian 4.0 scheint generell ein Problem mit gemounteten Verzeichnissen zu haben. Evtl. liegt es auch nur an der Samba-Version. Nur wird meines Wissens für Etch nur die 3.0.24 angeboten

Hat irgend jemand eine Idee, wie ich das Problem in den Griff bekommen kann? Gibt es irgendwo ein Samba 3.0.22 für Debian 4.0?

Vielen Dank schon einmal!
Heiko

[Friesi]

Hi!

Könnte es an der umask in der Sambaconfig liegen?
Denn im gegensatz zum chmod ist die umask invertierend. Also 0777 ergibt als chmod 0000 (Gar keine Rechte).

Hier ein kleines Beispiel:

Code: Alles auswählen

friesi@hyperplex:~/tmp$ mkdir test1
friesi@hyperplex:~/tmp$ umask 0777
friesi@hyperplex:~/tmp$ mkdir test2
friesi@hyperplex:~/tmp$ ls -l
insgesamt 8
drwxr-xr-x 2 friesi friesi 4096 2007-05-21 09:34 test1
d--------- 2 friesi friesi 4096 2007-05-21 09:34 test2

Schau mal mit welchen Rechten die Datein auf dem Dateisystem angelegt werden!

[HeikoSch]

Hallo Friesi und danke für Deine Antwort,

ich habe in den letzten Tagen etwas weiter geforscht:

Samba auf Server S selbst kompiliert

- 3.0.22 -> kein Problem
- 3.0.23 -> kein Problem
- 3.0.24 -> selbes Problem

Das lässt die Vermutung aufkommen, dass es an der Samba-Version liegt. Um diese Vermutung zu bestätigen, habe ich auf einem Debian/Sarge-System die selben Samba-Versionen compiliert - es gab bei keiner Version irgendwelche Probleme. Also liegt das Problem doch bei Debian/Etch?

Neuer Versuch. Vielleicht kommt Debian/Etch mit dem NFS-Mount nicht klar. Also habe ich die Cover per SMB gemountet (ich verwendete bei diesem Test die von Etch mitgelieferte Samba/smbfs-Version)

Code: Alles auswählen

//192.168.13.242/Cover-All /data/cover  smbfs   username=nobody,password=nogroup,defaults,user,uid=nobody,gid=nogroup   0   0

Siehe da, alle User konnten lesend und schreibend auf das Verzeichnis "/data/cover/" zugreifen. Nur gab es nach einer Weile massive Probleme mit Verbindungsfehlern zum Samba-Server (leider liegen mir die Logfiles nicht mehr vor). Für ein paar Sekunden verlohren die User die Verbindung zum Samba-Server.

In meiner Verzweiflung versuchte ich statt smbfs cifs zu verwenden. Bingo - jetzt hörten auf Schlag auch die Verbindungsfehler auf. Alles wäre bestens, wenn die User sich jetzt nicht über teilweise sehr langsame Geschwindigkeit beim Zugriff auf Server S beschwert hätten. Diese waren leider reproduzierbar und ließen sich auch beim besten Willen nicht "wegoptimieren".

Testhalber habe ich eine Billigkiste mit Ubuntu 6.06 aufgesetzt und die ursprüngliche Config (mount per NFS und dann Samba-Freigabe) vom Server S auf diese Maschine übertragen. Alles lief perfekt. Da mir die User im Nacken standen und auf eine Lösung pochten, installierte ich auf dem Server S Ubuntu 6..06, übernahm die ursprüngliche Config und fertig. Keine Probleme beim Schreiben, keine Verbundungsabbrüche und sehr schneller Zugriff.

Ok, der Kunde hat jetzt eine Lösung - wenn sie auch anders aussieht als ich mir vorgestellt habe. Da ich auch an einer Lösung des Problems interessiert bin, stehe ich für weitere Tests gerne zur Verfügung. Ich habe den Backup-Server momentan noch mit Debian/Etch laufen und habe also noch die Möglichkeit verschiedene Dinge an dem auszuprobieren.

Viele Grüße,
Heiko

[master_ben]

hallo heiko,

ich habe exakt dasselbe problem! hab auch schon mit verschiedenen samba versionen experimentiert, es ist zum haare ausreissen! hast du mittlerweile ne lösung? wär dir sehr dankbar!! ich bin am verzweifeln... es muss doch mit etch auch gehen!

sg, ben

[HeikoSch]

@master_ben

wenn Du Dich auf den nfs re-mount beziehst:
Kurz und knapp: nein, mit Etch geht es nicht.

Lösung:
1.) Mounte das fremde Verzeichnis nicht mit nfs, sondern cifs. Nachteil: Es ist sehr (!) langsam.
2.) kompiliere eine alte Samba-Version. Vorsicht: ab Version 3.0.23 gibts Probleme

Ich habe bei dem Kunden immer noch Ubuntu 6.06 im Einsatz und beginne mich mit dem Gedanken anzufreunden, dass es dabei bleiben wird.

Sorry, dass ich Dir keine bessere Alternative nennen kann

Viele Grüße,
Heiko

[master_ben]

danke heiko,

ich hatte auch schon mal nfs4 ausprobiert, das hat super funktioniert, bis auf die tatsache, dass usernamen mit umlauten (die ueber winbind vom ads kommen wie domänen-benutzer) einfach nicht gemapt wurden, alles andere funktionierte (so weit ich das testen konnte).

na gut, dann werd ich das ganze wohl auch mal mit ubuntu ausprobieren. hast du eigentlich mal probiert den nfs client auf dem etch system selbst zu kompilieren?

sg und dank fuer die schnelle antwort!

ben

[HeikoSch]

Hallo Ben,

an NFS4 hatte ich auch gedacht, nur hat einer der Server, den ich per NFS mounten wollte nur NFS3 angeboten. Da das nicht geändert werden konnte / durfte (warum auch immer), viel bei mir diese Möglichkeit aus.

An die Idee, den NFS-Client selbst zu compilieren, habe ich ehrlich gesagt noch gar nicht gedacht Meine Fehlersuche ging in eine andere Richtung: Der Schreibzugriff funktionierte ja, wenn ich eine alte Samba-Version compiliere. Also vermutete ich das eigentliche Problem hier.

Ich habe aber noch einen Test-Server im Einsatz, auf dem ich das diese Woche noch mal nachbauen werde. Sobald ich neuere Ergebnisse habe, melde ich mich noch einmal.

Heiko

[tflaig]

Ich habe aber noch einen Test-Server im Einsatz, auf dem ich das diese Woche noch mal nachbauen werde. Sobald ich neuere Ergebnisse habe, melde ich mich noch einmal.

Gibt es da inzwischen Ergebnisse?

Hab' hier dasselbe Problem, und such nach einer möglichst schmerzfreien Lösung.

ciao
Thomas
PS: Sorry für das hervorgraben des alten Threads.

[mcdikki]

Hab mal ein einen Denkanstoß für das Sekundäre Problem, die Gescwindigkeit der notlösung.

Versuche mal samba mit und auch nfs auf einen Port festzunageln. Samba benutzt standardmäßig zwei port, 139 und 445. Dass kann zu den genannten Verbindungsabbrüchen führen (war bei mir so). Mit dem Paramter "ports = 139" in der smb.conf ging es dann.

kannst es ha mal test.

[tflaig]

Auf der Samba-ML bekam ich folgenden Hinweis:

One potential workaround (no guarantees!) is to say "posix locking = no" on the relevant shares.

Googel nach posix locking = no hat ergeben, dass dies wohl oft die Problemlösung ist, bei mir war das leider nicht der Fall.

[tflaig]

Stefano Deponti hat mir vorgeschlagen, folgenden Schalter in die Globalsektion der smbd.conf einzufügen:

kernel oplocks = no

to the global part of my smb.conf file.

Damit scheint es auch bei mir zu funktionieren.