Openoffice won't open files using sftp:// in read-only mode

Bug #41985 reported by Red_Phoenix
34
Affects Status Importance Assigned to Milestone
OpenOffice
Fix Released
Unknown
gnome-vfs2 (Ubuntu)
Invalid
Undecided
Unassigned
Declined for Feisty by Chris Cheney
openoffice.org (Debian)
Fix Released
Undecided
Unassigned
openoffice.org (Ubuntu)
Fix Released
Medium
Unassigned
Declined for Feisty by Chris Cheney

Bug Description

Pop an openoffice document on a sftp:// 'share' under gnome, attempt to open. File will open in read-only mode, even if permissions are otherwise correct.

A text-file in the same directory, will open in read-write mode with no problems in gedit, which eliminates gnome-vfs.

From memory, early versions of breezy worked fine (as did FC4).

***WORKAROUND by Guttorm Flatabø:
Gvfs has its own folder in the home folder called .gvfs where you can access all gvfs mounted drives. If I navigate to the file and open it through Nautilus, OOo will open it read-only.
***EOW

Revision history for this message
Rick Gabriel (klaxian1) wrote :

I am also experiencing this bug in Dapper beta 1. Even opening the same text file with openoffice and gedit produces the results described above.

Revision history for this message
Philipp Schlesinger (philipp-sadleder) wrote :

This bus is still present in Edgy.
For the record: It works well in Debian (2.0.4-2).

Revision history for this message
Philipp Schlesinger (philipp-sadleder) wrote :

It is nearly impossible to download ubuntu and debian diffs to OOo compare them, they are simply to big (~60MB)
It would be great if a OOo maintainer could comment on patches in debian and ubuntu packages and maybe find the difference causing the bug.

Revision history for this message
Antti Pirilä (antti-pirila) wrote :

I have the same problem.

I have following setup:
Workstation:
ubuntu 6.10 with OOo, my user number is 1000.

Server:
Linux with opensshd. In this machine my user number is 500. I user public key based authentication.

I can make the file editable from OOo by
1) chowning the file in the server to a (non existing) user number 1000 and make it group readable,
2) make the file world writeable or
3) use same user numbers in client and in server.
These solutions work as a work around in very limited situations, of course.

The initial report states that this is not a gnome-vfs bug. However the same problem exists in Nautilus privilege property sheet, so this might well ultimatly be a gnome-vfs problem. I've attached a screen shot from the property sheets. The file on the right has owner 500 and the file on the left has owner 1000. I've even chmoded the file on the left to 600, so I don't in reality even have a read permission to the file and the Nautilus states that it is owned by me. :)

Revision history for this message
Antti Pirilä (antti-pirila) wrote :

I think this bug is reported here: http://bugzilla.gnome.org/show_bug.cgi?id=346676

The problem is that gnome-vfs takes the uid of a file directly from the server. The patch changes the behaviour so that every file has uid of the current user. Better approach would to first check if we really have permissions to the file and if so, change the uid.

I wrote a small patch based on the patch reported on the above bug and old code taken from the gnome-vfs's CVS repository . The patch fixed this issue, atleast for me. However the patch may have other problems.

Revision history for this message
Sebastien Bacher (seb128) wrote :

Upstream is usually responsive on the gnomevfs-list, they use it for patch review too, maybe you could post your patch to the list?

Revision history for this message
Philipp Schlesinger (philipp-sadleder) wrote :

As stated above, opening files using sftp:// works on Debian, so it should be possible to figure out the problem for an experienced person.

Revision history for this message
Philipp Schlesinger (philipp-sadleder) wrote :

I'd like to withdraw my statement that it works in Debian, which is _not_ true. Debians OO.o and gnomevfs (whichever is the problem) suffer from the same issue.

But, as stated above, gedit does open/save files on a sftp share if either owner or group has read permission, like one would expect it. Based on that, I think the bug is in OO.o and would like to provide additional information to help resolve it.

Revision history for this message
Philipp Schlesinger (philipp-sadleder) wrote :

I tried the uid-gid-hack.patch for gnomevfs.
It doesn't alter the situation for OO.o after all, but improves for the corresponding nautilus upstream bug: http://bugzilla.gnome.org/show_bug.cgi?id=346676

Revision history for this message
Philipp Schlesinger (philipp-sadleder) wrote :

The attached file shows a section from OO.o source.
It checks if the remote file has owner or group matches the uid/gid of the running Openoffice process (!)
This is all just plain wrong:

