Share Folder On Windows Network?

[TRS-80]

I thought about a Samba Shared folder, which seems to be quiet easy, but also seems to be buggy in Ubports, as well as in Android.

Samba is buggy in Linux because Microsoft are not actually interested in interoperability, in fact quite the contrary.  If all devices on your network are using Linux, you would be much better off with the native Linux equivalent which would be NFS.  You only need Samba if you have mixed devices on your network (i.e., one or more Windows boxen).

Syncthing, being written in Go, is cross platform.

I also thought about a Rasperri Pi with OpenMediaVault connected over SSH to a writing device, or running it on a virtual machine. The first seems to be easy. But who wants to carry around a Rasperri PI all the time with the PinePhone or another phone? Only a temporary solution, or as a backup device.

Yeah, seems cumbersome.  Where Single Board Computers (SBC, a more general and IMHO preferred term than RPi) really shine is in leaving them hooked to your network at home, and then using them for file sync (by any of the many ways being discussed in this thread).

SSH from Windows to Linux and vice versa seems to be a very professional solution, but I could not find out yet with what applications this is done the easiest way .

Yes SSH is very nice, for certain applications.  In Emacs I use dired and TRAMP (which work on top of ssh) which also works very nice for manipulating remote files.  But Emacs is a hairy beast, not recommended unless you are going to commit to getting over the learning curve which is pretty big.  So maybe I should not have menbtioned that.  I guess point being, all these tools have their place, depending on what you are trying to do.

Your requirements seem to be a moving target. Are you looking for something that works on a network, or can cope with offline edits to sync later? Text only, or arbitrary files? Or are you having new ideas sparked by the suggestions people are making?

I think this cuts to the root of the issue.  Almost like we are getting into XY problem.

So maybe we should start anew, by firstly defining exactly what your criteria/priorities are?  Then maybe we can suggest the most appropriate tool(s).

For general use I went with Nextcloud on a server at home, and wireguard to let me access it when I'm away from home. The client is available for most common platforms (linux, windows, mac, iOS, android), can be selective about what to sync on which devices, and warns about conflicting changes rather than blindly using the most recent.

Syncthing automatically finds the most recent file on any device and propagates that.  In the event of conflicts, those are synced also, and dated, so you can resolve them manually.  In practice, this happens seldom (unless you have some devices offline a lot, and edit those in parallel).

Of course you can select which devices to sync or not.  Even which folders, etc.

The reason I went with Syncthing over Nextcloud (which I also used to run) is that Nextcloud file sync is based on WebDAV, and therefore is syncing a whole entire file at a time.  Where Syncthing is chopping every file into chunkhs, hashing them, and doing incremental sync which is much more efficient.  Although if we are talking about small (or even medium to large) text files, it probably won't make a difference.

Also Syncthing is truly decentralized, clients will find each other (including navigating NAT) by way of community/project run relay servers.  Where Nextcloud is a classic server-client (hub and spoke) model.  You do not need to be running any server / SBC at home to use Syncthing (even though I do).

As wibbble mentioned, Wireguard can be a workaround for the NAT issue, as well as providing security.  I use Wireguard too, for that (and other things).

I also use git for other things in parallel (because git / version control have yet other use-cases; even for writers, which was in fact how I started out (not using it for code actually)).

But back to what wibble said above (let's define the actual use-case), before we go any further.