Bug 36827 - Can't save LibO file into SSHFS share
Summary: Can't save LibO file into SSHFS share
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: BASIC (show other bugs)
(earliest affected)
3.3.2 release
Hardware: All Linux (All)
: medium major
Assignee: Not Assigned
Depends on:
Blocks: Network
  Show dependency treegraph
Reported: 2011-05-04 02:32 UTC by ZMo
Modified: 2021-07-29 04:31 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:
Regression By:


Note You need to log in before you can comment on or make changes to this bug.
Description ZMo 2011-05-04 02:32:25 UTC
I get an "I/O error" trying to save any libreoffice file into a directory mounted via sshfs who only accept own definied "user:group" permissions.

Following the pid with strace i ve noticed libreoffice do a

chown("/home/zmo/.libreoffice/3/user/backup/prova_libreoffice0.ods", 847, 847) = 0

during the save procedure. As mentioned above, my directory does not permit to store "user:user" files.

How can i workaround that, and first of all, which is the main reason to call chown/chmod saving files?

Comment 1 Björn Michaelsen 2011-12-23 12:08:03 UTC Comment hidden (obsolete)
Comment 2 Florian Reisinger 2012-08-14 14:01:00 UTC Comment hidden (obsolete)
Comment 3 Florian Reisinger 2012-08-14 14:02:06 UTC Comment hidden (obsolete)
Comment 4 Florian Reisinger 2012-08-14 14:06:46 UTC Comment hidden (obsolete)
Comment 5 Florian Reisinger 2012-08-14 14:08:49 UTC Comment hidden (obsolete)
Comment 6 sasha.libreoffice 2012-09-04 08:46:45 UTC
not tested yet
Comment 7 sasha.libreoffice 2012-12-01 09:57:13 UTC
3.6.3 on RFR 17 64 bit works correctly
(installed package : yum install fuse-sshfs.x86_64)
meanwhile, closing as WFM

@ ZMo
If problem still exist, please, reopen this bug
Comment 8 Jacques Roux 2013-01-03 08:42:25 UTC
I confirm the bug which I reproduce with version (Build ID: 360m1 (Build:2))
I use Kubuntu 12.10 quantal.
I mounted manually a sshfs directory from a NAS (synology DS213, DSM 4.1). I can use all files in this mounted directory with dolphin, kate, and other applications (BTW identification done with RSA keys). I can open the same text document with Kate and LibreOffice. I can save it in Kate but NOT with LibreOffice. However, with LibreOffice I can save under another name or export as pdf. I guess that "overwriting" with the same name is for some reason not possible. I hope this help.
Comment 9 Michi 2014-05-02 11:19:27 UTC
I had the same bug on latest Ubuntu 14.04 LTS 64 Bit Intel. I am mounting a share over sshfs from my Synology Diskstation. Opening files, and saving under a new(!) filename worked out of the box. Saving to an existing (e.g. the original filename) led to the I/O error.

I fiddled around with the sshfs mount options, and in the end one of the workaround options ("truncate") did work for me, i.e. if I mount using:

  sshfs me@diskstation:/ diskstation -o workaround=truncate

does the trick.

Comment 10 Joel Madero 2014-11-04 03:27:00 UTC
Never confirmed by QA team - moving to UNCONFIRMED.
Comment 11 tommy27 2014-12-14 14:42:26 UTC
it was confirmed by other users though... so status NEW.
anyway has anybody the chance to retest with current LibO and give an update of the bug status?
Comment 12 Hans 2015-03-05 21:36:00 UTC
I can confirm this bug with LibreOffice 430m0(Build:2) on Ubuntu 14.04.2 64 bit.
Comment 13 Pascal Bodin 2015-08-15 14:55:58 UTC
I can confirm this bug with LibreOffice The workaround=truncate does the trick for me as well.

OS: Linux Mint 7.2 64 bit.
Comment 14 QA Administrators 2016-09-20 10:26:22 UTC Comment hidden (obsolete)
Comment 15 QA Administrators 2019-12-03 13:56:43 UTC Comment hidden (obsolete)
Comment 16 rupert.thurner 2020-05-09 20:10:49 UTC
there is chown in the source code, e.g.
Comment 17 Julien Nabet 2020-12-29 14:28:42 UTC
On pc Debian x86-64 with master sources updated today, I don't reproduce this.

I created a "pi" directory on Debian.
Then I used a raspberry pi 4b on which I enabled sshd
and typed:
sshfs pi@<raspberry ip4>: pi

Then, I could:
- create an odt file with just "test"
- save it
- close LO
- reopen the file
- modify it
- save it again

Also, I created a file from LO on Raspberry ("pi" user) then I could modify it from LO on Debian ("julien" user).

Did I miss something?
Could someone give a try with a recent LO version? 6.4.7 or brand new 7.0.4?
Comment 18 QA Administrators 2021-06-28 03:48:47 UTC Comment hidden (obsolete)
Comment 19 QA Administrators 2021-07-29 04:31:22 UTC
Dear ZMo,

Please read this message in its entirety before proceeding.

Your bug report is being closed as INSUFFICIENTDATA due to inactivity and
a lack of information which is needed in order to accurately
reproduce and confirm the problem. We encourage you to retest
your bug against the latest release. If the issue is still
present in the latest stable release, we need the following
information (please ignore any that you've already provided):

a) Provide details of your system including your operating
   system and the latest version of LibreOffice that you have
   confirmed the bug to be present

b) Provide easy to reproduce steps – the simpler the better

c) Provide any test case(s) which will help us confirm the problem

d) Provide screenshots of the problem if you think it might help

e) Read all comments and provide any requested information

Once all of this is done, please set the bug back to UNCONFIRMED
and we will attempt to reproduce the issue. Please do not:

a) respond via email 

b) update the version field in the bug or any of the other details
   on the top section of our bug tracker

Warm Regards,
QA Team