Unable to open user directory over ssh provider

[darrott]

Hi sorry to bother you! You are doing an amazing job with this plugin and I hope to help you in some way.

I was trying the 1.1 version since I wanted to use it with a file browser, but I have the same error with the master branch.

Since I cannot do Nmlogs, I paste down there the error I get on Nvim:

E5108: Error executing lua [string ":lua"]:1: attempt to call field 'dump_info' (a nil value)
stack traceback:
[string ":lua"]:1: in main chunk

OS: MacOS
Nvim version 0.8.1
Plugin Manager: Packer (wbthomason/packer.nvim)

All of this because I was trying Neotree and Netman combo, but without logs I can't give you more data about the "error" I get with it. It is not much an error, the problem is that the server I am connecting to is a shared server for php websites, and it has small rights for users. Neotree starts ssh connection in the root of the server but I can't "see" what is inside of home directory, so I cannot go down in the working tree.

Thanks in advance and sorry if I missed something while trying to do some logging!

[miversen33]

No problem! Nmlogs is currently severely broken (it's on my list of things to get patched before I merge 1.1 into main :( )

You can find your log file in $USER/.local/nvim/netman/logs.txt (most likely).

You can also print the logs location via

:lua print(require('netman.tools.utils').data_dir

I apologize about the quick log access being broken :/

[miversen33]

To the actual issue, I would recommend updating it log level to 0. To do that, put vim.g.netman_log_level=0 somewhere in your neovim configuration. Then recreate your issue and the logs should have both all commands ran when you did that, AND the output of the commands. It'll make it nice and easy to see what's going on. It's very likely a permission issue, I've been battling them while trying to fix an async issue. But if you can isolate what the issue is, I will throw it on the 1.1 pile!

[miversen33]

Sorry for the comment chain, rereading your issue, I know exactly what you're running into, it's been an issue in my head for a bit and I haven't known the next way to address it.

So because you don't have permission to see the contents of the home directory, you can't see your own user directory, which means netman (via neotree) is useless. I've been toying with instead having netman open the entire root tree (as it does) and then open the subdirs to your user directory immediately on accessing an SSH server, to help with this. How does that sound? Do you have any other suggestions for how you'd like to see that work?

[darrott]

Thank you so much for your attention! I tried the :lua print you wrote and yeah, it says the path but inside the last folder there is no log file (maybe is right since "no error" was printed, not counting the Nmlogs I mean).

About suggestions, I don't know if there are some kind of limitations with it but would be nice (always if possible) to declare somewhere the starting directory on connection. I know this is not possible to do with the openssh config file, but with netrw (which I don't like so much) I saw that declaring on the connection script the directory to open I bypassed this problem.

Your solution seems more friendly and less painful and will do perfectly imho. My experience is: scp:// works fine declaring the hostname and nothing more, with sshfs I had to declare after the hostname the user directory path, in my case /home/customer. Probably talking about this stuff you are more prepared than me for sure, I just hope to not create confusion and to bring something useful!

[miversen33]

So scp actually interprets scp:// as your user directory (ironically, so does sshfs but only if you open sshfs in shell mode).

I am planning on allowing netman configurations for providers, meaning in the future a user will be able to specify things to the provider (potentially including the directory to open on connection??). I am fleshing this behavior out a bit for the neotree extension but don't expect that to make it into 1.1 unfortunately.

I should probably get around to fixing Nmlogs sooner rather than later though. When I get home, I'll properly tag this and move it to the highest priority thing to do.

In the mean time, it's probably worth figuring out why you don't see your logs. Feel free to add my discord: #131 and we can (later) see if we can figure that out. The logs do exist somewhere, but if they aren't where I expect them to be, them something is wrong :/

[miversen33]

@darrott I have created a new issue (#112 ) specifically for the :Nmlogs failure bit. This issue will be treated as the underlying ssh failure issue you mentioned. I will work with you over discord to see if we can get your logs working, though I suspect that I know what is going on here (as mentioned previously)

[miversen33]

So my current thought process on addressing this is as follows. Once the ssh provider has established a connection, it should figure out the user's home directory (probably store it as a variable within the provider). The neotree provider should ask the API for some sort of "home" directory for the host (or even better, have the host query return the home directory if it has it), and then it should open and highlight down to that directory.

I don't quite have this fleshed out yet, but it "should" work. There will likely need to be some guard rails around permission errors and retries to handle weirdness, but this theory should work. It will need to wait until find (#95 ) is complete, as find in the neotree provider is also adding some tree walking ability that will be critical for this functionality to work.

[miversen33]

A couple issues that need to be worked out here.

The way I am envisioning this work is that the providers ui.get_host_details function can return an additional value called ENTRYPOINT. This entrypoint will be an array of URIs (similar to how find returns its ABSOLUTE_PATH now).

The UI then iterates over each URI, and "navigates" to each one, executing a read on each node in the path (if it hasn't already been read).

The biggest hurdle in this logic is how to deal with the fact that any part of that path may toss a permission denied (or some variant) error while executing these reads. Right now, we specifically check for this error and toss back a failure on read. So the question is, how do we deal with this in a situation where the provider tells us to read a directory that it then tells us it can't read?

Current options in my head are

• Warn on permission denied (maybe even include an errors attribute in the return value) and still pass back whatever could be read on read
  This has the benefit of allowing us to move forward as permission denied is reduced in severity and no longer considered a "critical" error. The downside is, it is usually a critical error. If a user attempts to open a directory they shouldn't have access to (such as root), this error is how we can inform them that they cannot access it (albeit, right now that feature is missing in Netman anyway).

• Accept that in the instance of processing the ENTRYPOINT, we may get permission denied errors and assume the provider knows what its doing (so ignoring the error, create the node anyway, and continue processing the ENTRYPOINT items)
  This has the benefit of migrating the ignore logic into one place (so as to avoid having the provider "make decisions" on if it really should throw a permission denied or not), though it does pose a problem of how we plan on moving forward here, if we literally can't read the directory in question.

• Just don't do this
  By far the easiest answer, simply not implementing this feature would make this a non issue. That said, this feature is important and thus this isn't really an option.

I am currently exploring option 2 (targeted ignore), though we will see what issues arise in that exploration. I do have a branch created for this, and I will push whatever option I end up attempting there for others to test.

[miversen33]

@darrott

I have pushed up an update to the branch for this issue as a sort of WIP for this. It is working for me in a "jailed" environment, but as you are the one who opened this issue, can you test out this branch and lemme know if it works as you expect with your current situation?

This branch cannot be merged into v1.1 just yet, it is reliant on #95 being completed and merged (it is using some of the stuff from that branch to make life easier for node generation), but #95 being in testing right now, I would see both of these being merged into v1.1 by the end of this week :)

[miversen33]

This has been tested and approved. Closing out.