Trying my luck

[Qubes]

I am just trying my luck here with an issue that i have been unable to
resolve on my Qubes system for a long time now. I have been looking into
this problem quite a bit but i cannot seem to find a solution anywhere.
Perhaps someone on this list has experienced the same and has found a
solution.

When i open a text file that is located on a network share with gedit,
gedit is unable to save the file. When I click the save button, or `Ctrl
+ s`, i can see gedit creates a temporary file named
".goutputstream-AO9U51" on the network share and in gedit i get a
message "Could not create a backup file while saving
"/home/user/data/test/file-name.txt"". If i launch gedit from cli i see
a message on cli when saving the file "Hit unhandled case 27 (Error
renaming temporary file: Resource temporarily unavailable) in parse_error."

I definitely have permissions on the network share as i can copy files
to it, delete, create directories, etc. I can also open a LibreOffice
document and save it. The problem appears to be specific to gedit. Also,
it happens with both a Fedora and Debian based VM.

[Qubes]

In addition that i forgot to mention is, i can open edit and save the
same txt files with vi and it works.

[Qubes]

I have read reports [1][2][3][4][6] dating as far back as 12 years with
the sshfs protocol (an abandoned project) being implicated as well.

On issue 438 [3] that was reported on Gitlab it is reported that "As far
as I can tell, the problem is in the way glib saves a file by writing to
a temporary file and renaming to the final name." and "I'll take a more
serious look later but I'd start with gio/glocalfileoutputstream.c and
particularly the function _g_local_file_output_stream_really_close which
contains the error string "Error renaming temporary file".".

A duplicate issue 565 [5] to issue 438 [3] was opened and there a patch
is provided that is said to fix this issue although i have not tried it
because i don't know how to.

**Question:** Would anybody perhaps know how and where to do the patch,
attached for reference, on Fedora/Debian. As far as I can tell the patch
needs to be done on the client since the problem originates from the client.

[1]:
https://askubuntu.com/questions/13843/gedit-sshfs-wont-save-vi-saves-fine
[2]:
https://unix.stackexchange.com/questions/52951/gedit-wont-save-a-file-on-a-virtualbox-share-text-file-busy
[3]: https://gitlab.gnome.org/GNOME/glib/-/issues/438
[4]: https://github.com/rclone/rclone/issues/2130
[5]: https://gitlab.gnome.org/GNOME/glib/-/issues/565
[6]:
https://illumos.topicbox.com/groups/omnios-discuss/Tc4c6b72d6386f9fb/resource-temporarily-unavailable-when-saving-to-cifs-share-on-r151038

[Ulrich Windl (Google)]

Just wondering: Is the remote end Windows, and could some virus scanner block the rename request? You know Windows has kind of strange locking rules.

[Qubes]

> Ulrich Windl (Google) wrote:
> Just wondering: Is the remote end Windows, and could some virus scanner block the rename request? You know Windows has kind of strange locking rules.
>

No the SMB server is running on OmniOS which is Illumos kernel.