- Local and remote users/groups aren't necessarily matching.
- Openoffice checks things which lay in the domain of libgnomevfs
- Even if users/groups are in sync on local/remote system, there can be supplementary groups the user (on both sides) can be part of.

Of course, this is an upstream problem, but I don't know where to report that in a proper way and I think Ubuntu/Debian maintainers could help getting that nasty problem fixed.

Changed in gnome-vfs2:
status: Unconfirmed → Rejected
Changed in openoffice:
status: Unconfirmed → Unknown
Changed in openoffice:
status: Unknown → Unconfirmed
Changed in openoffice:
status: Unconfirmed → Confirmed
Changed in openoffice:
status: Confirmed → In Progress
Revision history for this message
Philipp Schlesinger (philipp-sadleder) wrote :

I can state that opening files read/write remotely via sftp:// with OOo in Ubuntu feisty works as expected. People who had that problem as well: please recheck and report back.

What doesn't work now is opening files via sftp:// that have only read permissions. OOo reports a "common error in the internet area" (translated back from german).

Revision history for this message
Philipp Schlesinger (philipp-sadleder) wrote :

It would be great if some other people could report back on this bug. The main issue is fixed for me, so maybe for others as well.

Revision history for this message
Red_Phoenix (intersect) wrote :

I can confirm that the problem no longer exists for me under Feisty.

Appreciate the effort Philipp.

Revision history for this message
Johannes Rohr (jorohr) wrote :

Also confirming that it is fixed. Thanks!

Changed in openoffice.org:
status: Unconfirmed → Fix Released
Changed in openoffice:
status: In Progress → Confirmed
Changed in openoffice:
status: Confirmed → In Progress
Chris Cheney (ccheney)
Changed in openoffice.org:
status: New → Fix Released
Revision history for this message
Philipp Schlesinger (philipp-sadleder) wrote :

Well, only part of that bug is fixed.
As described in https://bugs.launchpad.net/ubuntu/+source/openoffice.org/+bug/41985/comments/11, opening document with read-only permissions at a remote location doesn't work.

Revision history for this message
xorkid (syd-shah) wrote :

Hi All,

For me the problem still exists with OO.org in Hardy (fresh install latest beta updates as of 9/4/08)

This is for files with read write permissions. The OO dialog asks for password but fails after 3-4 tries with "General Internet Error". I have seen this behavior since feisty..

According to http://www.openoffice.org/issues/show_bug.cgi?id=75446 it wont be fixed til OO 3!

Please could someone fix this please ask if there is any more information I could provide. I would really appreciate a fix for this!

Revision history for this message
Keith Clark (keithclark1966-rogers) wrote :

Problem exists for me as well in Ubuntu 8.04. I cannot open a file via sftp. It asks for my password twice and then gives a "General Internet Error". I've gotten around this by running Open Office Calc via a ssh session, but this is a very slow way and taxing on my server.

Thanks,

Keith

Revision history for this message
admmoore (j-adminc3-charter-net) wrote :

I have had the same problem for a while now.....a local Linux Engineer told me to set up SSH public /private keys. You will have to have the login and password on the local and remote server the same. Set up the keys as follows:

SSH Version 2
Step 1
at the command line type ssh-keygen -t dsa
(the following you should see as output)
Generating public/private dsa key pair.
Enter file in which to save the key (~/.ssh/id_dsa) just hit enter
Enter passphrase (empty for no passphrase) just hit enter
Enter same passphrase again just hit enter
Your identification has been saved in ~/.ssh/id_dsa
Your public key has been saved in ~/.ssh/id_dsa.pub
The key fingeprint is
(there will be some really long string)

Step 2
copy the ~/.ssh/id_dsa.pub file into the file ~/.ssh/authorized_keys on the remote server/host

