Just for clarity:

Tested clients on Tested on Red Hat Fedora, Knoppix 3.9 (debian), kanotix 2005-3 
(debian)

Tested servers: Samba 3.x, Samba 2.x, Windows NT4 SP6, NFS v?

Reproducible on all.

Please check if file-locking is enabled. See readme, chapter "file-locking".

# more /usr/lib/openoffice/program/soffice | grep SAL_ENABLE_FILE_LOCKING
SAL_ENABLE_FILE_LOCKING=1
export SAL_ENABLE_FILE_LOCKING

According to the README, that means it is turned on.

Have done some further testing:
I use smb4k for mounting smb shares on servers.
It was suggested I try mounting shares using CIFS instead of SMBFS - the 
results:

Note - correct behaviour in the below examples means that the first machine 
opens the file RW and the Second machine opens the file RO.

Server: Linux/samba 2.2.3a
Linux/Linux: Correct behaviour
Linux/Windows: Correct behaviour
Windows/Linux: Linux client throws error "General Input/Output error while 
accessing <file>"

Server: Windows NT4 SP6
Linux/Linux: Both clients open the file RW. Changes made and saved by one are 
overwritten when saving on the other client
Linux/Windows: Linux opens the file RW, windows cannot open the file at all. No 
error messages
Windows/Linux: Linux client throws error "General Input/Output error while 
accessing <file>"

This is better than the results mounting shares using smbfs, but it doesn't 
resolve the issue with NFS shares, and the behaviour is still not correct in all 
cases anyway.

TM->JSK: Please have a look, thanks !

Almost two weeks have passed since last developer comment - I probably should 
have classed this as a P2 issue since it results in data loss. Hoping that will 
give it a little more exposure...

In terms of severity, this is holding back a rollout of ~80 Linux desktops in my 
organisation, and I would assume this affects a lot of other companies running 
mixed OS environments.

Can I please get some feedback on whats happening? Should I create a duplicate 
issue with a P2 priority?

Thanks

Hi dbw,

we are currently very busy so please have a little patience.
However, this is dataloss which qualifies for a P2.

I change the target to OOo 2.0.3 (there is little to no chance that this can be
addressed earlier), 2.0.1 is under way and 2.0.2 has its planning complete.

Thank you for this very comprehensive and detailed error report.
Reassigning.

NFS file locking usually works as soon as all required daemons are running: see
i54586 for details. 

BTW: the only thing that changed from OOo 1.x to 2.0 regarding file locking is
that it is now enabled by default. 

jsk - apologies for the impatience. Thanks for getting back to me, I guess I 
should've done some more thorough testing in development builds and made it an 
issue earlier. Having it slated for resolution at the earliest possible time (2.
0.3) is a great relief :)

obr - the NFS server I tested on was not built by me so I have no idea about the 
setup. A company I was visiting used nfs for filesharing, so I just tested the 
filelocking from the client side with no further info about the server.
This problem exists for linux/linux sharing in the 1.1.x branch as well, and was 
an issue for windows/windows sharing in 1.0.x (resolved in 1.1.0) 

Thanks again for the great software, and the hard work. I(we) really do 
appreciate it :)

I have problems accessing files in Samba 3.0.21 server from Linux (Debian.etch)
cifs client. Here is the output from the server:

17486        DENY_NONE  0x12019f    RDWR       EXCLUSIVE        /datos/6.004.odt   
14847        DENY_WRITE 0x2019f     RDWR       EXCLUSIVE+BATCH  /datos/6.005.odt   

The first one is the file opened form Linux CIFS client (I get errors)
The second one (good) is the file opened from WXPPro client.

Here is more info regarding the (CRITICAL?) bug.
I have opened a file from a samba server using CIFS Linux client. When saving
the file I get a message "Can't create backup" (in Spanish "No se pudo crear la
copia de seguridad"). At this moment, the server shows:

alcudia:~# smbstatus
Samba version 3.0.21b
PID     Username      Group         Machine
-------------------------------------------------------------------
 6536   jordi         jordi         192.168.11.2 (192.168.11.2)

Service      pid     machine       Connected at
-------------------------------------------------------
datos1       6536   192.168.11.2  Wed Feb 22 23:20:45 2006

Locked files:
Pid          DenyMode   Access      R/W        Oplock           SharePath      
    Name
----------------------------------------------------------------------------------------
6536         DENY_NONE  0x12019f    RDWR       NONE             /datos1  
6.005.odt   Wed Feb 22 23:40:26 2006
6536         DENY_NONE  0x120089    RDONLY     NONE             /datos1  
6.005.odt   Wed Feb 22 23:41:15 2006

My server and client system is debian.etch (share is accessed from localhost)

alcudia:~# uname -a
Linux alcudia 2.6.12-1-386 #1 Tue Sep 27 12:41:08 JST 2005 i686 GNU/Linux

After hitting <Ok> button the the error dialog window, samba shows:

alcudia:~# smbstatus
Samba version 3.0.21b
PID     Username      Group         Machine
-------------------------------------------------------------------
 6536   jordi         jordi         192.168.11.2 (192.168.11.2)

Service      pid     machine       Connected at
-------------------------------------------------------
datos        6536   192.168.11.2  Wed Feb 22 23:20:45 2006
datos1       6536   192.168.11.2  Wed Feb 22 23:20:45 2006

No locked files

If a click on the OpenOffice <Save> button again, I get one error regarding that
it could not load some Basic from the document, and if I accept these errors it
saves Ok.

alcudia:~# smbstatus
Samba version 3.0.21b
PID     Username      Group         Machine
-------------------------------------------------------------------
 6536   jordi         jordi         192.168.11.2 (192.168.11.2)

Service      pid     machine       Connected at
-------------------------------------------------------
datos1       6536   192.168.11.2  Wed Feb 22 23:20:45 2006

Locked files:
Pid          DenyMode   Access      R/W        Oplock           SharePath      
    Name
----------------------------------------------------------------------------------------
6536         DENY_NONE  0x12019f    RDWR       EXCLUSIVE        /datos1  
6.005.odt   Wed Feb 22 23:46:58 2006

I have tested it also at work where the client and the server are different
Debian.etch machines.

I urge the developers to correct this, the issue is critical for mixed
Windows/Linux environments, it if forcing the linux desktops in my company to a
freeze again...

I suspect that the locking is broken even with ONE MACHINE SELF. We got this
issue  sometimes even when ONLY ONE machine actually is accessing the file.
Seems as if the machine locked the file for self and didn't unlock. Or if it
incorrectly processed the flags returned by Samba.

Please, could someone tell, what should I note, what kind of info should I
gather from client, server, and how to do it to help best to solve the issue?

*** Issue 54136 has been marked as a duplicate of this issue. ***

*** Issue 62959 has been marked as a duplicate of this issue. ***

I had the same problem writing in NFS mounted directory.

I get this problem solved issuing:

#  mount -t nfs -o nolock  server:/Share  /mnt/Data

Hope this help.

Greetings.

woautalan - that does not resolve the issue of two clients trying to access the
same file, and neither client locking the file for writing.

I will try to sumarise what users from cs-mailing list said regarding this problem.

28.03.2006 08:13 user Shipowner said:
Saving files using VPS Hamachi, TC, OfficeXP performs all well, only
OpenOffice.org claims "General Input/Output error". I then put the document on
local drive and copy it to server using file manager.

Other "pearl": I open OOo Calc, use Open File and browse to server, where I open
document from then. Calc opens, however data is not there. I must "touch" the
server using commander, copy the spreadsheet to local PC and open from it. It
opens again, however now it contains needed data..

27.03.2006 09:19 user Petr Štefánik wrote:
I feel that if the server share is mapped as drive in Windows clients, no
problem appears.

27.03.2006 09:23 user Evžen Hlavica wrote:
I use OOo 2.0.1 under W_XP/2000/98SE and whole data is stored on W_NT/4.0 SP4
server. Shared directories are mapped as drives in Windows (using login script).
I haven's got any problems.

27.03.2006 12:56 Daniel Hrbac wrote:
I run OOo under WXP, data are stored on SAMBA. I get this error in the case when
mapped drives disconnect for some reason. It's enough then to run explorer,
mouse click on the mapped drives, they reconnect/actualise and OOo saves the
data. It looks like OOo cannot touch the files the way to actualise the
connection for himself.

See also Issue 63672

27.03.2006 17:50 Lumir Pribyl wrote:
Problems with reconnecting mapped drives in WXP client versus SAMBA/Linux server
-they have been completely resolved by upgrade WXP SP to WXP SP2.

It is rumored that WXP SP1, while mapping the drive, waits for some output from
some obscure, totally independent function, and he of course dosen't get that
from Linux server. In SP2 it probably got fixed.

27.03.2006 21:03 Daniel Hrbac wrote:
For me, the WXP SP2 DIDN't solve the problem. Look at Issue 63672.

28.03.2006 00:41 Uhrak.ServIT wrote:
Gentleman, this bug (hopefully not a feature) is appearing not for the first
time. It seems that it is specific for server/client configuration, might also
depend on other software installed ( onserver?client?)

In work we use RH9/SAMBA, W2k3 with shared drives, some users also share their
directories.
I've got Mandriva2006 as server with samba3 + NFS + FTP +.. (You know that
stuff), clients the same + WXP also. I haven't ever noticed problems (since the
OOo 1.0.1) regarding saving the documents. Dosen't matter if they were or
weren't mapped (Win versus \\server\path..). Dosen't matter if it even has been
NFS share.
However, I have activated NFS recently and there have been problems with OPENING
the file (Mandriva 2006). I've been able to save only. I played a little with
settings of NFSD, and the upgrade to NFS3 really helped. It might have been set
to protocol version 2 by default. I don't really understand the stuff generally.

