Issue 54567

reassigned

Hi 

I have been experiencing the same problem. Not only can I not save on a SMB
network drive I cant even open files from that drive. The program gives an I/O
error but saves a 0kb .odt file. It is not a problem with one or the other
component write, calc and impress all do the same. I am pretty sure it is not a
problem with the OS (Mac OSX 10.4) since my neooffice/j and M$ office opens them
fine and saves them too. I took a couple of screen shots but don't kno how to
up-load it into this page (i dont see an option for attachments)
it reads (de-accented)
Opening error: Erreur generale d'entree/sortie lors de l'acces a
/volumes/devbio/***/***/***/***.xls
Saving error: erreur lors de l'enregistrement du document sans nom1: Erreur
generale sortilors de l'access a /volumes/devbio/***/***/***/***.odt


Thanks

Shiv

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

work around:

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

Hi,

thanx - the workaround works for me.

To change the file, you have to have administrator rights
You should then use the Terminal - pico editor.

cheers,
lomograf

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

The workaround dosen't fully work for us.

After applying the change, the frequency of bug appearance has lowered. When
error occurs, user is now able to save the document. For example, autosave
generated eroor, but then I used manual save and this worked. Saving with
different name worked partially, OOo has frozen after save and the file was
considered damaged when opening next time.

So, the workaround works, but DOES NOT RESOLVE THE WHOLE PROBLEM.

As of NFS, the workaround works to extent, that NFS files can be opened now (it
has been impossible before).

I cannot say if it removes the whole problem from NFS -I haven't tested it much
so I don't know, if there'll be not casual error on saving the document, such as
in the case of SMB.

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

Hello , we've the same problem since the first version of OOo . We store the
document on a server with a samba partition . When we try to open one of this
document directly from the server , OOO fall in error . We must make a copy of
it on our desktop , work on it , save and after replace it on the samba
partition . This happens with OP on the clients windowsXP or linux independently
. We've never resolve the problem unfortunately but sincerly I've not understood
how to apply the "work around" written below . It works only for Mac ? 

Thanks to all , Lorenzo

Please, someone with sufficient privilegues, do perform these changes:

Platform: All
OS: All
Summary: Input/Output error on network-shared documents
Status: NEW

The work around outlined by jsi perhaps is applicable if the client is Oo for Mac.
Our situation is : Windows client and Mac 0sx 10.4.3 server.
So we have to applie the WA to a windows Oo and we have not found the way.
Some one can help to find the applicable INI option?

Thanks.
CAP

Any news about this unsolved problem ? 
Many thanks ... Lorenzo 

Hi, 
I'm having the same problem with OOo 2.0.1-1-i568 (Debian) and various NFS-shares.
OOo 1.x (from 1.1-1.5) worked fine. So does smb-Access with OOo 2.0.1 (Windows
and Debian).
The workaround (SAL_ENABLE_FILE_LOCKING=1) has already been commented out by
installation. Setting SAL_ENABLE_FILE_LOCKING=0 and exporting it didn't help either.
Let me know, when I can help in testing.

Significantly reported on Windows.

Can anyone confirm it happens while Linux to Samba accessing, please?

Hello,

We've significantly recorded this problem on Mac OS X and on almost all Windows 
versions, but it isn't clear, when this problem occurs - its behaviour isn't 
regular on all configurations although the base enviroments are the same - Samba 
and Windows or Mac OS X as server or client. 

We have reports, it occurs, and reports, there is no problem. It is very 
questionable - probably, i think, because of some OpenOffice.org/Samba 
configuration incompatibilities.

--

Martin Kozák
(CS User Support Leader)

*** Issue 54567 has been confirmed by votes. ***

Could it be marked P2?

When facing this problem, we have had situation here, that in consequence, the
document has been overwritten by zero-sized one (despite of claiming the "I/O
error). Once the OOo has been closed (and it probably HAS BEEN because it often
crashed after the error), the document has been COMPLETELY GONE!

We need more info. Should be well to make clear, when problem occurs. This is 
relatively important problem, but nobody doesn't know anything about it.
--
Martin Kozák
CS User Support Leader

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

Please, could anybody tell us, the users, what could we do to help solving this
problem?

And could it FINALLY be marked P2?

I still got Linux, rarely even Windows users that couldn't save their documents
becouse of this ****ing problem.

