samba - Oct 2003 - shared files not locked -> samba culprit or clients?

hello,

i have a question concerning the locking feature of samba (both 2.2.8 
and 3.0.0) that i haven't found answered in the documentation. at this 
point i am not sure, whether it's a bug in samba, the client 
applications or simply a misunderstanding of the locking feature itself 
on my part - at any rate it's a pressing problem, as my clients are 
losing both their data as well as their faith in the server!

scenario:

- server S running samba 3.0.0 on freebsd 5.1p10,	strict locking is on, 
oplocks off (see smb.conf below)

- client A running Mac OS X 10.2.8

- client B running Mac OS X 10.2.8

now A opens a file (common text file or tiff image), then B opens it, 
too. Neither TextEdit nor Photoshop complain.
Both A and B make changes to the file. when B tries to save the file, 
he gets the message, that i can't be saved (good!). When he tries to 
save a second time it succeeds, though! User A still has the file open 
and can't save any changes (no matter how often one tries.) The 
directory is being populated with files such as 384-88097892-1.rtf.

With Photoshop on the other hand it's simply "The last one to save 
wins!"

With Excel it's even worse: when B opens the excel file, it says 
'access denied. abort or retry?' (good! strict locking is on, after 
all). However, now comes the scary part: in about one of three cases A 
will now be unable to save his changes! After 30 - 60 seconds Excel 
will time out and ask to retry. the clients smb-log is filled with 
multiple instances of the following message:

[2003/10/17 18:20:45, 3] smbd/trans2.c:call_trans2findfirst(951)
   call_trans2findfirst: dirtype = 22, maxentries = 1, 
close_after_first=1, close_if_end = 1 requires_resume_key = 0 level = 
257, max_data_bytes = 16644
[2003/10/17 18:20:45, 3] lib/util.c:unix_clean_name(580)
   unix_clean_name [/Test/testvier.xls]
[2003/10/17 18:20:45, 3] lib/util.c:unix_clean_name(580)
   unix_clean_name [Test/testvier.xls]
[2003/10/17 18:20:45, 3] lib/util.c:unix_clean_name(580)
   unix_clean_name [Test]
[2003/10/17 18:20:45, 3] smbd/dir.c:dptr_create(491)
   creating new dirptr 256 for path Test, expect_close = 1
[2003/10/17 18:20:45, 3] smbd/error.c:error_packet(113)
   error packet at smbd/trans2.c(1085) cmd=50 (SMBtrans2) 
NT_STATUS_NO_SUCH_FILE
[2003/10/17 18:20:45, 3] smbd/process.c:process_smb(890)
   Transaction 2804 of length 96
[2003/10/17 18:20:45, 3] smbd/process.c:switch_message(685)
   switch message SMBtrans2 (pid 7152)
. this cycle doesn't end. if i don't retry, the file is renamed to 
arbitrary name (FFAAB00.xls).


now, did i miss something? isn't server side locking meant to be just 
that? server side and thus server dependant? why does every application 
handle this situation differently? with oplocks on and strict locking 
off A even loses his excel file: excel will state that 'all previous 
copies have been lost' and will refuse to save the file anywhere, even 
locally!

the situation is even worse when i introduce

client C running Win2K (latest service pack) using OpenOffice 1.1

again, no locking.

i guess, i could live with strict locking, if it ensures the integrity 
of my clients data. if they need to peak  into an excel sheet that's 
being edited then they could always make a local copy. ugly but doable. 
but as it is, the whole server has become pointless...

when using Mac OS X server via AFP, locking between A and B works like 
a charm (read-only access for B as long as A has the file open), 
whereas C won't get any access at all.

i'm really stumped. has anybody got any suggestions? is there no way 
that i can enforce read-only locking regardless of client os and 
application? surely, that must be possible! but how?

below is my smb.conf.

also, could everybody be kind enough to include my address in 
responses? the huge volume of the samba list has kept me from 
subscribing to it at this point.

thank you for your time!

kind regards,

tom lazar


smb.conf:

[global]

    workgroup = Rheinsberger79
    server string = Knox

    hosts allow = 192.168.0. 127.

    load printers = no
    log level = 3
    log file = /var/log/log.%m

    max log size = 50000

    security = user

; locking:
    oplocks = no
    level2 oplocks = no
    strict locking = yes

    encrypt passwords = yes
    socket options = TCP_NODELAY

    local master = yes
    domain master = yes
    preferred master = yes
    os level = 65

