Data loss when using Thunar and SFTP connection

[LL-user]

Hi TC, hope you enjoyed your coffee

Thanks again for sharing your knowledge!

A bit more input from my end/ about testing sftp connection from LL3.0 (client) to LL2.8 (server)

• As mentioned before I'm not talking about root permissioned files! The files are owned by a user with UID=1000, GID=1000 (basically the first user after install) and are remotely accessed by a user with UID=1000, GID=1000.
  
• I only get prompted for authentication when I establish the fstp connection via the file manager - as it always has been.
  
• The text files I actually never tried to open with LibreOffice - I keep things simple Opening plain text files with LibreOffice also fails, as with the other (LO) files. When I try opening the remote file via the command line I'm getting a pop-up window with the error message: "General input/output error while accessing <path/to/file>"
  
• As mentioned before, opening remote txt files via Leafpad is possible without error, it even saves changes without error - BUT with the result of wiping its content. Interestingly, using gedit as a text editor does not show this data loss!
  

So for now,

• using a different text editor for txt files is a nice workaround.
  
• LO files can't be opened.
  
• other files (picture, videos, etc.) open up without problem
  

Thanks for taking the time, TC!

[trinidad]

1) Are you using the scp commands from the terminal to open files or cp commands?

2) Are you using a relative or absolute naming convention for pathnames?

3) Have you tried the blowfish cipher instead?

Take a look at this link: http://www.computerhope.com/unix/scp.htm

TC 

[LL-user]

Hi TC,

No, I connect from client to server via Thunar and sftp, something like this:

Code:

sftp://[email protected]/home/linuxlite

[trinidad]

Hmmm? Scratching my head myself. Public IP convention. AES, matched users,  should work fine. I don't have any 2.8 around here anymore so I can't enable your set up exactly. Plus my Linux to Linux ssh connections are always interface bound ad hoc, or interface bound wired, and almost always to a Debian server. I know open ssh server is not code expressed exactly the same as far as root login between trusty and xenial, and RHEL and Debian, but you're not getting a no route to host error, and using a public IP convention with matching user names, so I'm guessing we've narrowed it down to a difference between older Mint and newer Ubuntu somewhere, i/e trusty leafpad, and xenial ssh, or an XFCE modification difference between 2.8 and 3.0 which will not let the kernels interface at some levels of function while default Debian gnome gedit seems to work fine. The other issue is I rarely use leafpad myself, either nano, redit, gedit, or kate, and sometimes when applicable Libreoffice. By the way there are some basic code options in Libreoffice, >LO greeting page >tools>Libreoffice drop down menu>Basic IDE Options. In Solydx I had to write fire wall rules to connect ssh but yours is already working so that's not it either, or you might have to enable x forwarding on the server side, and add (-x) to a long ssh URI address to /LO application/ then file, for Libreoffice to work seamlessly, and probably a vnc viewer on the client side to produce its remote desktop. Again I mostly use RDP and Samba protocols at the same time, so I have not experienced your particular situation. 

Out of ideas for now. Still thinking though. Ease of networking is a very important feature for any OS, and a source of constant tinkering and mistakes for many users of all experience levels. I'm always looking for the best, simplest, and safest solutions. Good Luck.

TC   

[LL-user]

Hey TC,

Thanks again for all you input. Yep, it's mind-boggling - and unfortunately not only an inconvenience but also a risk for data loss.
I don't expect X-forwarding to be an issue as the local program is used to open the remote file. But who knows

I will keep it at that for now, will run the odd tests at times when I have another system running or after a few rounds of updates.

Thanks again!