Taking in account, how this bug is annoying and how it leads to data loss, I
wonder how could NOTHING happen for nearly HALF YEAR since it has been reported.

Files randomly don't save, OOo20 crashes with "General I/O error" and nobody
really cares.

martinkozak: Yes, it affects Linux/Samba too. It affects all systems (excepting
Solaris that I don't know). There is significant number of duplicates of this
issue and they include a rich bunch of systems:

Issue 56926
Issue 57421
Issue 58215
Issue 52531

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 

That's it. Someone has been looking for more information, so I have provided as
much information as I have.

Removed mru from cc.

We are working on a small network of 4 Computer (Workstation Setting) under Win
XP all Computer SP2 and having on all Computers the same problem since updating
from OO 2.0 to OO 2.0.1. and OO 2.0.2.
As we are working daily with the same docs from our main workstation this
situation is more than annoying. We have had the same problem after updating
from 1.1.3 to 1.1.4. This problem has been solved when updating to 2.0 beta. I
guess it is the same problem we had with the 1.1.4 version.

Judith

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

Confirmed the SAL_ENABLE_FILE_LOCKING=1 on OS X 10.4.6 on PPC and Intel with
both Samba and AFP servers

Confirmed the SAL_ENABLE_FILE_LOCKING=1 on OS X 10.4.6 on PPC and Intel with
both Samba and AFP servers

client: linux/FC5 OOo 2.0.2
server: linux/FC4 samba 3.0.14a

edit existing document 
- first save -> "could not create backup copy"
- second save - ok

This is why Open Source will never be taken seriously, bunch of hacks thinking 
they're programmers though they think the real issues are worth dealing with.

Seem pretty much layed out there.  Somewhere the path is not able to see 
network when being saved.  Works good to the local drives - seems like a 
logical place to start looking from.

Fill free to kick me off this site - isn't worth a sh^t anyhow!

NEED MORE INFORMATION!

wrong owner, reassign.

That's not my turf. hro: could you please have a look ?

.

Suddenly, the error occured for me.

Fortunately, I've got debug mode turned on on the Samba server. So I'm posting
logs. I have had file rozpocet 2006.sxc opened and tryed to save it as reozpocet
2006.ods

Samba version is 3.0.14a-3sarge2 (Debian Sarge) on server and 3.0.23d-1 on
client (Debian Etch).

Created attachment 41372 [details]
log file from Samba server

What's strange, after the error, I cannot even create a file from console on
that path. I tryed to do ls >ls.log and here's the log from samba server. I got
kinda "no such file or directory" error.

Created attachment 41373 [details]
log from Samba server while trying to create ls.log

It is quite interesting, that Samba seems to process every file in the directory
by some means.

Could possibly the bug be caused by usage of diacritical symbols in the file names?

I'm posting ls -la log

Created attachment 41374 [details]
ls log from the actual directory

Oops, I was so excited by the possibility of logging that I overlooked, that I
didn't have an access to the directory in fact.

Consider my todays previous posts as false.

Please, could someone remove the misleading attachments, please? I'm not allowed
to..

I'm sorry. Was too happy to help with the pesky bug..

No problem, thanks for trying to help us.

On my system I get:

Error saving the document Untitled1:
The operation on
<my-network-path>t.odt was started with an invalid parameter.

No saving happens.
The same error is reported on reading a file.
The problem can be repeated using OO 1.1.5.


In 2.0.4's soffice script the lines:
 SAL_ENABLE_FILE_LOCKING=1
 export SAL_ENABLE_FILE_LOCKING

 are enabled by default. Disabling them allows OO to work, but
 then no locking of the given file happens, that is almost as
unacceptable in a workgroup, as not being able to r/w.

- network drive served by Windows
- client: FreeBSD 6.1 with smbnetfs

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

Now, Issue 68348 and this cross-references each other (OK, if it is so intended)

I just wanted to add that the problem still exists for 2.1.

Though this issue is a mixup of different scenarios most of the problems might
be caused by the fact that network connections may be going down while OOo has
the file open -> file handle is no longer valid.

Need a mechanism to reopen a broken network file handle.

Setting Target to 3.0

How do You imagine the "network connections going down"?

Although I tend to be polite, I must object the target milestone 3.0.

This bug annoys users for year and half, it is P2-grade bug (data loss). Taking
in account, that the bug was uncovered as soon as during 2.0 BETA stage, should
been fixed even BEFORE 2.0. It's bad enough that it made it to the stable 2.0,
bad enough it was not fixed for 2.0.1, 2.0.2, 2.0.3, 2.0.4, 2.1 and just pushed
to 2.x. Pushing it towards next major is really bad. What will be done then?
Pushed to 3.x and then to 4.0?

Cite: "Issues with this priority must be fixed before the target release (see
Target milestone), which usually is the next major release, and should be dealt
with as soon as possible. Not fixing them for the target release is not acceptable."

