Bug 1054952

dtardon->sberg: One for you, I presume?

4.2.1.1 has the same problem.

The /usr/share/applications/libreoffice-*.desktop files all contain

  X-KDE-Protocols=file,http,smb,ftp,webdav

where the "smb" apparently cauess Dolphin to directly pass smb URLs to LibreOffice to open (instead of going via some /var/tmp filepath workarounds).

Internally, the Fedora LibreOffice builds use GIO to resolve smb URLs, and GIO in turn internally requires the gvfs-smb package to access smb URLs.  That package is apparently not installed by default in KDE spins.

Bob, I assume that "sudo yum install gvfs-smb" would make the problem go away for you?

The right fix would be to either remove "smb" from the /usr/share/applications/libreoffice-*.desktop files or to let the packages bringing along those files require gvfs-smb.  The latter is probably preferable, as it avoids Dolphin's /var/tmp filepath workaround and allows LibreOffice to access the smb files directly.  David, any opinion?

*** Bug 1135979 has been marked as a duplicate of this bug. ***

(so I took the "require gvfs-smb" route)

(see <https://bugs.freedesktop.org/show_bug.cgi?id=67527#c20> how to set up a local smb server for test purposes)

> Bob, I assume that "sudo yum install gvfs-smb" would make the problem go away for you?

Thanks for the help.  gvfs-smb did bring me closer, but I'm still not there.  Something else is still wrong.

Before installing gvfs-smb, the behavior of dolphin when attempting to open an .xls file on a remote share was for nothing to happen.  I might get a dancing wait-state icon for a few seconds, but nothing would ever happen in terms of opening a file.

After installing gvfs-smb, the behavior of dolphin did change.  Now when I click on a shared .XLS file I'm seeing a Libre-Office spash screen, and I see a status bar that begins to move across the pop-up window... but the process collapses when the status bar is half-way across and the file never gets opened.

FWIW, PDF files open just fine using Dolphin to browse the SMB share.  It's the LO types of files that aren't opening.


It's almost as if we've solved one necessary condition, but another one remains.  Installing gvfs-smb alone it's not sufficient to fix the problem.  It's as if something else needs to be loaded that isn't here.

recommendations?

(In reply to bob from comment #7)
> After installing gvfs-smb, the behavior of dolphin did change.  Now when I
> click on a shared .XLS file I'm seeing a Libre-Office spash screen, and I
> see a status bar that begins to move across the pop-up window... but the
> process collapses when the status bar is half-way across and the file never
> gets opened.

"a status bar that begins to move across the pop-up window": that pop-up window is the (green) LibreOffice splash screen, not a proper LibreOffice Calc window, right?

> recommendations?

If you could follow the instructions at <https://bugzilla.redhat.com/show_bug.cgi?id=1135979#c1>, that would hopefully give us a clue.

I just posted my attachment file to the closed bug by mistake. /*facepalm*/

on my system, it was not possible to invoke soffice directly via the command line, because the file's location was not in the system path.  i had to pass the full path on the command line to get strace to open the LO application:

/opt/libreoffice4.2/program/soffice

unfortunately, no log file was created, though I performed the procedure several times as a non-privileged user.  i'm thinking that this should not be done as root.

*** Bug 1135979 has been marked as a duplicate of this bug. ***

Created attachment 941017 [details]
screenshot of a password dialog for windows share

Dialog showing when I try to open a word document on a windows share. The "username" field is not writable.

Edit to comment #11: This is what happens after I installed the gvfs-smb package. Any other document, such as a PDF file, opens without that dialog.

(In reply to Peter Andreasen from comment #11)
> Dialog showing when I try to open a word document on a windows share. The
> "username" field is not writable.

But you can enter your password into the password field and the document then opens in LO, right?  (At least, that is what I reproduce with the local smb server setup from comment 6.)

The nuisance of having to re-enter the password would be due to the GNOME infrastructure internally used by LO to access the passed-in smb URL apparently not coordinating with the KDE infrastructure internally used by Dolphin to access the smb mount.

FWIW, here's another 2 cents worth:

I have been using LO on Fedora for a long time.  I reported the LO bug relating to failure to open files on a shared SMB partition for earlier Fedora versions, and that bug was rapidly fixed.  I'm not sure why the same problem is taking so long with F20 (this bug has been open since January and it's September now).  

FWIW, I haven't experienced the gnome infrastructure problem that was suggested in Comment 12 -- I've been using KDE exclusively on Fedora for many years, and I've NEVER had the problem of passwords not being passed properly in relation to opeining LO files on SMB shares.  In my experience LO and KDE never had a password passing problem -- that is to say, I never got hung up on loading files because of a password problem, where I was stuck because of a password prompt.  The files just either opened or they didn't, and a password prompt was never the problem.  I hope this helps.

libreoffice-4.2.6.3-7.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/libreoffice-4.2.6.3-7.fc20

libreoffice-4.3.2.2-3.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/libreoffice-4.3.2.2-3.fc21

Package libreoffice-4.2.6.3-7.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing libreoffice-4.2.6.3-7.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-11524/libreoffice-4.2.6.3-7.fc20
then log in and leave karma (feedback).

works for me.

libreoffice-4.2.6.3-7.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

libreoffice-4.3.2.2-3.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.

Updated to libreoffice 4.2.6.3-7 and gvfs-smb 1.18.3-3 today. Password dialog still pops up. If I enter a password, the file opens correctly.

(In reply to Stephan Bergmann from comment #13)
> (In reply to Peter Andreasen from comment #11)
> > Dialog showing when I try to open a word document on a windows share. The
> > "username" field is not writable.
> 
> But you can enter your password into the password field and the document
> then opens in LO, right?  (At least, that is what I reproduce with the local
> smb server setup from comment 6.)
> 
> The nuisance of having to re-enter the password would be due to the GNOME
> infrastructure internally used by LO to access the passed-in smb URL
> apparently not coordinating with the KDE infrastructure internally used by
> Dolphin to access the smb mount.

(In reply to Peter Andreasen from comment #21)
> Updated to libreoffice 4.2.6.3-7 and gvfs-smb 1.18.3-3 today. Password
> dialog still pops up. If I enter a password, the file opens correctly.

@Lukáš Tinkl, in case you know about a way to fix that?

Hmm no idea, the dialog doesn't look like something coming from KDE

(In reply to Lukáš Tinkl from comment #23)
> Hmm no idea, the dialog doesn't look like something coming from KDE

Sorry, my question was a bit terse.

What happens is that LO gets passed an smb URL from Dolphin, LO calls GIO's g_file_query_info on that URL, gets G_IO_ERROR_NOT_MOUNTED from GIO, calls GIO's g_file_mount_enclosing_volume, which calls back into LO's ooo_mount_operation_ask_password, which causes LO to display that dialog and pass the password back to GIO.

What would be necessary to make that additional password dialog go away is that the password/mount information available in Dolphin is available to GIO, either through some commonly used underlying infrastructure, or via some form of passing it through LO, in addition to the smb URL.  But this is extremely vague and I have no idea if anything like that would be possible.

This bug should not be closed.

I opened this bug.  As suggested, I've performed a de novo install, which resulted in an "official" installation, and an upgrade to latest version of LO in the repositories.  I can confirm that the problem with LO failing to open files on SMB shares has been fixed... sort of.

It seems that we've traded away one problem in order to gain another.

Now L-O is interposing an authentication layer that didn't exist before.  Specifically, when I browse an SMB share within Dolphin, and select an L-O file on the SMB share, LO does not directly open the file.  Instead, LO now opens a pop-up dialog box bearing the title bar "Authentication Required."  It fills-in my username, and requests a password.  A check-box is offered for "Remember password."

This authentication paradigm is a real problem.  There is no reason to require me to submit new authentication information.  My authentication information for accessing SMB shares is already being stored by KDE, and it appears that LO is failing to utilize this existing information.  From a user standpoint, the appearance of a new pop-up dialog that inappropriately requests re-authentication looks like the equivalent of a man-in-the-middle/keylogging attack that is being performed by LO.  This behavior is abnormal.  It represents a security problem that needs to be fixed.

When using Dolphin to browse SMB shares, no other software component requires me to deliver my username:password in order to open a file.  I have no problems playing multimedia that is stored on the SMB server; I have no problems opening PDF files that are stored on the SMB server.  But whenever I attempt to use an LO file, up pops this dialog which demands that I re-submit user credentials.  Unfortunately, I am not comfortable re-submitting this security information to an anonymous dialogt box, as I have absolutely no idea where this username:password information is being sent, or where it is being stored when the "Remember password" box is checked.

Is this something that can be addressed via this existing LO bug submission, or is it something that needs to be investigated separately as a Fedora security issue?

(In reply to bob from comment #25)
> Now L-O is interposing an authentication layer that didn't exist before. 
> Specifically, when I browse an SMB share within Dolphin, and select an L-O
> file on the SMB share, LO does not directly open the file.  Instead, LO now
> opens a pop-up dialog box bearing the title bar "Authentication Required." 
> It fills-in my username, and requests a password.  A check-box is offered
> for "Remember password."

See this issue's sub-thread consisting of comment 11, comment 12, comment 13, comment 21, comment 22, comment 23, comment 24.

Maybe it would be best to remove "smb" from upstream <http://cgit.freedesktop.org/libreoffice/core/commit/?id=673be8e76856c6bc39f448f3374db4ae84258952> "add X-KDE-Protocols" (discussed at <http://lists.freedesktop.org/archives/libreoffice/2014-September/063621.html> "X-KDE-Protocols=...,smb,...").  (And thus remove Fedora LO's dependency on gvfs-smb again, which would also get rid of issue 1147649.)

(In reply to bob from comment #0)
> This behavior began following the F20 upgrade.  On my F18 install LO would
> open the file, allow me to edit a local copy in /tmp, and when exiting the
> application, it would automatically upload the modified file back to the SMB
> share.  

Bob, did it fully automatically upload the file back, or did it present a dialog asking whether it shall upload back?

Stephan, I don't have the F18 setup any more, so I'll have to work from memory to answer your question.  

My recollection is that it never presented a dialog asking whether the upload to the originating share should occur.  But it's not fair to assume that in the absense of such a prompt, that the system would fully/automatically upload the file back.  There were a great many times that I lost data because the "fully automatic upload" silently failed with no error message, leaving the modified file in the local system's temp workspace where it was ultimately lost on power down.  Read on to find out why.

Back in the days of F18, office would download the shared file, edit it locally, and when saving/exiting, it would display a pop-up window to notify the user that the upload back to the original SMB share location was taking place.  when this happened, the upload to the originating share occured without user intervention.  It wasn't a transparent process, because the dialog appeared that allowed you to see what was happening, but when you saw that window you could at least assume that your data was saved.  Not seeing that window was a clue to an impending data loss problem.

Back in the days of F18, this automatic process worked fine as long as you were only editing one file.  If, on the other hand, you had several different office files opened from an SMB share, data loss could occur for all but the last file that was edited.

In F18 the upload-to-originating-share event seemed to be triggered by the close/exit of the LO application, rather than upon the closure of the file being edited.  If only the file being edited was closed, the latest revision of the file would remain on the user's temporary directory, and it wouldn't get uploaded back to the originating share until the upload was triggered by closing LO.

I'm not at all thrilled about going back to the F18 paradigm, unless steps are taken to ensure that the upload back to the originating share is triggered to occur upon closure of the file, and not upon closure of the office application.  If I had three office files open, and I saved and closed the first two and continued to work on a third, and then eventually closed the third file and exited the office application, only the last file that was in the process of being edited would be saved back to the originating share, and the other two would be left in the temporary workspace.  As you can imagine, files that get left in the temp workspace are subject to being lost.

That bug (I never reported it) resulted in the loss of a LOT of data.  I had to become very adept at saving files locally, and then manually moving them to the originating share.  If I had failed to manually perform a local save and an upload to the SMB server, I had to remember to search through the tmp folders for the file to recover them before the system got shut down.  If the system got shut down, the data became lost.

So the moral of the story for me is that the upload-to-SMB needs to be triggered by saving the file and not by exiting the application.

thanks for your time.

come to think of it, I did previously file a bug report relating to the failure to upload back to the originating shares.

(In reply to Stephan Bergmann from comment #26)
> Maybe it would be best to remove "smb" from upstream
> <http://cgit.freedesktop.org/libreoffice/core/commit/
> ?id=673be8e76856c6bc39f448f3374db4ae84258952> "add X-KDE-Protocols"
> (discussed at
> <http://lists.freedesktop.org/archives/libreoffice/2014-September/063621.
> html> "X-KDE-Protocols=...,smb,...").  (And thus remove Fedora LO's
> dependency on gvfs-smb again, which would also get rid of issue 1147649.)

Did just that now.  Consequently, Dolphin will pass /var/tmp filepath proxies for smb URLs to LO again, as in the past.  If there are any problems with that (like related to uploading modified documents back to the smb share), that would need to be addressed through the upstream feature request <https://bugs.freedesktop.org/show_bug.cgi?id=70712> "KDE: Support of 
opening and saving to a remote fs via KIO."  (Also see <http://lists.freedesktop.org/archives/libreoffice/2014-October/063904.html> "Re: X-KDE-Protocols=...,smb,...")

libreoffice-4.2.6.3-8.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/libreoffice-4.2.6.3-8.fc20

libreoffice-4.3.2.2-5.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/libreoffice-4.3.2.2-5.fc21

Package libreoffice-4.2.6.3-8.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing libreoffice-4.2.6.3-8.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-12477/libreoffice-4.2.6.3-8.fc20
then log in and leave karma (feedback).

libreoffice-4.3.2.2-5.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.

Any chance that us F20 users will see this pushed into the Stable repository instead of Testing?  It would be nice to have access to the fix without having to resort to porting stable-only systems to the testing branch.

Yes, when it fulfills the requirements:
https://fedoraproject.org/wiki/Updates_Policy#All_other_updates . There is _no_ chance to push "to Stable instead of Testing". The way is _always_ Testing -> Stable. Pushing updates directly to Stable is prohibited. Also, there is no "porting" involved in installing updates from testing. It is not a separate branch.

libreoffice-4.2.6.3-8.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.