Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adding SFTP drive does not work #55

Open
Svarthand opened this issue Mar 14, 2018 · 12 comments
Open

Adding SFTP drive does not work #55

Svarthand opened this issue Mar 14, 2018 · 12 comments

Comments

@Svarthand
Copy link

Svarthand commented Mar 14, 2018

When adding SFTP drive Friend reports "Device added successfully" but the drive is only shown in the "unmounted" drives list.

The behaviour is the same on my local Friend setup and on friendsky.cloud

@Svarthand Svarthand changed the title Adding SFT drive does not work Adding SFTP drive does not work Mar 14, 2018
@stefkosdev
Copy link

Can you post your logs somewhere (console output)?

@Svarthand
Copy link
Author

Sure, here are the mounted and the numounted lists from console:

Volumes: Handler: Visible:

System: built-in yes
RS_GoogleDrv: php.fsys yes
RS_Dropbox: php.fsys yes
Home: php.fsys yes

Found 4 disk(s) in mountlist.

Volumes: Type: Visible:

NAS: SFTP yes
RAM:: INRam yes
ROSNAS:: SFTP yes

Found 3 unmounted disk(s) in mountlist.

Here is the notifactation log:
notifications

@stefkosdev
Copy link

I need console output from your local FriendCore server.

@Svarthand
Copy link
Author

I dont have my local FriendCore server availible at the moment but the exact same problem and behaviour exists on friendsky.cloud as well.
I will upgrade to Friend 1.1.1 when I have a little spare time and see if the problem still exists and can add console output then.

@Svarthand
Copy link
Author

Same result in 1.1.1 both locally and on friendsky.cloud.
I have attached the logs.

friend_core_log-1-2018-04-04 (Friend 1.1).log

friend_core_log-1-2018-04-04 (Friend 1.1.1).log

@stefkosdev
Copy link

Looks like you attached logs (files) generated by FriendCore but can you launch it from console and give me console output?
I owe you here explanation.
In code we have 2 type of log functions which print something to console or console + log file.
First are macros DEBUG, INFO, FERROR which gives stuff only to console. We are using it to debug FC just after adding new feautures. They are almost everywhere and you can remove them by compiling FC with command "make release".
Second is function Log() which gives stuff to console and file if this is set. You cannot remove that without removing a code.
With your help I want to replace some macros by Log functions to prevent this kind of problems.

@Svarthand
Copy link
Author

I see, thank you for the clarification.
I have attached the console info.

console.txt

@stefkosdev
Copy link

Ok, your log says:
(fsysdyn/fsysssh2.c:546) 140501214394112 Connect_client:: could not connect to host=[192.168.0.2]
(system/fsys/device_handling.c:856) 140501214394112 [MountFS] roger.sjogren - Device not mounted name ROSNAS type SFTP

Looks like:

  • it cannot open default ssh/sftp port or
  • it cannot find address 192.168.0.2

@Svarthand
Copy link
Author

Yes.
However it reports that the mount were "successful" both locally and from friendsky.cloud.
I can connect to it using the same configuration using other software.
I experienced the same issue in 1.1 but Hogne found and fixed the issue then but a few weeks later the problem reappeared.

Anyway it is confusing that it reports mounting it successfully and then places it in the unmounted list.
If my configuration were wrong there would still be a bug here I think because it should report a mount failed instead, right?

@stefkosdev
Copy link

Yes, agree.
I will talk tomorrow with Hogne + check this code and fix. Thank you for your help.

@stefkosdev
Copy link

I reproduced your problem on my machine and:
1 as you see on your picture there is only information that FS was edited with success, there is no info about mounting with success
2 I will register bug in our internal system about messaging. User should get all details while doing actions on his drives.

@Svarthand
Copy link
Author

That is great.
More information that can help investigating configurational issues during mouning will be most helpful.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants