After adding a new SSH connection there is no feedback provided - there is no authentication error etc. Nothing appears to happen other than the new SSH connection is added and can be seen in the "Service" list pull-down.
Using the "Edit service" pull-down option on the "Add service" button displays the "File Services" dialog, but after entering the same username used when creating the new service the "OK" button is still greyed out.
The SSH server is provided by the OpenSSH Server running under Ubuntu 14.04 Server.
I can confirm the same bug on Xubuntu Xenial System 64 bit. I do not know if this is a bug in LO or a configuration issue. New to LO and the documentation is quite sparse on the issue.
i found a fix for this:
sudo apt-get install libreoffice-gnome
i don't know why this is not installed by default?
i will checx my logs and see if it was uninstalled somewhere.
i am running a fresh install of xubuntu xenial
(In reply to William Geiger from comment #2)
> i found a fix for this:
> sudo apt-get install libreoffice-gnome
> i don't know why this is not installed by default?
> i will checx my logs and see if it was uninstalled somewhere.
> i am running a fresh install of xubuntu xenial
It seems that xenial doesn't install all files of LO, even Base isn't available.
Does the problem still exists if you download and install the whole package manually ?
(In reply to MM from comment #3)
> It seems that xenial doesn't install all files of LO, even Base isn't
The Ubuntu images don’t contain all the LibreOffice-related packages because of space constraints. Anyway, please take those issues to https://launchpad.net/df-libreoffice, as they are not directly related to the upstream LibreOffice project.
(In reply to Adolfo Jayme from comment #4)
> (In reply to MM from comment #3)
> > It seems that xenial doesn't install all files of LO, even Base isn't
> > available.
> The Ubuntu images don’t contain all the LibreOffice-related packages because
> of space constraints. Anyway, please take those issues to
> https://launchpad.net/df-libreoffice, as they are not directly related to
> the upstream LibreOffice project.
Personally, I always download & install manually.
Eric: we need further information from you based on all the comments so far.
Set to NEEDINFO.
Change back to UNCONFIRMED, if the problem persists. Change to RESOLVED WORKSFORME, if the problem went away.
I'm not sure what additional information you require? Let me know and I'll assist.
Note that I am running LibreOffice on the Windows 7 platform, not Linux.
I have just installed LibreOffice version 188.8.131.52 and the problem still persists.
Remote File Type = SSH
We have a Linux server running a SSH service. We can connect to the server from any machine (including a Windows machine) using an SFTP Client and access files - copy, delete, add files etc., so we know that remote SSH works OK.
Adding the same connection details to the "Remote Files" appears to add the service but nothing is shown in the file list.
If I then try to "Edit Service" with the recently added service selected, the pop-up dialog has a blank user name, displays the label, but there are no edit boxes for the the other fields originally entered. Re-entering the "User" name does not restore the state of the greyed-out "OK" button.
Remote File Type = Google Drive
Using this option with a valid Google Drive account results in a "The specified device is invalid" error dialog.
I've observed the same results as Eric when using libreoffice 5.1.2 and attempting to open ssh remote files on both Windows 7 and debian stretch.
Upon adding an ssh connection in "Remote Files", the service is added, but nothing happens -- no file list. This is on both debian stretch and windows 7.
Upon selecting "Edit Service", the pop-up dialog has a blank user name. After entering the username, the OK button is greyed out. It does not appear possible to save the user name.
One of the user comments in bug 98723 suggested installing the libreoffice-gnome package instead of plain 'libreoffice'. Previously I had installed 'libreoffice' on debian stretch. After installing libreoffice-gnome on debian stretch, opening a ssh remote file results in a pop-up dialog saying 'nonexistent file'.
The file exists, and the ssh service is working, based on tests with scp and ssh.
I would be glad to try to gather more info if anyone can point out info on how to enable debugging logs.
(In reply to Richard from comment #8)
> I would be glad to try to gather more info if anyone can point out info on
> how to enable debugging logs.
On Debian, you install the libreoffice-dbg package.
Did this work in an older version?
NEW per comment 8.
(In reply to Buovjaga from comment #9)
> (In reply to Richard from comment #8)
> > I would be glad to try to gather more info if anyone can point out info on
> > how to enable debugging logs.
> On Debian, you install the libreoffice-dbg package.
> Did this work in an older version?
> NEW per comment 8.
Older versions had the same issue back to 5.0 at least.
I can try earlier ones as well if needed.
I'll install libreoffice-dbg on debian, and gather more info with --backtrace.
Thanks so much for your help!
Here are instructions for testing older versions (and a link to old version archive): https://wiki.documentfoundation.org/Installing_in_parallel/Linux
** Please read this message in its entirety before responding **
To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.
There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.
If you have time, please do the following:
Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/
If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.
Please DO NOT
Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not
appropriate in this case)
If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/
2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword
Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa
Thank you for helping us make LibreOffice even better for everyone!
This bug is also here: bug 122157
This bug seems to be 'non linux' (so only exists on windows and/or Apple)
Although some remarks here say that 'libreoffice-dbg' or 'libreoffice-gonme' needs to be installed on linux to get things working.
*** Bug 122157 has been marked as a duplicate of this bug. ***
This happens to me on linux, LO version 184.108.40.206.
I connect to a sftp share by connecting to the share on thunar (xfce). But clicking any odt files in the share does nothing (LO does not even open).
I commented out the 'X-GIO-NoFuse=true' line in my libreoffice-write.desktop file as per (and countless other sites):
and it throws a 'General input/output error while accessing' error dialog box when I try to open the same file (or any odt files).
Trying to open the file through command line, I get:
$ libreoffice --writer /run/user/1000/gvfs/sftp\:host\=website.com\,user\=user/home/user/Winter\ Parking.odt
javaldx: Could not find a Java Runtime Environment!
Warning: failed to read path from javaldx
Symptoms in comments #7 and #8 still apply to LibreOffice 220.127.116.11 on Windows, I am unable to use Remote Files Service to either open or save.
Ermh that should say "open or save via ssh", apols for the truncated update.
I have removed the "obsolete" tag from this bug accordingly.
(In reply to Nick Leverton from comment #17)
> Ermh that should say "open or save via ssh", apols for the truncated update.
> I have removed the "obsolete" tag from this bug accordingly.
The obsolete tag was added to the comment on purpose so the report would be easier to read. Nothing to do with any supposed obsoleteness of the report itself.
My apologies for misunderstanding. When I added the entry, BZ showed me the obsolete tag and said that it was an issue reported on an old version and to re-test on current LO. This I have done and can confirm that the bug is very much still present, I'm afraid.
If you feel this means it should still get the obsolete tag to help LO triage, then please go ahead and re-add it. I'm very grateful for all the work the team does so thankyou.
I can also confirm that the same symptoms, of inability to open a remote SSH service, are still present in LO 18.104.22.168 which I believe is the most current, installed from the official LibreOffice .debs and running on Linux (Debian Jessie x86_64).
When I try to edit the ssh service by doing:
- File->Open Remote File
- Clicking the dropdown 'Service' and choosing my already ssh created connection
- clicking the arrow next to to the right of 'Add Service' drop down and choosing 'Edit Service' while my ssh dropdown is selected.
- A pop up appears with a 'User' and 'Label' fields only. The label has my ssh service label and no username. Currently the OK button is greyed out (just like initial comment and comment 7 and 8.
- if I try to enter in a username, the OK button is still greyed out.
LO Version: 22.214.171.124 on Linux
This was reported for Windows; so it's a dupe of bug 98723. Similar problems with other systems (macOS, Linux without Gnome, etc) need own issues.
*** This bug has been marked as a duplicate of bug 98723 ***