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 <[EMAIL PROTECTED]>
-- To unsubscribe from this list go to the following URL and read the instructions: http://lists.samba.org/mailman/listinfo/samba
