Apache OpenOffice (AOO) Bugzilla – Issue 58107
[Samba] Strange error when saving to some SMB shares
Last modified: 2017-05-20 10:04:44 UTC
It seems that OOo 2.0 does some bad ACL checks before trying to save files, ot that it misintepretes the error code it gets when trying to open the file or check if it exists. When saving a document to one network share (on a Linux Samba server), OpenOffice.org 2.0 gives the following two error messages: --8<-- [OpenOffice.org 2.0] Error saving the document Untitled1: u:\testing.odt does not exist. --8<-- [OpenOffice.org 2.0] Error saving the document Untitled1: General Error. General input/output error. --8<-- Older versions of OpenOffice could save to the same share from the same machine. Actually, all applications exept OpenOffice.or 2.0 can save perfectly fine to the same directory on the share. Just open a file for write or write+create works perfectly fine, so OpenOffice.org must do something else. OpenOffice.org *does* manage to save files to another directory on the same share however. The difference in that directory is that I have explicitly set the inherited ACLS for owner and group. This normally makes no difference when just opening a file for writing, wich indicate that OpenOffice.org makes a bad ACL test before even trying to save the file. A case where less is more maybe. smbcacls reports the following for a directory where I *cannot* save the file: smbcacls //kansli/jonas Documents REVISION:1 OWNER:KANSLI\jonas GROUP:KANSLI\jonas ACL:KANSLI\jonas:ALLOWED//FULL ACL:KANSLI\jonas:ALLOWED//FULL And it reports this for a directory where I *can* save the file: smbcacls //kansli/jonas kansliet/PROGRAM REVISION:1 OWNER:KANSLI\kansli GROUP:KANSLI\kansli ACL:KANSLI\kansli:ALLOWED//FULL ACL:KANSLI\kansli:ALLOWED//FULL ACL:\Creator Owner:ALLOWED/OCI/FULL ACL:\Creator Group:ALLOWED/OCI/FULL I have seen the same problem in one of my own applications once. I thing it misinterpreted the error it got when trying to open a non-existing fiule as an access denied error, when the reason the access wasa denied was simply that the file wasn't there. I'm sorry, but I don't remember the details. I'll try to figure out exactly what I did wrong at that time and post it here. Regards /Jonas
The text below is all about Win32 API stuff. Some more testing and now I suspect I know what happens. The result of GetLastError is different for different shares and directories. I haven't the environment to compile OOo myselrf, so I'm not sure if my findings really do apply to OOo 2.0, but it does seem probable. Usually the GetLastError() result after CreateFile() when trying to open a non-existant file without specifying CREATE_ALWAYS, CREATE_NEW or OPEN_ALWAYS is ERROR_FILE_NOT_FOUND (2), but for some shares/directories (actually, most on hour Samba server) the result is ERROR_ACCESS_DENIED (5). Another possibility is hinted at in Microsofts documentation of CreateFile(): When an application creates a file across a network, it is better to use GENERIC_READ | GENERIC_WRITE than to use GENERIC_WRITE alone. The resulting code is faster, because the redirector can use the cache manager and send fewer SMBs with more data. This combination also avoids an issue where writing to a file across a network can occasionally return ERROR_ACCESS_DENIED. I have no idea wether this problem is really a bug in the version of Samba we are using, a bug in the Windows XP network redirector, a bug in the Win32 API or a bug in Microsofts Win32 API documentation. As seen above, Microsoft do mention in their documentation that it is possible to get strange ERROR_ACCESS_DENIED errors when opening files over the network. It is however possible to get strange ERROR_ACCESS_DENIED errors in situations other than the one they describe. The fix/workaround I've applied in my own app having the same problem was to check for the files existance when I receive an ERROR_ACCESS_DENIED in the above situation, and if the file does not exist the app behaves as if it received a ERROR_FILE_NOT_FOUND. /Jonas
TM->MBA: Please have a look. As far as I know, we don´t take care of ACL settings. Do we ?
Very propably an osl problem
I guess the problem is not the confusing error message but that it does not work at all. @mba: Actually I don't know how saving to a file works but AFAIK it's writing to a temp file and then renaming the files. This could be the problem in the described scenario. To preserve original ACLs the content has to be streamed into the already existing file instead of renaming it.
@jonaseckerman: OOo does no ACL checks. It just opens the file with exclusive access (FILE_SHAREDENY_WRITE). So what exactly is your problem. The misleading error messages or that it does not work at all ?
The problem is that OOo 2 simply cannot save files, new or changed, to some of our samba shares even though other apps (including OOo 1.x) have no problems. My second comment in this issue is my *guess* as to what actually happens. I first erronesously thought this ahd to do with ACLs as it as an access denied error and soem ACL juggling on the shares seemed to help. More checking showed that it might not be a ACL error at all.
Reset assignee on issues not touched by assignee in more than 2000 days.
Well 10 years later, Samba and AOO has been upgraded. WinXP is end-of-life. So, this issue can be closed.