Then reboot and retry your connection. (Go to Places, Connect to Server, Choose SSH and enter all info) You should be able to open read/write files directly from the server and save them directly to the server (however, to save them directly to the server you will have to include the entire server file name. EX. ssh://user@remotehost/locationforfile/filename)

SSH Version 1
Step 1
at the command line type cd ~/.ssh
then type ssh-keygen -t rsa1
(the following you should see as output)
Generating public/private rsa1 key pair.
Enter file in which to save the key (~/.ssh/identity) just hit enter
Enter passphrase (empty for no passphrase) just hit enter
Enter same passphrase again just hit enter
Your identification has been saved in ~/.ssh/identity
Your public key has been saved in ~/.ssh/identity.pub
The key fingeprint is
(there will be some really long string)

Step 2
copy the ~/.ssh/identity.pub file into the file ~/.ssh/authorized_keys on the remote server/host

Then reboot and retry your connection. (Go to Places, Connect to Server, Choose SSH and enter all info) You should be able to open read/write files directly from the server and save them directly to the server (however, to save them directly to the server you will have to include the entire server file name. EX. ssh://user@remotehost/locationforfile/filename)

Now if I could just find a way to select the server as the save as location instead of having to type the whole thing in with the filename!!

Hope this helps!!

Chris Cheney (ccheney)
Changed in openoffice.org:
status: Fix Released → Confirmed
Revision history for this message
Sergios (linuxmangr) wrote :

Hi . I think is the way , to edit doc , odt file from sftp I use Abiword and is worked ok, I edit 1 file and no problem but with OO is not work , I try to edit with Kword is is worked.
For the problem with OO have solution ?

Chris Cheney (ccheney)
Changed in openoffice.org:
status: Confirmed → Triaged
Revision history for this message
Pablo Castellano (pablocastellano) wrote :

I can also confirm this behaviour in Intrepid 8.10 fully updated.

From upstream:
------- Additional comments from tkr Fri Jun 6 12:53:50 +0000 2008 -------
For now I will set the issue to OOo 3.1.

:-/

Revision history for this message
netmastr (netmastr) wrote :

I have been having the same problem(s) in fedora9 both OOo 2.4.X and 3.0. Thought the information might be useful. Using the public/private key as described above but did not change the symptoms. Still looking for a workaround.

Revision history for this message
Guttorm Flatabø (dittaeva) wrote :

I have the same problem in OO 3.0 on Ubuntu 8.10.

Revision history for this message
Guttorm Flatabø (dittaeva) wrote :

I have the same problem in OOo 3.0 on Ubuntu 8.10. The files rw or read-only. Here's a workaround to get read access though:
Gvfs has its own folder in the home folder called .gvfs where you can access all gvfs mounted drives. If I navigate to the file and open it through Nautilus, OOo will open it read-only.

Revision history for this message
Sergios (linuxmangr) wrote :

Ok, this problem is exist , but you can try to setup NSF disks and files can be read and write by OpenOffice and any other programs , you can see movies or listen ogg , or mp3 from the disk with mounting is by NSF protocol not sftp , sftp is good for transfer file by network , not to open and edit some documents .

description: updated
Revision history for this message
Chris Cheney (ccheney) wrote :

I believe this issue has been resolved in Jaunty (Ubuntu 9.04) due to switching to using gvfs fuse instead of gnome-vfs/gio directly. If you still have trouble please feel free to reopen this bug and follow up with more information.

Changed in openoffice.org (Ubuntu):
status: Triaged → Fix Released
Changed in openoffice:
status: In Progress → Fix Released
Revision history for this message
Erik Reuter (misc71) wrote :

With karmic, has anyone tried opening sftp:// Open Office documents ?

When I double-click on .xls files on an sftp:// volume, I get:

  Could not display "sftp://remote/file.xls".
  There is no application installed for Excel spreadsheet files

But the Properties / Open With for the file correctly lists Open Office spreadsheet. Also, if I right-click on the sftp://.xls file and choose open with other application...open office spreadsheet, then open office starts but does not load the file (just opens a new blank spreadsheet).

I regularly opened sftp://.xls files in jaunty, but after upgrading to karmic I no longer can. I'm not sure if it is a Gnome change, or an Open Office change.

Also, if I drag the sftp://.xls file to the local desktop, then the .xls can be opened by double-clicking.

Should I file a new bug report, or re-open this bug which looks similar (but maybe not identical?)

Revision history for this message
Erik Reuter (misc71) wrote :

I should have mentioned that I am using Free-NX. I think this is relevant, since I just noticed that there is no file system mounted in ~/.gvfs/ when I access an sftp:// volume with Free-NX.

I tried opening an sftp://.xls file in karmic without Free-NX (just a local Gnome desktop) and that did open correctly.

Another data point is that I can open sftp://.pdf files by double-clicking in karmic, with Free-NX.

So the problem I am seeing appears to involve Free-NX, Open Office, and sftp://.xls files. And karmic (same thing worked correctly in jaunty). What package(s) should I open a bug against?

Another data point: I just tried opening an sftp://.odt file by double-clicking, and bizarrely File Roller 2.28.1 opened with a blank window, even though the file properites / open-with are correctly set to OpenOffice.org word processor. If I write click and open with OO wordprocessor, then OO starts up but does not open the file (just gives a blank document).

One more data point: if I write click on the sftp:// window and create an empty file, then double click the empty file, I get "Could not display sftp://remote/new%20file. The file is of an unknown type".

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.