XYplorer Beta Club

After "Assume servers are available" is unchecked.
network server credential dialog is not popping

I did not touch this for a longer while. Are you sure this is brand-new?

Good afternoon all,
I noticed this happening to me today (haven't checked a network path in a while). I am using 18.50.0100 on Windows 10 CU x64, accessing a path on my NAS that requires a manual logon name/password. Mapped drives w/saved credentials work fine.

General / Controls and More / Network
Assume that servers are available (checked)
Pre-check... (unchecked)
Cache network servers (checked)

In the address bar in my top pane, if I type \\10.10.10.3\shared and press ENTER I immediately get the 'Location not available' display. Here is what I have tried so far to correct it :
-uncheck the above options (restarting XY in between) - same results
-used List Management House Cleaning XY script to clean everything - same results
-closed XY, delete servers.dat - same results

Here is what "works". Open Windows Explorer (gack!), type the same path, credentials popup is displayed, enter name/password and the path is opened. Go back to XY, type in the same path in the address bar, press ENTER and the path is opened.

Is there any other XY setting or procedure I can try to force the logon prompt ?

Try the logon scripting command through the address bar and see what happens:

Good morning admin,
Back at work and can now test your request out. When I run : in the address bar (fresh bootup of the machine), I get : Typing in the path directly into the address bar, I get : Finally, if I use Windows Explorer with the same path, I am prompted, enter the name/password and it connects. Switch back to XY, repeat either test listed above and it immediately connects. I have another path on another NAS that is mapped w/saved credentials as a network drive (drive X) and it connects correctly in XY. Recently, only the ones with that require a prompt are having this issue.

VeeGee wrote:Good morning admin,
Back at work and can now test your request out. When I run :

Code: Select all

logon "\\10.10.10.3\shared";

in the address bar (fresh bootup of the machine), I get :

Code: Select all

Logon failed with error 67.
logon
\\10.10.10.3\shared

That's ERROR_BAD_NET_NAME. Google it...

https://msdn.microsoft.com/en-us/librar ... 2147217396

ERROR_BAD_NET_NAME: The value specified by the lpRemoteName member is not acceptable to any network resource provider, either because the resource name is invalid, or because the named resource cannot be located.

Sure, thanks for the link; however, explain to me how every other app (Explorer, DO, etc.) except XY can see it, access it and prompt for it. I am not doing anything different inside of XY. It has always worked in the past, connect, prompt, access. I've only noticed this after updating to the latest official. I can't test the beta on that machine due to the digital signatures missing on betas - Symantec blocks it.

I will setup a new share that forces a prompt from this machine (different network) and test it on the latest beta posted.

Good question.

Must have been one of these: I'll upload another beta (signed!) in some minutes...

Thank you for the quick update. Downloaded, installed, typed in my address and BAM - user name/password prompt !

Cool!

Good afternoon,
Using the latest official release, I am no longer getting prompted for network credentials when connecting to a share. This happened a few releases ago and a quick fix was issued to correct it - looks like the bug is back.

Immediately after typing the \\ address in the bar : I get this message : No prompt for the user/password like before.

I don't recall any setting changes that I have done and I get the same results in a fresh instance of XY. If I do the same in Explorer, I get the prompt and then it connects. Once connected via Explorer, typing the address into XY immediately connects to the share (guessing since it's already authenticated).

Sorry VeeGee, but it does work here with a fresh instance of XY (v18.90.0100)...

Thanks highend for checking. I figured it out. I asked myself, what have I changed lately...I started using the Mini Tree ! With the Mini Tree enabled, I get the error/no prompt/etc. If I turn off the Mini Tree (via the Toolbar), then try it again, the network credential dialog is displayed and I can connect to the share. If I close the tab, re-enable the Mini Tree, restart XY and try again - same error as before.

I stand corrected on the fresh instance of XY - it works fine since the Mini Tree is disabled. Yesterday I was just restarting XY and thinking it was "fresh" instead of using the ::fresh command

Mh, no, not here.

Fresh instance, mini tree enabled (as like you with the toolbar button), \\<ip>\<name of the share>
entering in the address bar: the credential window pops up...

Or did you try it by clicking on an entry under network in the minitree?

Good morning all,
I was able to get the network prompt using the Full and Mini Trees on a ::fresh instance. Must be something in my INI or setup, because I cannot get the prompt using the Mini Tree in my normal XY instance.

Doing some more testing. Start XY with full Tree on, type the network address or click it in the tree (left side) and I get the prompt. I cancel out so my credentials aren't cached. I click the Mini Tree and try again :
1 - typing from the address bar, same results, no prompt and I see 'The user name or password...' displayed immediately.
2 - clicking on the network location in the Mini Tree (left side), same results (but with a twist). No prompt and I see 'The user name or password...' displayed immediately: ; however, with the error panel displayed, I un-click the Mini Tree button and get this, a prompt and a busy message : I can click Switch To... and everything disappears.

If I allow XY to connect with the Full Tree enabled, no problems when switching back and forth from Full to Mini. Same happens if I allow Explorer to connect and then start XY.

For now I've stopped using the Mini Tree. Completely ignoring the Mini Tree, everything prompts, connects and works as normal. I made a fresh INI and am comparing it w/DIFF to my standard INI to see if there are any settings that stand out.