Thank you for your donation!


Cloudsmith graciously provides open-source package management and distribution for our project.


Solved: Configuring Windows To Access Moode USB Drive
#1
SOLVED - see this post http://moodeaudio.org/forum/showthread.p...3#pid20653

----------------------------------------------------------------------------------------------------------------------------------------



I've been trying to help myself here most of the day, time to tap myself out and ask for help.

  • Raspberry Pi 3B running Moode with an attached USB hard drive
  • I am able to connect to the USB hard drive over the network from one Windows 10 PC,  read/write, etc  at  \\10.0.0.215\PINAS\    (the local IP and share name)
  • I am able to connect to the USB hard drive over the network from a second pi running Volumio at the same address
  • I am able to connect to the web interface of the Moode device at http://10.0.0.215/ from everywhere.

This indicates the Moode device is configured correctly.

What I cannot do is access the USB drive from any other Windows 10 devices in my houses (er, two of them) -  on both I have enabled smb1 but beyond that I'm not really getting anywhere.   I have not been able to find any obvious differences in how the Windows 10 devices are configured,  just that one is able to access the drive and none of the other ones are. 

Suggestions?

Thanks
Raspberry Pi 3b+  Currently being updated to a larger SD card w/ local library.


Reply
#2
You probably ought to be asking on some MS Windows forum. I don't pretend to be a MS support person. Here's a few things to think about.


(you've twigged to the SMB1 issue so I'm assuming all PCs have SMB1 support enabled)

Have you ensured all your hosts are part of the same work group (traditionally "WORK GROUP")?

Have you tried pinging your moOde player from the misbehaving PCs to be sure it can be reached?

Have you tried using the "net" commands from the command line of your PCs, in particular something like "net view \\moode" ?

https://www.tenforums.com/tutorials/1120...ws-pc.html

Have you tried installing the Windows Subsystem for Linux on your PC(s) so you can use traditional Linux tools to diagnose the network? (I do this because I know Linux much better than I know MS Windows, but the things-to-think-about above cover similar ground.)

Regards,
Kent
Reply
#3
(05-25-2020, 02:32 AM)TheOldPresbyope Wrote: You probably ought to be asking on some MS Windows forum. I don't pretend to be a MS support person. Here's a few things to think about.

Indeed - it's been a surprisingly common question across a ton of them! Spent a fair number of hours today reading and trying solutions where they existed on the client side (Windows) - no reason to suspect the "server" side since it's accessible to at least one client.

Well.. this is why I posted here in the chit-chat section and not the tech support section since Moode is working as it should Smile

(05-25-2020, 02:32 AM)TheOldPresbyope Wrote: Have you ensured all your hosts are part of the same work group (traditionally "WORK GROUP")?

Yes, both the working computer & the misbehaving ones are in a workgroup called WORKGROUP Smile





(05-25-2020, 02:32 AM)TheOldPresbyope Wrote: Have you tried pinging your moOde player from the misbehaving PCs to be sure it can be reached?

I can access the moode player's web UI from the browser on those devices, so a ping would not likely reveal more information than that - but yeah good call to make sure it's reachable by any means.

(05-25-2020, 02:32 AM)TheOldPresbyope Wrote: Have you tried using the "net" commands from the command line of your PCs, in particular something like "net view \\moode" ?

I had not before now, but the result is an error 53 "network path not found" on the misbehaving computers. On the one behaving computer it instantly produces a list of the shared directories.

As for installing the windows subsystem for linux... I'm a clown when it comes to linux so that would not speed me up Sad

Well, looks like I still have some work to do. Bad news is that the working Windows 10 machine is slated for retirement so I'd rather not have to rely on a solution like "well just use the one that works to manage it" .

One other thing I did check, both the working computer and the non-working ones are running the same version number of Windows 10. Both working/not working also have netbios enabled. Noting that in here just in case future people search this thread hoping for answers.

Cheers!
Raspberry Pi 3b+  Currently being updated to a larger SD card w/ local library.


Reply
#4
Your search engine is your friend.

Try searching on "windows 10 net use command error 53". I'm staring at the list of 10+ pages of search results offered up by Google. I suspect that they all discuss the same number of factors and that they all are equally dissatisfying in offering up a bunch of nonspecific things to try. 

Given the large number of system settings hidden away in the Windows registry, it's easy to have seemingly identical Windows boxes behave differently.

Truth to tell, this can happen with Linux systems too. It's just that being open-source software from many distributed contributors Linux has more documentation of the settings. That's not guaranteed, of course, even for Linux, but it's a lot easier discussion when things go wrong.

Good luck.

Regards,
Kent
Reply
#5
(05-25-2020, 01:04 AM)kurek Wrote: I've been trying to help myself here most of the day, time to tap myself out and ask for help.

  • Raspberry Pi 3B running Moode with an attached USB hard drive
  • I am able to connect to the USB hard drive over the network from one Windows 10 PC,  read/write, etc  at  \\10.0.0.215\PINAS\    (the local IP and share name)
  • I am able to connect to the USB hard drive over the network from a second pi running Volumio at the same address
  • I am able to connect to the web interface of the Moode device at http://10.0.0.215/ from everywhere.

This indicates the Moode device is configured correctly.

