I have written a script to help me mount Windows shares with GVfs, it's here: https://github.com/rdiez/Tools/blob/master/MountWindowsShares/mount-windows-shares-gvfs.sh The script is just a fancy wrapper that runs gvfs-mount and creates symbolic links to all the mount points. Without the symlinks, finding the mountpoints is awkward (for me). I am using Ubuntu 16.04. I have installed Launchpad's "official" PPA to get LibreOffice 5.3. If I open a Writer document through a symbolic link like this: /home/rdiez/WindowsShares/WindowsPcRdiez/Temp/MyDoc.doc I then get this error: General input/output error while accessing /home/rdiez/WindowsShares/WindowsPcRdiez/Temp/MyDoc.doc However, if I open the same file directly through the GVfs mountpoint (without using the symlink): /run/user/1000/gvfs/smb-share:domain=MY-WINDOWS-PC,server=my-windows-pc,share=rdiez,user=MYUSER/Temp/MyDoc.doc Then it opens fine. Other programs like Emacs can open the document file over the symlink without problems. 1) The first issue is probably in Writer. It should report where the error is coming from, and some sort of specific error message or error code, instead of a generic error. I mean that Writer is probably discarding error information along the way. That makes it difficult to troubleshoot problems. This is not the first time I see LibreOffice not reporting error causes accurately. This looks like a general design or structural shortcoming in LibreOffice. 2) The underlying error is likely in some GVfs library, but it is difficult to report or to argue with the GNOME developers without an real scenario where an application hits the problem. That is the main reason why I am creating this bug. I hope that you could tell me (or even better, the GNOME developers) where exactly this error is coming from, and what error code is being returned (that Writer does not display to the user). Many thanks in advance, rdiez
Would it be possible you attach a backtrace? (see https://wiki.documentfoundation.org/QA/BugReport/Debug_Information#GNU.2FLinux:_How_to_get_a_backtrace) You may find recent LO version, with also debug symbols, here: http://dev-builds.libreoffice.org/daily/
I am sorry, but I do not have the time to provide a backtrace. It would be hard anyway, because it is not a crash. I have more information on this: 1) I am using Ubuntu 16.04.2 LTS, which has a different kernel version as the plain 16.04 version. 2) This kind of bug is apparently already known: https://bugs.launchpad.net/ubuntu/xenial/+source/gvfs/+bug/1598183 Regards, rdiez
(In reply to R. Diez from comment #2) > I am sorry, but I do not have the time to provide a backtrace. It would be > hard anyway, because it is not a crash. > ... Oups, you're right of course, let's remove "wantbacktrace"
It seems fixed on Ubuntu 16.10 but find nothing about 16.04. See https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/1638245 (you can start reading from comment 10)
In that bug report, which seems to be a different issue, they say that they fixed it in "xenial" too, which is Ubuntu 16.04. But I keep my systems up to date, and the problem I reported in this bug is still there.
I have the same problem on 6.0.1.1 (debs from libreoffice.org) under Ubuntu 17.10. It's not because the symlinks, because it doesn't work if I access directly to /run/user/.... either. I cannot open or save a document. Nautilus is able to operate normally (create, modify, delete), so it's not a permission issue.
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. See... https://bugzilla.gnome.org/show_bug.cgi?id=748106 https://bugzilla.gnome.org/show_bug.cgi?id=777152 You will get an "operating not permitted" error which shows up in libreoffice as "general input/output error". Some file managers default to opening gvfs files from /run/user/... because most older or simple programs don't support opening files with gvfs URLs, they only support normal file names. Backtrace just dropped me off to an empty gdb shell. But I found this out by using --strace.
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 ***