It's pitty that we can't find the exact suspect. More PC's with the same
problem, server configuration, which are problematic and which aren't..

I can say, that in case of NFS, I have been unable to open files from NFS share
too. (Issue 58215).

Workaround from Issue 54567
jsi Tue Nov 1 02:39:59 -0700 2005 -------

exclude with a # (hash)
SAL_ENABLE_FILE_LOCKING=1
in soffice start script (View package content -> Contents .... /program/soffice).


I tested it and it completely helped with NFS, however it dosen't help much with
Linux client + Linux server }SAMBA|.

28.03.2006 01:02 Daniel Hrbac wrote:

Well, one test case

client1: WinXP SP2, OOo 2.0
client2: dtto
documents on shared drive X:\Akta on \\Akserver\Akta

server: Mandriva linux 2006.0 actualised from stable
fs: ext3

samba.cfg:
# Samba config file created using SWAT
# from UNKNOWN (127.0.0.1)
# Date: 2004/03/23 15:36:02

# Global parameters
[global]
    log file = /var/log/samba/log.%m
    client code page = 0
    character set = ISO8859-2
    socket options = TCP_NODELAY SO_SNDBUF=8192 SO_RCVBUF=8192
    hosts equiv = /etc/hosts.allow
    guest ok = Yes
    create mask = 0777
    interfaces = 192.168.1.0/24
    map to guest = Bad User
    null passwords = yes
    encrypt passwords = yes
    hosts allow = localhost 192.168.1.99 192.168.1.98 192.168.1.97 192.168.1.96
    printer admin = @adm
    dns proxy = No
    netbios name = AKSERVER
    mangle case = Yes
    printing = cups
    writable = yes
    workgroup = FJD
    directory mask = 0777
    comment = Akta
    printcap name = cups
    security = SHARE
    preload = global
    max log size = 50

[Akta]
    force create mode = 0660
    oplocks = no
    force user = samba
    path = /data/Akta
    force directory mode = 0770
    force group = users 

Daniel Hrbac also wrote:

Try issue 63672 with this config and tell, if writing works. I can reproduce the
error anytime.

04.04.2006 18:35 Uhrak.ServIT wrote:

Hallo,
because my configuration is similar to Daniel's, I'm posting my smb.conf. It
would be fine if it has been enough to just change some setting from his one.
However I cannot figure, what problem they have on Windows servers..

This SAMBA configuration works flawlessly both with WXP and Mandrivou2006.
Server is also Mandriva 2006.

# Samba config file created using SWAT
# from 192.168.0.100 (192.168.0.100)
# Date: 2006/03/28 20:25:06

# Global parameters
[global]
    dos charset = 852
    unix charset = ISO8859-2
    workgroup = DOMA
    server string = Samba
    interfaces = 192.168.0.1/24
    auth methods = guest, sam, winbind
    update encrypted = Yes
    allow trusted domains = No
    min password length = 0
    map to guest = Bad User
    null passwords = Yes
    obey pam restrictions = Yes
    password server =     pam password change = Yes
    passwd program = /usr/bin/passwd %u
    passwd chat = *New*password* %n\n *Retype*new*password* %n\n
*passwd:*all*authentication*tokens*updated*successfully*
    username level = 5
    unix password sync = Yes
    log file = /var/log/samba/%m.log
    max log size = 0
    debug pid = Yes
    debug uid = Yes
    time server = Yes
    paranoid server security = No
    socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
    logon path =     logon home =     os level = 33
    preferred master = Yes
    dns proxy = No
    wins support = Yes
    ldap ssl = no
    preload = %U
    guest ok = Yes