What I cannot do is access the USB drive from any other Windows 10 devices in my houses (er, two of them) -  on both I have enabled smb1 but beyond that I'm not really getting anywhere.   I have not been able to find any obvious differences in how the Windows 10 devices are configured,  just that one is able to access the drive and none of the other ones are. 
........................................   snip   ..........................................

Hello @kurek....

I've read the all the posts from your initial post onwards... Following up @TheOldPresbyope's suggestion to investigate the leads triggered by the 'error 53' Google Search is the logical path...

The way you want/perform access from all of the computers to a storage connected to another computer may be the reason for the encountered issue; scrutinise the way all the devices are connected to the Home Network,  whether you use Powerline Ethernet and/or WiFi extenders... You may find that some computers are on one subnet and others on another subnet. I'd suggest that you gather all the computers in one room, connect them by LAN cable to Network Switch which in turn is connected to the Router and check the access to the RPi+USB HDD. Any fault finding should be carried out in that configuration.

However... if the 'Search,Try, Search Again, Try, etc' could turn out tedious why not change the way you access the USB hard disk drive which operates as your Digital Music Storage device...? The idea is to create a Network-Attached Storage by:
- either connecting the USB HDD to your Router (if iit's got USB ports)
- or, better, re-purpose one of the Windows boxes as a NAS either by installing native NAS operating system on the PC on the boot HDD (wiping the Win10) or in Virtual Machine
- or, simply, buy a cheap NAS

This way any computer, tablet, smartphone on the Home network will have access to the Music Storage. I'm sure that you may have your strong reasons to want sort-of-side access to the music from all sorts of computers but the connectivity and protocols chain may get erratic.
Reply
#6
I suppose their might might be a concern that any new NAS-like configuration may still pose a problem with access from the Windows 10 boxes, especially if the one Windows box that does seem to connect is going to be retired.

@kurek, since you reminded me that you can access the moOdeUI from the recalcitrant host, can you use the net commands to connect via the moOde player's IP address?

I'm not in a position to say that this is a magic bullet, but here's an example of a connection:

Code:
C:\Users\Kent>net use N: \\192.168.1.184\NAS
The command completed successfully.

C:\Users\Kent>net view \\192.168.1.184
Shared resources at \\192.168.1.184

moOde SMB Server

Share name  Type  Used as  Comment
-----------------------------------------
NAS         Disk  N:       NAS Shares
Playlists   Disk           Playlist Directory
Radio       Disk           RADIO Stations
SDCard      Disk           SDCARD Storage
The command completed successfully.

C:\Users\Kent>

and I can now see the contents of moOde's NAS share under "My PC" in my Windows File Manager. The advantage of this test is that it avoids questions of mDNS and WINS, yada, yada, yada.

I should note that I do *not* have SMB1.0 / CIFS file sharing support activated on this host. My moOde players don't show up in the Computers section of the Network view of the File Manager, but they do show up as UPNP and DLNA hosts in the Media Devices section.

Regards,
Kent
Reply
#7
Problem solved - that took a lot more trial and error than would have been nice but hopefully this helps future users!

Link to solution here: https://support.microsoft.com/en-us/help...indows-ser

Actual steps to solution here:

Open "Local Group Policy Editor" by searching in Start Menu or going to Run and running gpedit.msc, then go to Computer Configuration\Administrative Templates\network\Lanman Workstation and: "Enable insecure guest logons"




After performing the above action,  mapping the drive as a network location was pretty much immediate, no reboot even. 

Thanks for your assistance and patience,  now on to the fun bits.  

   
Raspberry Pi 3b+  Currently being updated to a larger SD card w/ local library.


Reply
#8
Ah, some tubeyness I see :-)
Enjoy the Music!
moodeaudio.org | Mastodon Feed | GitHub
Reply
#9
"It just goes to show you, Jane, if it's not one thing it's another."

I'm curious why one system was successfully accessing the moOde share and the other two weren't. Had you already done this or done its equivalent some other way?

Regards,
Kent
Reply
#10
(05-25-2020, 10:04 PM)Tim Curtis Wrote: Ah, some tubeyness I see :-)

Well.. uhh... tube inspired Big Grin     It's really just a USB sound card with a novelty shape.   I bought it years ago because my laptop only had a mono mic input and this was a $9 way to get a stereo line in for a project I was recording at the time.

Then it lived in a drawer.     But it came back into service for getting analog out from a Raspberry Pi - it's not audiophile material but I think it compares favorably with the onboard pi audio.

(05-25-2020, 10:08 PM)TheOldPresbyope Wrote: "It just goes to show you, Jane, if it's not one thing it's another."

I'm curious why one system was successfully accessing the moOde share and the other two weren't. Had you already done this or done its equivalent some other way?

Regards,
Kent

Same - but the originally working machine is a laptop I've had a long time (3rd gen i5) and served as my daily driver/everything machine for most of its life, no way to remember all the stuff that's happened.     I had it connected to an early gen Apple Time Capsule/Airport for a while and maybe the apple management software installs some tweaks.  

Still,  I think the above solution is at least somewhat more satisfying than "I dunno I reinstalled windows and it fixed it" .  Smile
Raspberry Pi 3b+  Currently being updated to a larger SD card w/ local library.


Reply


Forum Jump: