Samba bekommt veränderungen der Dateien auf dem Server nicht mit.

13/10/2009 - 22:28 von Stephan Weissenrieder | Report spam
Hallo *,

mein Samba Linux client scheint Dateien vom Server zwischenzuspeichern:

auf dem Server lege ich eine Datei 1.pl an:
#!/opt/bin/perl -w
sleep 1000000 ;
__DATA__
bla

Auf dem (Linux Client) lasse ich dieses Script nun laufen:
/opt/bin/perl /samba/share/1.pl

wenn ich jetzt die Datei 1.pl auf dem Server àndere (echo hallo >> 1.pl)
bekommt Samba nicht jedes Update mit. d.h ich habe zwar immer aktuelle
Dateigroessen, aber der Inhalt der Datei stimmt zwischen Client und Server
nicht überein. Das passiert nicht bei jeder Änderung, aber nach ein paar
Änderungen habe ich unterschiedliche Dateien auf dem Server wie auf dem
Client. Wenn die Dateien unterschiedlich sind, ist das einzige was hilft
alle Perl Prozesse zu killen und die Datei auf dem Server zu touchen.


Ich habe keine Ahnung, um was für ein Art von Problem es sich handelt,
trotzdem habe ich mein Glück mit den verschiedenen Einstellungen zu Locks
versucht:

testparm -v|grep -i locks auf dem Server:

kernel oplocks = No
blocking locks = Yes
fake oplocks = No
oplocks = No
level2 oplocks = No


An dem Samba ist sonst "eigentlich" nichts besonderes, er ist noch Mitglied
einer Samba Domain.

Gemountet wird das ganze auf dem Client per fstab so:
//server/share /server/share cifs username=bal,password=blub,nobrl 0 0


Beides sind Opensuses, 11.1 64 Bit.
beteiligt ist ein Samba Server:
smbd --version
Version 3.2.4-5.2-1985-SUSE-CODE11
und auf dem Samba Client: (grr mount.cifs -V oder --version gibt die
Hilfeseite aus)
rpm -qf sagt cifs-mount-3.2.4-5.2

Die smb.conf:
[global]
workgroup = blub
server string = server
security = DOMAIN
map to guest = Bad User
password server = 10.9.12.12
log file = /var/log/samba/log.smbd
time server = Yes
unix extensions = No
socket options = TCP_NODELAY IPTOS_THROUGHPUT SO_SNDBUF384
SO_RCVBUF384
printcap cache time = 0
printcap name = cups
wins server = 10.9.12.12
kernel oplocks = No
pid directory = /var/run/samba/
host msdfs = No
winbind trusted domains only = Yes
cups options = raw
veto files = /*.eml/*.nws/riched20.dll/*.{*}/
oplocks = No
level2 oplocks = No

[share]
path = /somewhere/share
read only = No
force create mode = 0777
force directory mode = 0777
volume = blub


Für jegliche Hinweise bin ich dankbar.


Gruss

Stephan
 

Lesen sie die antworten

#1 Ansgar Strickerschmidt
14/10/2009 - 15:44 | Warnen spam
Also schrieb Stephan Weissenrieder:

Hallo *,

mein Samba Linux client scheint Dateien vom Server zwischenzuspeichern:

auf dem Server lege ich eine Datei 1.pl an:
#!/opt/bin/perl -w
sleep 1000000 ;
__DATA__
bla

...

Für jegliche Hinweise bin ich dankbar.



Ähnliches Problem hier. Werde das mit Interesse verfolgen.

Andererseits: was spricht denn außer der Frage "Case sensitive/insensitive
Dateinamen?" dagegen, von Linux zu Linux per NFS zu mounten?

In unserem Fall importiert auch eine Linux-Maschine ein Samba-Share von
einem NAS-Kistchen (Qnap TS-109pro; ja, ich weiss, die kann auch NFS, das
Problem ist aber die Verwirrung, die bei uns hier "case
sensitive"-Dateinamen hervorrufen würden -"wieso kommt die Änderung nicht
an? ich hab's doch unter genau diesem Namen gespeichert..."), um sie dann
a) lokal zu verwenden und b) via TFTP wieder auszuliefern. Auf diese Weise
gefàhrdet man nicht den Datenbestand, wenn an dem kleinen TFTP-Server mal
was klemmt.
Ja, auf dem Qnap làuft auch ein Linux mit Samba als Server.
Wenn nun Kollege an einem per TFTP auszulieferndem Textfile was àndert,
weil er am Testen ist, sollte diese Änderung auch verzögerungsfrei
ankommen... ich habe mich Samba-client-seitig dann jeweils mit einem
Zwangs-Remount beholfen. Das ist aber keine Dauerlösung.
Ich vermute mal, dass es da noch einen Samba-Parameter gibt, der, àhm,
weniger prominent ist...

Ansgar

*** Musik! ***

Ähnliche fragen