I was looking for a solution to the same problem and I think you can go a step further - use “fuse”, aslo known as sshfs.
It gives one advantage - I’m able to use remote files as if they really are on my own system. It doesn’t matter wIth moving of copying data, but in case case of playing a video, for example, fish still copies them to some temp folder on the local machine first and, depending on size, it might take several minutes before the video starts playing, even worse than Samba.
Shfs takes care of it beautifully. Check in Yast that it’s installed and enabled in Runlevels and then mount remote folders with simple
sshfs user@remoteIP: somelocal/mountpoint
It doesn’t matter if username is the same, btw, you can even use only “remoteIP”, without user@ in that case, as the system will assume that you are logging in with the same name as a user on the local machine.
I assume you’ve followed the exchanging public keys procedure to avoid the password prompt.
I’ve dug up this thread because on Suse 11.3 with KDE4 I can’t make this sshfs mounting script run from a link on a desktop. I’ve put it into .sh file, saved in my local /bin directory, added /bin to the $PATH variable and now, if I open the terminal and type “fuse.sh” I get connected in a few seconds, if I create a link to it on the desktop, however, nothing happens, the terminal window opens and stays blank, not even returns to prompt.
There was some change between KDE3 and KDE4 that apparently prevents sshfs from executing from a link. If it’s a test file with echo “hello world!” it works, if it has sshfs line it in it, it doesn’t.
I wonder why and if there’s a way to get it working again, as it still does on my older KDE3 notebook.