[ SOLVED ] Data loss when using Thunar and SFTP connection

[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!

[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]

Hi TC,

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

Code: [Select]

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


[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, 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]

LL, some thoughts over coffee.

1) Libreoffice uses rcp for sftp unless you choose otherwise, i/e by trying to open a server root permissioned text file with Libreoffice. If you are not prompted for authentication when you try, scp is not working. Are you prompted when you try?

2) OR, does the server prompt the client for authentication when the client attempts to access root files? That would be scp.

3) If you are not prompted you are using rcp which I don't think will allow you in these new "norootlogin" and long host naming days to edit root server files with a client even if your client and server root user and passwords are the same. Under rcp you can only copy the file from the server into the client, and rename it to edit it, and copy it back as a new file, going through the whole renaming convention on the server with the client logged off to save your new file back to its original name on the server.

4) It is also possible that the client and the server are mismatched, one scp, one rcp. 3.0 client and 2.8 server i/e. this is not a bug per se, just new and old ways in the kernels of doing things clashing. I'm not sure, but I believe 2.8 pre-dates the system wide "norootlogin" Debian policy and may not automatically default to scp when necessary.

5) I still have yet to get the Ubuntu build of x11vnc to work properly as an LL v-server, so I could just be wrong here. The Debian build works perfectly for me in Debian. Good Luck.

TC

 

[LL-user]

Hi TC,

Thanks for taking the time and your input.

No root permission involved Here a few more details:

• On both boxes I use a user with identical UID/GID.
• The files are owned by this user.
• Identical results with both file managers, Thunar and PCManFM
• Both boxes run on 64-bit systems

Results:

sftp connection from LL3.0 (client) to LL2.8 (server) via file manger

• Text files: Saving is NOT a problem per se, therefore I'm pretty sure it's not a permission problem. HOWEVER the text file content gets wiped out! Without any warning or error message.
• LibreOffice files are not opening at all
• Haven't tried other files yet.

sftp connection from LL2.8 (client) to LL3.0 (server) via file manger

• All files on server can remotely be opened, edited and saved.

sftp connection from LL2.8 (client) to LL2.8 (server) via file manger

• All files on server can remotely be opened, edited and saved.

A wild guess
Could it have to do with the libssh2-1 library installed on both systems?
LL2.8: Version: 1.4.3-2
LL3.0: Version: 1.5.0-2
Description: SSH2 client-side library
 libssh2 is a client-side C library implementing the SSH2 protocol. It supports regular terminal, SCP and
 SFTP sessions; port forwarding; password, key-based and keyboard-interactive authentication.

An initial search on the net didn't return any useful hints.

[trinidad]

Hello again LL,

The more I read through this, the more I am wondering what kind of text files you are working with. If it's a system file of any kind from the server, and the two systems have the same naming convention, (which they do in this case) you wouldn't be able to save changes on the client side if a file of that name already exists in that (client) system with the same name. To save changes on the client side you would in such cases have to rename the file first. I don't think SFTP would allow you to resolve root permissions in such cases without renaming or overwriting or working in a vbox or an fcage no matter how you configured it, even if root and password are the same on both systems. Just a thought.     

TC

[LL-user]

Thanks Trinidad for your constructive input! Highly appreciated

I will need to look into your suggestions further when I have more time.

Something must have been changed under the hood, because it was working flawlessly and without any additional configuration/ installation beforehand, i.e. between two LL 2.x systems.

That LibreOffice files are not opening is minor considering the issue that the content of txt files gets wiped out!
I do appreciate that Jerry has his way of doing things -  we all do. The fact that his workflow is avoiding this critical bug doesn't mean it does not exist

Meanwhile I have done some testing with sshfs. Mounting a remote folder via sshfs enabled me to open and edit remote txt and LibreOffice files from within Thunar. However, Thunar is not able to follow symbolic links in sshfs mounted remote locations.

Thanks again

XFCE uses "exo mount" but libreoffice uses "gnome mount" for GVFS URI resolutions. I'm not sure but you may have to allow gnome services enabled in the startup menu of both boxes for libreoffice to share, and thunar may need fuse to work with libreoffice. Your text file issue sounds like a praxis issue. You have to copy and save the file you wish to edit, to the machine you are working on, and then edit that saved copy. SFTP is something you can configure to meet your specific needs, including direct system editing, but you will need gnome keyring. I have yet to try libreoffice GVFS with LL, but I use it occasionally from Debian 8.5 to Kubuntu, and windows 10 on ad hoc net at the office, so I know it works. Bugs concerning it are all old. I'll try it next week from my laptop at the office. Long holiday weekend ahead for me.

Trinidad   

[Jerry]

LibreOffice may require the: libreoffice-gnome package

[trinidad]

XFCE uses "exo mount" but libreoffice uses "gnome mount" for GVFS URI resolutions. I'm not sure but you may have to allow gnome services enabled in the startup menu of both boxes for libreoffice to share, and thunar may need fuse to work with libreoffice. Your text file issue sounds like a praxis issue. You have to copy and save the file you wish to edit, to the machine you are working on, and then edit that saved copy. SFTP is something you can configure to meet your specific needs, including direct system editing, but you will need gnome keyring. I have yet to try libreoffice GVFS with LL, but I use it occasionally from Debian 8.5 to Kubuntu, and windows 10 on ad hoc net at the office, so I know it works. Bugs concerning it are all old. I'll try it next week from my laptop at the office. Long holiday weekend ahead for me.

Trinidad   

[Jerry]

I don't view it as a workaround, it's just the way I would prefer to work, so I guess it's more a personal perspective. I did offer a solution, but it's not the one you're looking for. Will be interesting to view other solutions

[LL-user]

Hi Jerry,

Hmmm.... thanks for your reply.

Of course I'll need to and will do these three steps to avoid data loss. But am sure you will agree that

• this is only a workaround for a bug somewhere - not saying it's in LL, most likely it's not.
• it would be preferable to do one step instead of three every time I edit a file on the server.
• the fact that user data loss can happen without warning makes this quite a critical bug.

I had three reasons to post it:

• to check whether others also experience this scenario/bug
• to warn others of the possibility of data loss when mounting a remote folder via Thunar
• to check with you whether it's a LL issue or an underlying issue (like XFCE, Thunar, etc.)

The three steps workaround I came up with myself

[Jerry]

If you can copy files already between server/client, why not copy file to server, work on it, then copy it back to client?

[LL-user]

Hi,

With two LL 2.8 64-bit systems I had no problem to connect from one system to the other via a sftp connection in Thunar and open/edit remote files.

Current situation:
server: LL 2.8 64-bit
client:  LL 3.0 64-bit

Sftp connection establishes successfully. Copy/move operations between server and client work without problems (drag & drop between two Thunar windows on client side).

However:

1. txt files: If I open a remote txt file, I can successfully edit that file and also save it without any error message/ warning. HOWEVER the file content is gone! File size is 0.

2. Libre Office files: Remote Libre Office files just won't open, neither by double click, right click and "Open with", nor from within Libre Office.

Any advice would be appreciated