I frequently use UNC paths to access network folder.
It would be like this:
\UNC\Fileshares\Storage
where \UNC\Fileshares is a UNC name of a physical server
I connect fine but after a few seconds I get an error saying that UNC canot be accessed.
Well, of course not because it does not exist by itself. But my question is why it happens. Does Opus try to establish a secondary connection?
Thanks!
What's meant by "it does not exist by itself" here?
Does the access succeed at all, or can it never be accessed in Opus?
Does the path literally begin with \UNC ?
\UNC\Fileshares being a server is unusual. The UNC syntax is normally \server\share, where \server would be the server by itself.
Our UNC path is actually 2 words. I will explain why in a minute.
\UNC\Fileshares is the part that you'd normally refer to as "\server" except in my casae it is a virtual 2-part name.
I don't want the server name to be available to users because if it goes down, then an instant behind the scene failover will kick the backup server, so my users will not even know there was a problem in the first place, and all their network shortcuts won't need to be changed.
If I just go to \UNC\Fileshares (this will get me to the listing of all shares on that specific UNC path), it will give me the error that it can't find "UNC" where "UNC" is the first part of the path's namespace. That's what I mean by "it does not exist by itself" as it requires the second part of the namespace as well.
So, for some reason, Opus connects to the UNC (which is good), and then throws an additional error.
This error only happens if I browse the UNC path with Opus.
I can cancel the error. The network connection is established. It is just something else happens that makes Opus attempt to connect to something that does not exist.
So presumably you get the same error if you go to the \unc level in Explorer?
If so, do you still get the error in Opus if you close the folder tree and close the Location toolbar? (It could be one of those which is trying to access each component in the path to build their lists of child items.)
Are you using DFS for this setup?
These two threads may be relevant, to making the root level of the UNC path work (as far as I know, all components of a UNC path including the root should be browsable, but I have not used DFS in quite a while so I may be wrong in that context, although the two threads below suggest it should work if the DNS / NetBios are correct and/or the FQDN is used instead of just the NetBIOS name):
social.technet.microsoft.com/For ... 4e0af2dca/
social.technet.microsoft.com/For ... fc716ca35/
[quote="leo"]So presumably you get the same error if you go to the \unc level in Explorer?
If so, do you still get the error in Opus if you close the folder tree and close the Location toolbar? (It could be one of those which is trying to access each component in the path to build their lists of child items.)
Are you using DFS for this setup?
These two threads may be relevant, to making the root level of the UNC path work (as far as I know, all components of a UNC path including the root should be browsable, but I have not used DFS in quite a while so I may be wrong in that context, although the two threads below suggest it should work if the DNS / NetBios are correct and/or the FQDN is used instead of just the NetBIOS name):
social.technet.microsoft.com/For ... 4e0af2dca/
social.technet.microsoft.com/For ... fc716ca35/[/quote]
OK, we got it. The folder tree was at fault. It tried to load the UNC level as a separate machine. This action has resulted in an error.
I should've thought about it.
Locking the folder tree takes care of the error.
Anyway to prevent this from happening without locking the tree?
Try setting Preferences / Folder Tree / Options / Populate contents for local devices only if it's not set already. That may prevent the tree from enumerating the root level.
That said, it could be happening from the tree simply trying to look up an icon (or similar) for the root level, without enumerating its contents at all.
Have you tried using the FQDN in the UNC path to see if that also gets rid of the error?
Thank you!
Now this is totally resolved. Thank you, it was driving me crazy 
Out of curiosity - and for posterity - what exactly fixed the UNC error? Was it the "Populate contents for local devices only" option that Leo mentioned - or using the FQDN instead of just the shortened netbios alias?
I've split the two unrelated questions into separate threads:
[ul][li]Double-click on Network Printer results in Open With dialog[/li]
[li]Delay opening the right-click menu for Recycle Bin[/li][/ul]