[Eisfair] Samba-Problem mit Files groesser 2GB !

Thomas Bork tom at eisfair.org
So Jun 3 11:49:21 CEST 2018


Am 03.06.2018 um 09:53 schrieb Uwe Kunze:

>> [2018/06/03 09:22:11.263127,  0] 
>> ../source3/locking/posix.c:270(posix_fcntl_getl
>>   posix_fcntl_getlock: WARNING: lock request at offset 3034388, length 
>> 1958 retu
>>   an Invalid argument error. This can happen when using 64 bit lock 
>> offsets
>>   on 32 bit NFS mounted file systems.
> Da aber kein nfs im Spiel ist, muß die Ursache noch woanders liegen.
> Tatsächlich greift neben Samba noch ein anderer (Linux-)prozess auf die 
> Files zu ... ein DLNA-Server auf demselben eis.

Wir haben ja schon bei den Problemen mit dem neuen Kernel vermutet, dass 
Dein(e) DLNA-Server die Probleme verursachen.

>> Siehe oben. Und die Fehlermeldung deutet eindeutig auf ein
>> Locking-Problem hin. Hast Du es schon einmal mit
>> strict locking = no
>> im global-Teil der smb.conf probiert?
> Soweit man das nach schon nach ein paar kurzen Tests sagen kann:
> ERFOLGREICH !
> Keine der o.g. Fehler mehr in /var/log/log.smbd ... keine 
> Zugriffsprobleme auf größere Files.

Sieht für mich so aus, als fordert Dein DLNA Locks mit falschem offset an.

Noch einmal als Warnung:

Locking ist ein Mechanismus, der verhindern soll, dass 2 verschiedene 
Prozesse zur selben Zeit die selbe Datei bearbeiten, Setzt Du das ausser 
Kraft, kannst Du damit Datensalat produzieren.


strict locking (S)

     This is an enumerated type that controls the handling of file 
locking in the server. When this is set to yes, the server will check 
every read and write access for file locks, and deny access if locks 
exist. This can be slow on some systems.

     When strict locking is set to Auto (the default), the server 
performs file lock checks only on non-oplocked files. As most Windows 
redirectors perform file locking checks locally on oplocked files this 
is a good trade off for improved performance.

     When strict locking is disabled, the server performs file lock 
checks only when the client explicitly asks for them.

     Well-behaved clients always ask for lock checks when it is 
important. So in the vast majority of cases, strict locking = Auto or 
strict locking = no is acceptable.

     Default: strict locking = Auto

-- 
der tom
[eisfair-team]


Mehr Informationen über die Mailingliste Eisfair