;encoding
    unicode = yes
    unix charset = CP850
    dos charset = CP850
    display charset = CP850

[homes]
    comment = Home Directories
    browseable = yes
    writeable = yes

[Shared]
         comment = Shared Stuff
         path = /home/shared
         valid users = @house
         public = yes
         writeable = yes
         printable = no
         create mask = 0775
         directory mask = 0775
         hide dot files = yes

--
tom lazar <tom@tomster.org>

On Fri, Oct 17, 2003 at 06:10:35PM +0200, Tom Lazar
wrote:
> hello,
> 
> i have a question concerning the locking feature of samba (both 2.2.8 
> and 3.0.0) that i haven't found answered in the documentation. at this 
> point i am not sure, whether it's a bug in samba, the client 
> applications or simply a misunderstanding of the locking feature itself 
> on my part - at any rate it's a pressing problem, as my clients are 
> losing both their data as well as their faith in the server!
This was a bug in 3.0.0, has been fixed in the 3.0.1 CVS tree
and in the 3.0.1 pre release.
I posted the patch on this list, sorry for the problem. If you
can't find it in the archives (look for "read only Excel file")
mail me and I'll look it up.

Jeremy.

>On Fri, Oct 17, 2003 at 06:10:35PM +0200, Tom Lazar wrote:
>> hello,
>> 
>> i have a question concerning the locking feature of samba (both 2.2.8 
>> and 3.0.0) that i haven't found answered in the documentation. at
this
>> point i am not sure, whether it's a bug in samba, the client 
>> applications or simply a misunderstanding of the locking feature itself
>> on my part - at any rate it's a pressing problem, as my clients are
>> losing both their data as well as their faith in the server!
>
>This was a bug in 3.0.0, has been fixed in the 3.0.1 CVS tree
>and in the 3.0.1 pre release.
>I posted the patch on this list, sorry for the problem. If you
>can't find it in the archives (look for "read only Excel
file")
>mail me and I'll look it up.
Unfortunately this patch doesn't solve all locking problems :-(
As i wrote (I posted mail to samba-technical by mistake) I have locking
problems with current CVS.

On 17.10.2003, at 21:17, Jeremy Allison wrote:
> No, I can't reproduce this with 2 W2K boxes and Office 2000 SR1.
hi again,

i've done some more testing and have been able to nail down, when it 
happens:

user a opens file test.xls, modifies it, but doesn't save it yet.
user b opens it, closes it
user a can't save any changes anymore! excel times out, renames the 
file to an arbitrary name and will not permit any further save attempts 
of the file.

i have repeated this five times and it happened every time.

i have created a fresh log-directory for samba, turned the log-level up 
to 10, restarted samba and then repeated the above steps. i've taken 
the liberty to upload a .tgz of both clients log files, the smbd.log, 
as well as my smb.conf to the following URL:

http://tomster.org/geek/samba-debug-logs.tgz

in the logs user a is machine burroughs with IP 192.168.0.23 and b is 
goedel with IP 192.168.0.177
> What are the permissions/ownership on the xls file on your share ?
the permissions for the file in question are:

root@knox# ll /home/shared/SambaTest/
total 34
-rwxrw-r--  1 tomster  house     82 Oct 18 18:26 ._FA7E5000
-rwxrw-r--  1 tomster  house     82 Oct 17 20:36 ._test.xls
-rwxrw-r--  1 tomster  house     82 Oct 18 18:19 ._test2.xls
-rwxrw-r--  1 tomster  house     82 Oct 18 18:21 ._test3.xls
-rwxrw-r--  1 tomster  house     82 Oct 18 18:24 ._test4.xls
-rwxrw-r--  1 tomster  house  24064 Oct 18 18:50 FA7E5000

(this is after excels renaming-funk...)

clients are both mac osx (build 7B85 aka Panther Golden Master), using 
the latest version of Office v. X (10.1.5) the server is running 
freebsd 5.1p10 with samba 3.0.0 and your patch applied.

the behaviour has been the same with 10.2.8 clients (to which i haven't 
got acces right now)

currently I'm also not able to provide any testing with a Windows 
Client, but i can do that tomorrow or on monday.

thank you for any feedback. I'm sort of getting desparate here... :-( 
there's twelve people who will have a busy day on monday and will be 
opening, closing and saving A LOT of excel files...

kind regards from berlin,

tom


--
tom lazar <tom@tomster.org>