[homes]
    comment = Muj adresar
    path = /opt/ftp/%u/
    username = %S
    read only = No
    create mask = 0664
    directory mask = 0775
    guest ok = No
    browseable = No

film]
    comment = film
    path = /opt2/filmy

[hudba]
    comment = hudba
    path = /opt2/hudba

[income]
    comment = income
    path = /opt/ftp/pub/income
    read only = No

[sw]
    path = /opt/ftp/pub/sw
    write list = milan
    browseable = No

[Dokumenty]
    path = /opt/samba/Dokumenty
    write list = milan

[i250]
    path = /var/spool/samba
    printer admin = milan
    max print jobs = 10
    printable = Yes
    cups options = lpr-cups -P %p -o raw %s -r
    printer name = tp0
    use client driver = Yes

[Drivers]
    path = /opt/ftp/pub/Drivers
    admin users = milan
    write list = milan 

Hi Tuharsky,
I appreciate your help in trying to resolve this issue, but your replies are NOT
relevant. 
This issue refers to LINUX clients not locking files for writing on multiple
fileserver configurations inc Windows/SMB, Linux/SMBv2, Linux/SMBv3, Linux/CIFS,
Linux/NFS -

Your posts refer to Windows Clients (not relevant), Linux/Windows Clients (not
relevant), General Input/Output errors trying to save files (not relevant), and
Samba conf files (also not relevant since it is reproducible on multiple
fileserver setups)

I would appreciate it if you could reread the summary and previous posts on this
issue before making more "off topic" posts.

I apologize, I felt that the issues are too connected, and they are pretty much
annoying.
I'll post it all to Issue 54567.

I hope that didn't come across as too harsh - the reason for my concern is that
this issue has been marked for resolution in 2.0.3 and so far there has been
very little feedback from the developers. I just don't want them to get
distracted by side issues and focus on resolving this one 

(chances are other related issues will be resolved with this issue too ;-) )

@dbw: Your desired behaviour reflects the DENY_xxx modes used by the 
Windows file API. UNIX does not support such DENY_xxx modes which are a kind 
of locking on Windows. Instead file locking is implemented (and OOo does so) by 
f_cntl() calls to set a write lock, while on Windows clients it's done by setting the 
share mode to DENY_WRITE when opening a file for writing.

Your first provided SMBD log output shows that the share mode is not set when 
accessing the files from linux clients. OOo does not know anything about the file 
system it accesses, it just sets a write lock. Then it's up to the smb client to 
forward the write lock to the smb server and the smbd has to translate that into a 
share mode (and vice versa when a share mode is set by a Windows client).

oplocking has nothing to do with real locking it's just a hint wether the client is 
allowed to cache the files by assuming the client is the only one accessing the 
file. So enabling oplocking in smb.conf is a bad idea if you want to get the desired 
exclusive file access. I don't know which parameter in smb.conf might help but 
when taking a look into the manpages I guess playing around with "posix 
locking", "kernel oplocks",  "strict locking" might be the right switches.

The answer for the NFS problem is that locking is just faked if there's no lock 
deamon running on the NFS server.

So the answer to fix the problem is: Configure your file system servers and clients 
in a suitable manner to get the desired behaviour. It's not an OOo specific thing. 
And I don't know wether this is possible at all as I've not tested the smb.conf 
switches.

Closing.

I am having the same problems trying to share a Calc document using Fedora 10
and SMBFSv3. We are trying to migrate all Windows desktops on the office and
share documents with the locking options.

The same OpenOffice version installed on my Notebook with Windows XP works fine.
The problems seems to be about some compatibilities between the SMB and the OO
locking features.

I am surprised that after so much time this problem still persists.

@ cpatt - this issue is very old, and there has been some significant changes
since then.
Please look at the following for more details, clarification and resolution:

http://www.openoffice.org/issues/show_bug.cgi?id=95809
http://www.openoffice.org/issues/show_bug.cgi?id=91015

In short, there was a major change to the file locking mechanism in 3.0.x which
caused data loss in heterogeneous environments (ie OOo and any other office
suite opening files simultaneously). This behaviour was reported as a bug, and a
very robust and flexible solution has now been implemented, and will be included
in the 3.1.x release.

@ cpatt : 
P.S. The wiki entry to give you indicative timing for the 3.1 release:

http://wiki.services.openoffice.org/wiki/OOoRelease31