Cite: "# User data is corrupted in an easy-to-encounter way;
e.g. saving a document corrupts the resulting file and renders it unusable
# Crashs or freezes during normal operations of the application"


Pushing the bugs does not resolve them, nor it makes users happy. I'd rather
spend more time waiting for next release to see the bugs actually fixed, than
watching bazillions of releases with no visible progress on serious bugs. I'm
happy for tiny tweaks here and there, but this dosen't make the major bugs
dissappear. Could anything annoy users even more than severe, well-known,
years-lasting bug?

I'm working in a heterogene network infrastructure with NFS, Samba, NT Servers
and client on Windows, Solaris and Linux.

The problem is not reproducable here.

I don't want to talk about the technical background, but most of those problems
occur because of misconfigured network evironments (f.e. samba configuration).

Every network file system/client has different underlying locking mechanism
which have to be translated.

OOo uses the common C runtime APIs for locking. What's going on under the hood
is not OOo but it's the operating system/network file system layer.

This issue is a mixup of completly different scenarios, different servers,
different clients, different OS, different problems.

Read the comments of this issue (including yours ;-)) You wrote that there's a
problem on WinXP if the drive mapping has gone for some reason. Others said the
problem has gone with XP SP" the next one says it's still there.
Maybe there's a problem when using UNC network paths instead of mapped drives.
If so this would be a complete different problem than using a Linux served SAMBA
server.

What OOo might handle different than other apps is that it holds the file handle
open. That's a problem when the network connection has gone.

Not enough resources to fix this for next micro release. Setting Prio to P3

Whoaa, lowering the priority, I wonder, who would expect this? Well, actually,
anyone who has ever made a deal with OOo P2 dataloss grade bugs.

"Not enough resources to fix this for next micro release. Setting Prio to P3"

Not enough resources ..this is pretty clear for most long-time OOo users.
Setting Prio ..this is common mistake here in OOo. How could low resources
implict lower priority of severe bugs?

The bugs are not less serious becouse of lack of resources. This is just
sweeping the crap under the bed.

Just face the problem.
-Yes, there are dozen of P2 bugs in OOo.
-Yes, we don't have resources to fix them.
-Yes, there will not be major release anytime soon, because it dosen't make
sense to shoot out major releases with years lasting P2 bugs.

>Every network file system/client has different underlying locking mechanism
which have to be translated.

Yes. Many have kernel-level support mechanisms to handle that, luckily.

>OOo uses the common C runtime APIs for locking. What's going on under the hood
is not OOo but it's the operating system/network file system layer.

Please, try to connect this with the simple fact, that there is NOT any other
program known, that produces this error. It's ONLY the OOo, and ONLY after 680m125!

>Read the comments of this issue (including yours ;-)) You wrote that there's a
problem on WinXP if the drive mapping has gone for some reason. Others said the
problem has gone with XP SP" the next one says it's still there.
Maybe there's a problem when using UNC network paths instead of mapped drives.
If so this would be a complete different problem than using a Linux served SAMBA
server.

My comments are from bigger part just comments made by users in ooo-cs mailing
list. I took them and translated here to help with recognizing the problem.

Yes, the issue seems to have several paths of impact. However, not easy to
"decode" and with no uniform results.
One could have something to do with mapped/not mapped network shares.
Another one means that opening a document from Linux-Linux Samba connection
makes OOo loss Your data with quite a probability.

>What OOo might handle different than other apps is that it holds the file
handle open. That's a problem when the network connection has gone.

Now if this is that easy, then it should be reasonably easy to solve the whole
problem. Just do it the same way the M$Office does?

My mistake, I meant target 2.3 :-)

.

