[Solved] OOo 3.0 cannot save to network drive

[cubrewer]

I use OOo on XP. I have a Samba fileserver (Fedora 9). I had been using OOo 2.4.x and I just installed OOo 3.0. Since installing 3.0 (i.e., everything worked peachy with 2.4, 2.3, etc), I cannot save files to some (previously-accessible) folders the mapped network drive. The error I get is: "Error saving document Untitled1: Object not accessible. The object cannot be accessed due to insufficient user rights." Also, if I open a file on the network, it opens but is readonly.

And it's just OOo 3.0 having this trouble, no other programs are having difficulty. The trouble is new, since I installed OOo 3.0. There have been no changes on the server.

Also, this occurs in some folders and not others, but it is NOT a Linux permissions problems: Notepad will happily create a file in the affected folder, and OOo 2.4 previously did. (And also I just double-checked the permissions and they are fine.)

Usually I google the specific error and I find a quick solution, but not this time..., any help would be MUCH appreciated because OOo 3.0 seemed to have many other great features... but not saving files is kind of a deal-breaker.

[acknak]

OOo3 uses a new method for locking the files it is working on. If you open a document named "document.odt", OOo creates a special file alongside the document with the name: .~lock.document.odt#. That's: <period><tilde>lock<period>document.odt<pound>.

Apparently, many network file systems do not allow file names with one or more of those characters. Since OOo cannot lock the file, it opens it read-only.

This is just my guess, based on a bug report that came up in another thread: Issue 94354: No write access to webdav folders, but maybe it would be worth a check to see if you can create a file with a name like that on your Samba share, and if not, maybe you can change the Samba configuration to allow it.

Please let us know what you find.

[cubrewer]

Ah ha. I had used the "veto" directive to hide dot files on the samba server. Now that I have removed this directive, OOo works great. That's a shame that this goofy interaction exists...

[acknak]

Ha! I almost deleted my suggestion because I went and did some checking on what systems would call that an invalid file name. From all that I could find, that should be valid on anything more recent than DOS (i.e. Win95-FAT-32 or newer), which is pretty much everything currently in use.

But it seems from what you found, and the issue I linked to, that some network services may impose other restrictions that conflict with the OOo lockfile names.

I have no idea why the OOo devs wanted to use that sort of name. I guess it's nice to not have mysterious lockfiles suddenly appear in people's file viewers, but the "starts with a dot = hidden" thing is hardly universal and seems a small payoff for possible naming problems.

Anyway, I'm glad it turned out to be helpful.

[cubrewer]

acknak, thanks!

[williamblue]

cubrewer, I have the same problem. How exactly did you fix it? I modified my /etc/openoffice/soffice.sh file, employing each of the variables: yes, no, auto and # (before the command setting) and I get no different result. I can open a file on the network server, but I cannot save the file once edited.

I am using OpenOffice 3.0, Ubuntu 8.04, and I am connecting to a windows server.

Thanks.

[cubrewer]

cubrewer, I have the same problem. How exactly did you fix it? I modified my /etc/openoffice/soffice.sh file, employing each of the variables: yes, no, auto and # (before the command setting) and I get no different result. I can open a file on the network server, but I cannot save the file once edited.

I am using OpenOffice 3.0, Ubuntu 8.04, and I am connecting to a windows server.

Thanks.

Is the "windows server" running Samba (on the Ubuntu machine)? If not, then none of this applies. Using Samba, there are different ways to hide files and I had enabled a directive called "veto" which prevents the Windows client from seeing files ...

http://www.google.com/search?hl=en&q=hi ... h&aq=f&oq=

In my case, I "vetoed" files beginning with a dot, which are Linux hidden files that do not normally show up in a directory listing (i.e., not in 'ls' but do with 'ls -a'); my home directory has a couple dozen. OOo 3.0 now uses lock files that begin with a dot, so I was preventing OOo 3.0 from working properly.

So, to allow OOo 3.0 to work, I just had to comment out that line (see below) from /etc/samba/smb.conf and restart Samba. In another setup, it might be elsewhere in smb.conf, you can do a search.

[cubrewer]
path = /home/amead
writeable = yes
browseable = yes
valid users = amead
# veto files = /.*/
follow symlinks = yes
wide links = yes

[williamblue]

cubrewer,

Thanks for the reply.

Ubuntu is loaded on my notebook. The file is located on a LAN network drive running windows.

