Ubuntu 8.04 breaks samba file locking

dgermann · 08-03-2008, 03:14 PM

Hi--

Just upgraded yesterday from Ubuntu 7.10 to 8.04.01. File locking in Samba is now broken, meaning two different users can have the same file open at the same time and edit it.

Server is RedHat 9.0 running Samba 2.2.7a-security-rollup-fix. This has been working well for us for several years. Have one WinXP box accessing the server using OOo 2.0. Have another couple of Win95 boxes.

In addition, have one Ubunutu 6.06 box, and three other 8.04 boxes.

It appears the XP and the 6.06 box lock files so the other cannot edit them while one has them open, but the 8.04 boxes, running OOo 2.4 can access and edit and save these files, thus causing havoc.

This is a production environment.

Can anybody suggest a solution or at least a trouble-shooting procedure?

Thanks!

netman4ttm · 08-07-2008, 11:07 AM

Had the same problem with moving from RedHat 7.1 to 7.2.
The issue at that time was oplocks and FoxPro.
The solution for us was to move to a FreeBSD server.
First: I would get everyone on the same version of Open Office.
Then I would start with the smb.conf on the RedHat box and disable oplocks either for the shared directories or the file types that are giving you issues.

If that fails you will probably find FreeBSD solves the issue (basically no oplocks to get in the way).

dgermann · 08-07-2008, 09:04 PM

netman4ttm--

Thanks for your help.

I am beginning to think that changing to a more up to date server, particularly ubuntu, since that is what the client boxes are, might help the whole thing work together better.

I am gathering by what you say about FreeBSD that there is something other than samba that might be involved in file locking. True?

In the last couple of days I have changed level2 oplocks to yes and kernel oplocks and oplocks each to no.

After this I opened a document in OOo Writer on Ubuntu Box 1; then I opened the same file on Ubuntu Box 2--there it opens and does not show as read only. Indeed I can edit it. I did so, saved the document and then reloaded on Box 1: there was no change! On box 2 it indicates that the changes were saved.

So I tried it in reverse and got the same results: both open, one saves, the other does not see the change, both think the file is up to date.

Tried it a third time, 1 saves, 2 can see the change; 2 saves a further change, 1 can see that change.

While both are open, I opened the same file in the WinXP box--and it opens as read-only.

So it seems unpredictable what changes will appear and from which client, although it seems that between WindowsXP and Linux boxes, they respect each other's locks.

Here is my smb.conf file, if that gives us any clues:

Code:

# Samba config file created using SWAT
# from 0.0.0.0 (0.0.0.0)
# Date: 2008/08/07 08:43:36

# Global parameters
[global]
	workgroup = EVERYONE
	server string = dougs samba server
	interfaces = 192.168.blanked/24
	encrypt passwords = Yes
	username map = /etc/samba/smbusers
	password level = 12
	username level = 12
	unix password sync = Yes
	log file = /var/log/samba/%m.log
	max log size = 100
	socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
	os level = 33
	domain master = Yes
	dns proxy = No
	wins support = Yes
	kernel oplocks = No
	remote announce = 192.168.0.255 192.168.blanked
	printing = cups
	oplocks = No

[label]
	comment = Vol1-apps-label
	path = /vol12/apps/label
	valid users = blanked
	force user = apps
	read only = No
	create mask = 0777
	directory mask = 0775
	strict locking = Yes
	dos filemode = Yes

[home]
	comment = Home Directories
	path = /home
	valid users = blanked
	read only = No
	create mask = 0664
	directory mask = 0775

[printers]
	comment = All Printers
	path = /var/spool/samba
	valid users = blanked
	printable = Yes
	browseable = No

[tmp]
	comment = Temporary file space
	path = /tmp
	valid users = blanked
	read only = No

[doug]
	comment = doug home
	path = /home/doug
	valid users = blanked
	read only = No

[doug2]
	comment = doug2
	path = /doug2
	valid users = blanked
	read only = No

[sys2]
	comment = sys2
	path = /sys2
	valid users = blanked
	read only = No
	create mask = 0775
	directory mask = 0775
	strict locking = Yes

[vol12]
	comment = Volume 12
	path = /vol12
	valid users = blanked
	force user = apps
	read only = No
	create mask = 0775
	directory mask = 0775
	sync always = Yes
	preserve case = No
	veto oplock files = /*.o*/
	map system = Yes
	map hidden = Yes
	strict locking = Yes
	dos filemode = Yes

[vol22]
	comment = Volume 22
	path = /vol22
	valid users = blanked
	force user = data
	read only = No
	create mask = 0775
	directory mask = 0775
	sync always = Yes
	preserve case = No
	veto oplock files = /*.o*/
	map system = Yes
	map hidden = Yes
	strict locking = Yes
	dos filemode = Yes

[etc]
	path = /etc
	valid users = blanked
	read only = No
	map system = Yes
	map hidden = Yes
	strict locking = Yes

vol22 is the main directory where we work, and where this bizarre stuff is going on.

This evening ubuntu #3 (a 6.06 box) had a file open and box 1 could not open it. Later, box 1 alone opened it and box 2 could also open it and edit.

Thanks netman4ttm!

netman4ttm · 08-08-2008, 08:10 AM

The issue for us was the oplocks for FoxPro and Access.
I can't say for sure that this is the same issue you are facing especially since your issue cropped up this late in the game. Oplocks, changed around the time of RedHat 7.1 or 7.2
What I do know is that FreeBSD is one of the *nix's that does not use oplocks that Samba can use and the switch cured the FoxPro problem. Our smb.conf files don't even deal with oplocks and no matter what we did we couldn't fix that issue within Linux.
Since the issue showed with the install of Ubuntu ---
You might want to try Mepis on the upgraded box instead of Ubuntu. I am more impressed with Mepis within a Windows environment; in fact after 6.06 I have been unimpressed with Ubuntu.

dgermann · 08-08-2008, 09:43 AM

netman4ttm--

Thank you!

I am unfamiliar with both FreeBSD and Mepis, but it sounds like it might be worth a look. I am not thrilled with the idea of learning a new OS, but if it cures a big problem....

Thanks, netman4ttm!