@hro: I'm happy to see that work on this issue has been started. 
What kind of locking issues will the fix resolve. E.g. we've observed that in
some situations opening a file on a Samba share with OOo from a Windows machine
and then attempting to open the same file with OOo from a Linux machine gave an
I/O error on the Linux machine rather than an end-user suitable message that the
file is locked by another user. Is it forseeable that the fix for this issue
will resolve this problem, too, or is that another issue?

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

@mux2005: What you stated is that cross platform file locking works but the
message that pops up isn't clear enough. You might flag this as a defect but of
less severity.

Other here seem to have the problem that file locking does not work at all.

Because the mixup of different scenarios that can't be fixed we will first of
all provide a HOWTO setup a samba server to a working environement within 2.3
time frame.

This will be useless for a lot of people.

My own scenario is simple: windows client, windows serveur, laptop with wired
ethernet (our IT people haven't decided yet to do wifi)

LAN cable is often disconnected (moving laptop somewhere else, flacky ethernet
connectors in the building). When it's reconnected every app just restarts using
the network share except for Oo.o that 
1. first displays an unhelpful popup about the original location not being
accessible (it is, the cable has been replugged)
2. then quickly proceeds to lose data if you try to save your file somewhere else.

How a samba doc setup is going to help me?

You may write I've got a different issue, except other OO.o people duped it
there, so they clearly consider it the same problem.

Again and again: Please refrain from mixing complete different issues !!! 

If this mixup goes on I'll close this and every furture task of this kind "me
too, I got problems with files on the network, must be the same".

@nmailhot: See issue i73979, this would be yours, has nothing to do with file
locking/file accessing problem in heterogene networks that are connected the
whole time.

Target set

FYI. I may have stumbled across the cause of this bug and, in our case, the
cause was found to be that either of the following products on a Mac OS X
machine had the file open: OpenOffice.org X11 or NeoOffice.

Although I initially suspected that the bug was in SAMBA or the OOo Windows
code, I eventually found that the code that caused this problem was the Mac OS X
code in sal/osl/unx/file.cxx.

Some time ago, a Sun engineer changed the file locking code from using the Linux
and Solaris file locking logic to custom logic. In short, by reverting the file
locking code back to using the Linux and Solaris logic, opening a file from Mac
OS X no longer caused errors for OOo Windows clients.

To determine if this bug is the same as the bug I found, try the following:

1. Determine if you have any Mac OS X machines that are connected to your SAMBA
file server that are running OOo X11 or NeoOffice. If the answer is no, then
ignore this post as it isn't applicable to your case.

2. Open a file that no machine has open on a Mac OS X machine using a recent
version of OOo X11 or NeoOffice.

3. After the file is opened in writable mode on Mac OS X, try opening the file
using OOo Windows.

If you cannot open the file and OOo Windows gives you an error dialog, then this
is likely to be the cause of the bug. If you want to be absolutely sure that
this is the cause, install NeoOffice 2.1 plus Test Patch 9 from the following
URL (search for Patch-7-Test-9 in the bug to find the test patch URL for your
Mac OS X platform):

http://bugzilla.neooffice.org/bug.php?op=show&bugid=2443

Once you have NeoOffice 2.1 plus Test Patch 9 installed, repeat steps 1 through
3. If OOo Windows can now open the file in read-only mode, then we have
confirmed the cause of the bug.

For the Sun developers, the fix is very simple: remove all of the following
custom Mac OS X code from sal/osl/unx/file.cxx so that file locking is handled
the same as Linux and Solaris:

#define HAVE_O_EXLOCK
adjustLockFlags()

The version 2.3 (target for this bug as seen in the comments, not seen in 
issue's header) is out, but no mention of the issue is in the release notes. 
Can we learn about when it is to be solved?
Thanks!

for me it makes a difference if i mount the samba-share as filesystem smbfs or
cifs. with smbfs it works, with cifs it's like:

edit existing document 
- first save -> "could not create backup copy"
- second save - ok

(sadly cifs is much faster than smbfs)

client: ubuntu 7.10, OOo 2.3
server: samba 3.0.x

with another windows-PC with the same OOo version there's also no problem.

Hennes,
please consider this defect for 3.0.
Thanks.

As I've already mentioned file system locking causes problems with heterogene
network file systems.
This is not really fixable for all scenarios. OOo relies on file locking
mechanisms so we try to archive a non file system based locking for OOo 3.0.

Setting as duplicate to follow-up issue.

*** This issue has been marked as a duplicate of 85794 ***

close the duplicate