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: 2020-12-29 14:28 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


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?