Cannot save the document on the remote filesystem

[FoxWise]

Hi all,

I have a remote filesystem mounted on the local PC via sshfs.

Locally I have set up my custom template and created a new impress presentation and saved it in the file, e.g. as test_presentation.odp. Then I have moved the presentation file to the other folder, which is mounted with sshfs. When I opened the presentation again no matter what I change I can’t save it again. It always returns an error. (see screenshot)

Also, creating and saving new presentation from the template imidiately on the remote gives the same error.

I thought all template settings are saved in the single presentation file, so I am a bit surpised that when I copy the file, I still can’t save it after the editing…

Could anyone have an idea how to fix this?

Saving/editing presentations on the remote filesystem works fine with old files, without custom template. That is why I usually just copy the old files and edit them to create “new” presentation, but it would be nice to actually use a new template I have created.

Let me know if you need any other information I can provide…

Local System: Ubuntu 20.04
Remote System: Centos 7
LibreOffice:

[FoxWise]

Reloading the local PC solved the issue.

I guess the problem is somehow in the access rights (which are updated after the reload/remount) which were restricting the save, but not restricting copying and folder access, which I find weird…

[FoxWise]

Or I thought so… The error seems to re-appear if the computer goes into the hybernation mode at some point (thats just my assumption right now) after few hours… It just stopped allowing me to save it anymore at some point during the editing and I lost few hours of work, because I didn’t save it and didn’t notice it. It seems autosaving didn’t work out either, although it is turned on, as I am back to basically blank template…

I would very appreciate if experts could tell me the potential reasons for the “General input/output” error, as I don’t find it very descriptive…

I am sorry if I sound frustrated, but it just kills so much motivation to do a well polished presentation with a well defined style/templated…

[webmink]

Sounds like an authentication timeout by the host - perhaps you could explore the settings on the target filesystem? I routinely load and save from a remote filesystem mounted on Debian (but using SMB rather than sshfs) and rarely find it disconnects like this (but it does sometimes.

[FoxWise]

Indeed,
But usually when I have experienced the timeout in the past, I got all the folders/files locked and I couldn’t access ANY file, not open/write/copy. While now “timeouts” affect only libreoffice save function (as I still can open remote files) and everything else seems to continue to work fine… And these new “timeouts” happen way more frequent…
So I am curious, does libreoffice require different authentication to open a file in a proper editing mode and to save the file while being in this editing mode?..

[webmink]

Sorry, I can’t help much further on the Libre office side - I suspect the issue is elsewhere though. I’d be checking group and individual permissions, server settings, client settings and experimenting with variations. Apologies for not having an answer!

[FoxWise]

Is it possible somehow for me to run libreoffice in “debug” mode, so I can extract the specific reason for the error (which exactly permissions are missing from which side, etc…)? Or maybe even get the backtrace?

Because this is the office computer and playing with permissions is not an option as I don’t have admin rights. As well as showing the error to local admins might not get a response, as all the other filesystem remains functioning

[webmink]

I’ve been experimenting with my system (attached to an SMB NAS so not the same as you, sorry) and get a behaviour like yours when the user authentication (with write access) times out but the group authentication still allows read access. Is it possible you have two authentications in play, maybe one via a key and another via login?

[FoxWise]

I have contacted my local admins, who are responsible for the file system.
They have confirmed that this is a known bug connected to our filesystem.
They didn’t specify direct reasons for the bug, but it seems it is indeed not the libreoffice fault.

Thanks a lot for your investigation and the effort going through the potential issues!

cheers