[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

[valtam]

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

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

I had three reasons to post it:

1. to check whether others also experience this scenario/bug
   
2. to warn others of the possibility of data loss when mounting a remote folder via Thunar
   
3. 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

[valtam]

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

[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   

[valtam]

LibreOffice may require the: libreoffice-gnome package

[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 

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

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]

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