I use linux computers (variants of Ubuntu) connected to a Windows network.
The Linux OS accesses the Windows network through samba shares.
Opening files using the files explorer never works. LO seems to launch but then nothing happens. This happens when double-clicking the file or using an opened instance of LO and using the menu 'Open file'.
I have been having this problem for along time. There was a workaround which was going to the application launchers in /usr/share/applications and editing all the LibreOffice*.desktop files to comment the following line :
This was working fine, although it had to be done again regularly (the files being automatically changed during certain system updates, I guess).
That worked with Linux Mint 17.3
But I am now trying to make this work with Xubuntu 16.04 and it does not work.
Steps to Reproduce:
1. Connect a Linux OS to a samba share with any LO file on it.
2. Use the file explorer (Nemo, Thunar, ..) to navigate to the samba share OR launch LO and use the 'Open file' command and then navigate to the file.
3. Double-click the file to open it.
LO seems to launch but then nothing happens (probably crashing).
LO should launch and open the file.
User Profile Reset: No but I tried this with several use profiles.
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0
Not reproducible for me with LO 5.4.0 from Ubuntu PPA and Nautilus under Ubuntu 16.04 x86-64.
So I guess the problem is not on the LibreOffice side but on the Xubuntu / file explorer side or in your Samba configuration. If you can, you should try with a standard Ubuntu / Unity installation.
Best regards. JBF
I have tried the same operation with another computer with Xubuntu 16.04 and it also fails to open the file but I have this time an error message : "General I/O error during access to file <path to file on the samba share>".
What is pretty interesting is that I have only this error with LO files. Opening .pdf files is no problem. Opening / editing a .txt file with a standard text editor is also no problem. But opening the same .txt file with LO fails with the same error message as above.
So I tend to believe it is not a problem with Xubuntu's file explorer (Thunar).
Do you have libreoffice-gnome as in Bug 99667?
There was libreoffice-gtk and libreoffice-gtk2 installed but not libreoffice-gnome.
I installed it, rebooted. No change.
Ok. No, actually, there has been a change.
I can now open a simple text file on the samba share using LO, either directly (double-click in the file explorer) or using the 'Open file' menu of LO.
But opening a .odt file still fails when done directly with the file explorer, but not when done wit the 'Open file' menu in LO !
(In reply to Mamoth from comment #5)
> Ok. No, actually, there has been a change.
> I can now open a simple text file on the samba share using LO, either
> directly (double-click in the file explorer) or using the 'Open file' menu
> of LO.
> But opening a .odt file still fails when done directly with the file
> explorer, but not when done wit the 'Open file' menu in LO !
What do you with "But opening a .odt file still fails when done directly with the file explorer"? Right click on the file name in the file explorer and choose Open?
Best regards. JBF
I mean either double-clicking on the file or right-cliking and choosing 'Open with LO'. The same operations on the same file copied to the local hard disk work just fine.
Are you sure that MIME types are correct on the Samba share?
Best regards. JBF
Can MIME types be different on the samba share and on the hard disk ?
There is no doubt that it is LO that is started : firstly, as described previously , the problem happens also when right-clicking and choosing 'Open with LibreOffice' ; secondly, either when doing this or when double-cliking the file, there is the start-up screen of LO that shows up ( this one : https://www.howtogeek.com/wp-content/uploads/2017/01/00_lead_image_libreoffice-splash-screen.png ) but then nothing happens. When I control the task monitor to see if the process is stuck, there is no 'soffice.bin' process running.
In terms of symptoms, it is very similar to another bug with samba shares that required to comment/disable the line "X-GIO-NoFuse=true" in the /usr/share/applications/libreoffice*.desktop launcher files.
I'm having this problem. I cannot open LibO docs in LibO from a gvfs mount point to a samba share. I'm running:
LibO Version: 18.104.22.168
Build ID: 1:5.4.1-0ubuntu1
CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk3;
Locale: en-GB (en_GB.UTF-8); Calc: group
On Ubuntu Gnome 17.10
If I try to ope a file *either* from LibO > File > Open, *or* from double-clicking in a file-manager (either default Gnome [=Nautilus?], or PCManFM), I get:
General input/output error while accessing //run/user/1000/gvfs/smb-share:server=server.uk,share=path/to/file/my-file.odt.
I mount the remote share using Gigilo, and other apps (e.g. AbiWord) have no problem accessing files. As an aside, I used to be able to mount via /etc/fstab using these instructions:
and LibO could access files using that "mount point". Unfortunately, that "cifs.mount" approach is now failing for me for some unknown reason (the error message does not enlighten). I believe that's a red herring here, though, given the way that ALL other apps can use the gvfs mount point without any glitch.
I have applied the "workaround" of commenting out "X-GIO-NoFuse=true" from the *.desktop files, but without any effect:
I need this access regularly, it's most frustrating. (I am copying files from remote share to local disk, editing, copying back.) If there's any debugging I can help with, please instruct: I'm "just a user"....
Libreoffice opens the file with O_RDWR. Gvfs mounts only support opening files with O_TRUNC or O_APPEND. But not O_RDWR by itself.
The way I've been getting around it is by using "nautilus --no-desktop" and opening it from there. nautilus will send the gvfs url to libreoffice (ie. smb://...) . pcmanfm will send the /run/user/... path to libreoffice which doesn't work.
Based on H. C.'s comment I think this is the same issue as bug 59424.
If you disagree, feel free to reopen the ticket.
*** This bug has been marked as a duplicate of bug 59424 ***