When I open samba.conf I don't see a veto line to comment on.

Do I need to add the following lines to samba.conf on my notebook?

[blueserver]
path = smb://blueserver/documents/
writeable = yes
browseable = yes
valid users = williamblue
# veto files = /.*/
follow symlinks = yes
wide links = yes

[cubrewer]

Ubuntu is loaded on my notebook. The file is located on a LAN network drive running windows.

When I open samba.conf I don't see a veto line to comment on.

Do I need to add the following lines to samba.conf on my notebook?

So, you have the opposite problem. I was making changes on my Linux server. Modifying your client's configuration of Samba won't accomplish anything. I don't know how to allow such names on Windows (I'm not even sure it's possible). I believe I found others who had this problem with Vista computers. Maybe one of them has found a solution.

I'd probably download the latest 2.4.x version, which shouldn't have this problem.

If your "windows server" is one of these little NAS devices, it may really be running Linux or BSD and you may be able to modify that configuration.

[williamblue]

I have stumbled upon a workaround:

1. I deleted all fields in Tools -> Options -> OpenOffice.org -> User Data
2. I removed all commas from my file names (I usually preface all filenames with "letter," or "pleading,"
3. I edited /etc/openoffice/soffice.sh and disabled file locking by setting the value to "no."

To edit your soffice.sh file:
1. Open Terminal (Applications -> Accessories -> Terminal)
2. Type sudo gedit /etc/openoffice/soffice.sh
3. Change value from auto to no

Note I am running OpenOffice 3 on Ubuntu Hardy Heron 8.04.

Hope this helps someone else.

[cubrewer]

3. I edited /etc/openoffice/soffice.sh and disabled file locking by setting the value to "no."

So, probably this disabling of locking is what solved the problem. I did not know you could do this. I would imagine that for many users, file locking is not needed, although at least in theory, you could lose data this way.

[williamblue]

I have stumbled upon a workaround:

Apparently, I spoke too fast. After working yesterday, my problems resurfaced again today. The problem is definately NOT solved.

[noope]

Exactly the same problem here. I disabled dot files on my samba-home shares and cant save OO files there. With dot files enabled everything works. But I dont want to enable them, because the user should not see them in Windows.
So I will go back to the previous OO version, or is there an option to disable or rename the lock files?


Regards,
Marco

[acknak]

I'm not sure exactly what the problem is with Samba, but from what I read from the documentation, it should not be a problem if Samba represents dotfiles as hidden. The only problem I've seen mentioned is when Samba denies or changes a filename based on the characters in the name, so that OOo cannot create or open the lock files properly.

Unfortunately, I've seen no clear description of what the exact problem, or problems, are and what to do to fix it.

[cubrewer]

But I dont want to enable them, because the user should not see them in Windows.
So I will go back to the previous OO version, or is there an option to disable or rename the lock files?

I'm not aware of a way to use OOo 3.0 with this restriction, but are you sure you need this measure? I don't see the harm in allowing them to see these files (which, after all, are all readable and writeable). Samba can treat dot files as hidden, rather than veto'ing them completely, and then OOo 3.0 will work fine and Windows users will only see the files if they have disabled hiding hidden files--same as Windows.

I can say that OOo 3.0 has significant improvements, including the ability to open the newer MS Office files that people carelessly send increasingly often.

This post shows both the "hide" and "veto" approaches:

http://www.mail-archive.com/samba@lists ... 96165.html

[scananza]

Hello,
I'm using Linux Fedora 10 default OOo 3.0 to access files on a FreeBSD smb share. Unfortunately for me the problem persists:

• when I open a file, it is opened read-only and cannot be saved;
• if I then close it, I can see a hidden lock file (.~lock.FILENAME#) which ISN'T removed as it should when OOo's exiting;
• if I reopen it, it opens read-write despite the fact that a lock file is there;
• when changes are made and I try to save the file, it complains that it cannot be done due to some permission failure (this is false since I have write access on the share and every other program is not having troubles).

This looks like something very weird is going on....

This behaviour I think is the same as reported here:

http://forums.fedoraforum.org/showthread.php?t=206478

but no answer was found.

Googling around I tried these fixes, without luck:

• erasing user information in preferences (commas are known to cause problems but there weren't there);
• make sure smb server is not vetoing files with leading dots: it isn't, in smb.conf I have a "veto files = ";
• disabling OOo file locking from OOo startup script.

As you can imagine, using OOo on network shares (which is the default in my office env) is therefore impossible.

If anyone can tell me how to further investigate and possibly fix this, or even where to drop a bug report, this would be really appreciated!

Thanks a lot and best regards.

[acknak]

The things you've tried are the only workarounds that I'm aware of. The major bugs with the new locking design should be fixed in OOo 3.0.1, due for release next week--perhaps there is some other issue causing your problem that has been fixed.

Also, Fedora does make some significant changes to the OO.org code base, so it's not impossible that the Fedora-packaged OOo has problems that the OO.org package does not.

All I can suggest is trying the OO.org 3.0.0 (since that's the current stable release), and if that doesn't help, then try the 3.0.1 release candidate.

It should be possible to install the OO.org packages alongside the Fedora packages, but there have been package name collisions with pre-3.0 versions that caused problems removing or upgrading when both are installed. For testing, to avoid any unnecessary complications, I would remove the Fedora packages first, and only keep one or the other installed while testing.

[scananza]

Hi,
thank you for your prompt reply, my major concern about "original" OOo 3 is:

does it support smb access on linux?

As far as I can tell smb support, at least in the 2 release, was tipically added by the various distros and not provided by OO.org, so you couldn't manage network shares on linux with that version. Is it different with the 3?

[acknak]

Sorry, I'm not sure what you mean.

I assume that the Linux/Unix system would mount the network share using 'smbmount' or something like that. Then any application, including OOo, would access files on the shared location using a normal-looking path.

Are you using some other method?

[scananza]

It's not that simple, in order to access a smb share (whose mounting is manged by the appropriate linux interface, in gnome, for instance, by gvfs) OOo must be compiled with smb support; if not you merely won't be able even to see the network from the "open..." dialog within OOo. OOo 2 from openoffice.org lacked that switch which was, instead, added by the packaged version of all the major distros, don't know if it was included by default with the new 3 release...

[acknak]

Hmm, that's all news to me, but my experience with access to smb shares from a Linux client application is old and using the traditional system-level tools, not the newer desktop/application sharing schemes.

I've typically used smb shares the other way: from applications on Windows' accessing a network share (either Samba or another Windows host), and at least from the user's point of view, the application accessed the shared resource through a normal-looking file path, e.g. starting with a "mapped" drive letter. The same was true from the Linux side when I used smbmount to attach a remote share.

As for the desktop sharing schemes, I'm surprised that anyone would reply on them. The few times I've played with them, it's been a thoroughly disappointing experience. As far as I can see, things like gvfs still have major problems in transparency and integration, and needing special application-level support would go at the head of the list. Just my two cents, and probably off-target.

I have seen more than one report here of problems using OOo to access files over a gvfs/ssh link. The file could be opened, but not editied (it opened read-only for some reason not apparent). I found the same when I tried it from home; perhaps it's the same issue you're describing.

Thanks for the info; please post any solutions or workarounds you find.

[scananza]

Hi,
I've tried with community versions, both i386 and x86_64: smb support is now enabled but the problem persists, so it seems it's something upstream and not specifically Fedora-related.
BTW I've opened a bug report at bugzilla.redhat.com:

https://bugzilla.redhat.com/show_bug.cgi?id=479658

Just hope it will be helpful to gather some other information and to defy this annoying issue as soon as possible :^)

Later.

[scananza]

Tried Fedora's development 3.0.1 packages and problem is still there :^/

[steveedmonds]

I have also just had this problem arise. I have it with OOO2.4 on SUSE 11.0
I have an older samba server, a newer samba server (SLES9) and a NAS device.
Before Christmas openoffice could access files on SLES9 and NAS. Saving gave an I/O error but click save again and it saved. Opening was fine.

Now I can't open files on the NAS device with Ooo but I can on SLES9, saving hasn't changed. I can open and save files on NAS and SLES9 without problems with other applications (GIMP, seamonkey, etc.)

I have done a number of updates (system, not Ooo) since last year, so maybe it is an Ooo-cifs bug.

steve

[WildSioux]

You can add me to the list of not being able to save to a network drive I have a Dlink DNS323 NAS which is linux based. My current installed OS is Mandriva and XP. The XP OO version works and saves to the NAS as it should. I will just say that linux ((insert any linux OS here)) has failed for me. I have tried Opensuse 11.1, Kubuntu, LinuxMint, and Mandriva. LinuxMint and Mandriva are the only two that have worked for me. Well, did work until today.

LinuxMint worked fine with opening and saving to the NAS and as you know that was OO 2.4.1. But I couldn't get used to gnome (win95) and a few other things didn't work. Mandriva did work fine on a clean install with KDE 4.1.3. That too had bugs so I installed KDE 3.5.10. There was also a new kernal update along the way. Either way, now I can't save to the box.

I have tried the usual way of editing fstab for a mount on all distros other than mint and mandriva. Mint worked out of the box without having to mount. In mandriva, I use SMB4K. I have never found the manual way of editing in a mount point to work.

This is a serious issue for me since I can't even save my files. How hard can it be to open a file, edit it, and save? This problem has prevented me from fully switching to linux. I really don't know what to say other than either the linux distros I have tried are failures or OO is a failure, or both.

That is not the point, it JUST NEEDS TO WORK regardless.

Here is the error that I get on Mandriva OO 3.0:

Code: Select all

Error saving the document XX Xxxxxx 02-02-09: The operation on /home/xxx/DNS323/X & X Files/XX Xxxxxx 02-02-09.doc was started with an invalid paramter.

x two times.

Then I get this:

Code: Select all

Error saving the document XX Xxxxxx 02-02-09: General Error.
General input/output error.

I believe the second on is related to the file locking issue. But why was it working and now not?

Any ideas and help would be greatly appreciated. Thank you

[steveedmonds]

Now that I think back, the last trouble free saving I had with Ooo was with SUSE 9.3 and the mount.smb NAS mount. Now I am forced into mount.cifs which I have found causes me a range of compatibility problems in comparison.
Could it be a mount.cifs problem, anyone able to test with mount.smb?

[rjohns]

Recently downloaded 3.0. Using Windows Vista. I can not save files at all. I receive the error telling me I do not have sufficient rights to the file. I find a ~lock file on the drive. If I delete the ~lock file, I can then save the targeted file. Or, this worked until this morning. As of today, I can not save any files at all, first time or second time.

All other programs work. the computer otherwise seems fine. I have changed nothing since installing 3.0.1 a week ago.

I have deleted user information in OOo. No change. I have reset user information. No change. I have un-installed the program and then re-installed it. No change. The program is now useless.

I have looked through all of the posts here and so far no suggestions have corrected the problem.

Where do I go from here?

At the moment I am un-installing 3.0.1 and re-installing 2.4.0.

Help
rich

[WildSioux]

Just a follow up to my problem above of not being able to save to my Dlink DNS323 NAS. I have since moved to Sabayon which has OO 3.0

I believe I have found what the problem was, at least for me and I hope for others. I have never been able to mount by editing fstab manually. So I installed SMB4K and that was able to mount but still unable to save via OO. I have found that in Sabayon, SMB4K is the older KDE 3 version instead of the KDE 4 SMB4K. It still works the same as it is able to see my network, my NAS, and able to mount.

However, in the old KDE 3 version there is more options under "Samba." Maybe I overlooked it in version 4. But in version 3 SAMBA>Mount Tab>File System>"CIFS" or "SMBFS"

It wasn't working for me with CIFS. So I switched it to SMBFS, set a super user rule (since it wouldn't mount without it). And it mounts! I am able to open via dolphin (file manager), as well as open in OO, and I can now finally save to my NAS!

So I have found out that my Dlink DNS323 has SMBFS file system instead of CIFS. I vaguely remember reading something about it on one of the DNS323 forums of how to install CIFS files system on it. But this works and makes since to me now.

To others using linux, this method isn't found as a mount point in the fstab file. But it is instead found in the mtab file. I am not sure if I edited fstab if it would work that way or not. However, if CIFS doesn't work, try SMBFS.

Hope this helps someone!

[steveedmonds]

May be confirms what I suspected about CIFS but doesn't help SUSE users as SMBFS support no longer seems to be in the kernel.

[WildSioux]

@ steveedmonds:

Right, I now cannot save to my NAS. There was an update to SMB4k in Sabayon. It was 0.97 which is the older KDE 3.5 version. Now it is 0.10.1 and has been updated for KDE 4. The problem is now that the option for SMBFS is gone and only mounts as CIFS. As you said, it is no longer supported.

I seem to not be able to mount manually either (fstab). This has been the biggest issue for me to switching to linux entirely. It is really aggravating since it is 2009 and we can't even save a simple word document