Ok, thanks for the additional info.

FWIW what you describe (when you say PCManFM-Qt connecting via SSH) sounds like either SSHFS or SFTP - both of which should support creation of symlinks. Although the issue you might have (which it sounds you are) is that it may create absolute links (rather than relative ones). Relative links should work fine, but obviously absolute links won't unless you mount the paths in the same place locally as they are on the remote server. So perhaps that's worth a try? E.g. assuming default storage location (on your Fileserver) of /srv/storage, mount it to /srv/storage on your local machine.

FWIW, I just tested browsing to my local fileserver via SFTP in Nautilus (as root). Then I used the UI to create a symlink and it "just works" for me?! It did create an absolute symlink (and it has the dumb name of "Link to "), but it works.

Apologies on my incorrect assumption about Samba/CIFS/SMB, I was working on a combo of the error you reported (non native filesystem), and an assumption that PCManFM-Qt was very similar to Nautilus (default file manager in Gnome). Although I must say I'm surprised that PCManFM-Qt doesn't support it OOTB?!

Access via WebDAV should "just work" too (it's been a while since I last tested it, but last time I did it "just worked" - at least using Nautilus). IIRC in Nautilus you need to specify "davs://" for the path. Regardless though, you're still likely to have issues with absolute paths.

Re Webmin, I just tested creation of a symlink in Webmin and it definitely created a symlink. Although I admit that the work flow is a bit clunky (select file/folder, select "create symbolic link" from the edit menu, select the new symlink and "cut" it, browse to where you want the symlink and "paste"). I looked for the "New > Create symlink" that you mentioned and I don't seem to have that?! Perhaps we're using different versions of Webmin? FWIW I tested creating symlinks to both files and folders and it worked. I.e. I created a symlink to /etc/apt/preferences (file) and /etc/apt/sources.list.d (folder) and here's what it now looks like:

root@tester ~# ls -la /etc/apt/
total 32
drwxr-xr-x  7 root root 4096 Feb 28 00:00 .
drwxr-xr-x 92 root root 4096 Feb 24 20:25 ..
drwxr-xr-x  2 root root 4096 Feb 23 19:11 apt.conf.d
drwxr-xr-x  2 root root 4096 Jun 10  2021 auth.conf.d
-rw-r--r--  1 root root   58 Feb 23 19:06 preferences
lrwxrwxrwx  1 root root   21 Feb 27 23:59 preferences--symlink -> /etc/apt//preferences
drwxr-xr-x  2 root root 4096 Feb 23 19:11 preferences.d
drwxr-xr-x  2 root root 4096 Feb 23 19:06 sources.list.d
lrwxrwxrwx  1 root root   24 Feb 28 00:00 sources.list.d--symlink -> /etc/apt//sources.list.d
drwxr-xr-x  2 root root 4096 Apr  1  2022 trusted.gpg.d

It does give them silly names (appends '--symlink') and it does appear to be a little buggy (note the extra slash in the path - although that shouldn't matter as Linux interprets double slash the same as single one). But otherwise my experience seems quite different to yours. I note that I'm testing a VM, so perhaps the behavior is a little different in a LXC container for some reason? I do have a local fileserver container myself, but it's not publicly available and I haven't maintained it very well (it's really out of date) so it's not a good test candidate. Also, it's set up a little different to default as all my media are stored on a separate physical hard drive which I have mounted from the host into the container.

However, it creates a hard link. The link created is appended with "_symlink" but is the same size of the original directory. When I go back and create a file within the original directory, the "_symlink" directory created via Wedmin File Manager does not ls the newly created file - proving it is a hard link / copy.

On Linux, only files can have hardlinks - so the link you created to a directory definitely is a symlink. FWIW, that's because files are actually stored on disk as inodes - then the inodes are linked to the filename. A hardlink is just a new filename, linked to the same underlaying inode. That's why hardlinks can't span separate volumes. On Linux directories don't exist in the same way that files do (they are purely an abstraction) so hardlinking can't work.

Regardless, that still doesn't explain your behavior - nor why it differs from mine.

Re your SSHFS attempt, as I think I noted above, it should work if you mount the remote to the same place on your client as it is on the server. I.e. instead of mounting it to /mnt, mount remote:/srv to (local) /srv. If you already have files in /srv on your local system, then create the 'storage' subfolder and mount remote:/srv/storage to (local) /srv/storage (and so on).

So to summarize, I still don't think that we've got there. But hopefully that's a little more info to aid further testing and searching.

Also apologies that I never actually answered your original question! To circle back to that, another option (if you want to use a GUI) would be to install a desktop on your server. I generally recommend against that purely because I love the CLI and it seems incredibly wasteful of resources to be running a desktop on a server - but beyond that, there isn't really reason why you couldn't install a desktop if you wanted. Under the hood, TurnKey is Debian.

Finally, I'm not 100% sure how active the PCManFM-Qt community is, but perhaps it's worth asking them for input on suggested workflows/config/customisation to achieve your ends? As I note above, TurnKey is (mildly customised) Debian under the hood and Gnome seems to have the required functionality. So my guess is that even if it doesn't work out of the box, that it would be possible to configure it to work the way you want.