[PROBLEM] SCAN mount using SMB

[DaveJohnsonOtt]

In your case the moOde SCAN has only returned the host name of your NAS and not any of the Samba share names advertised by the host MYBOOKLIVE.

What do you enter in other players to access the share?

Everything else sees the NAS stack.  I don't have to search.  Win 10, iOS multiple apps.  Perhaps I'm looking in the wrong direction?


I am very new to RPi... everything to this point has worked well - knew it would be a bit of a hobby ;-)

[Tim Curtis]

Very odd. Most of our users have no problem with NAS shares.

[DaveJohnsonOtt]

I've never had an issue connecting to the NAS before. I'm tempted to mount my music shares on a DAS stack as an inelegant but effective solution, but that really defeats the purpose.

Could you recommend a RPI/moOde consultant who might be able to get onto a remote session for fee & see if there's an elusive detail preventing mount? As mentioned, I'd like to solve the NAS part before moving onto the streaming services (I'm in the Apple ecosystem & have AirPlay's CD quality for now).

[TheOldPresbyope]

I've never had an issue connecting to the NAS before.  I'm tempted to mount my music shares on a DAS stack as an inelegant but effective solution, but that really defeats the purpose.  

Could you recommend a RPI/moOde consultant who might be able to get onto a remote session for fee & see if there's an elusive detail preventing mount?  As mentioned, I'd like to solve the NAS part before moving onto the streaming services (I'm in the Apple ecosystem & have AirPlay's CD quality for now).

I don’t know anything about WD’s MyBook series and their user docs are useless but…

  that screen capture of a directory listing in post #6 suggests the share name is “Public”

Regards,
Kent

[Phil323UK]

Hi,
Have you tried adding 'SMB version' to your Mount flags?
start with vers=1.0 and work your way up.

Regards,
Phil.

[DaveJohnsonOtt]

I've never had an issue connecting to the NAS before.  I'm tempted to mount my music shares on a DAS stack as an inelegant but effective solution, but that really defeats the purpose.  

Could you recommend a RPI/moOde consultant who might be able to get onto a remote session for fee & see if there's an elusive detail preventing mount?  As mentioned, I'd like to solve the NAS part before moving onto the streaming services (I'm in the Apple ecosystem & have AirPlay's CD quality for now).

I don’t know anything about WD’s MyBook series and their user docs are useless but…

  that screen capture of a directory listing in post #6 suggests the share name is “Public”

Regards,
Kent

You're right, that part of the NAS is Public-ly visible without ID/PW in the network.  I've tried that too.

[DaveJohnsonOtt]

Hi,
Have you tried adding 'SMB version' to your Mount flags?
start with vers=1.0 and work your way up.

Regards,
Phil.

TBH Phil, I'm not sure much about it (RPI newbie, w/no Linux background).

Mount Flags are: ro,dir_mode=0777,file_mode=0777.

Would I be adding another ", SMB version=1.0" to the existing string, and then go up in version #'s?

[TheOldPresbyope]

Hi,
Have you tried adding 'SMB version' to your Mount flags?
start with vers=1.0 and work your way up.

Regards,
Phil.

TBH Phil, I'm not sure much about it (RPI newbie, w/no Linux background).

Mount Flags are:  ro,dir_mode=0777,file_mode=0777.  

Would I be adding another ", SMB version=1.0" to the existing string, and then go up in version #'s?

As Phil and the information line under the Mount Flags box at the bottom of the Music Source screen suggest, one adds ",vers=2.0" or such at the end of the mount flags string. (The default level is 1.0 if none is specified.) 

However, after Tim made changes to the mount code some time ago, this seems mostly to be unnecessary since it now only specifies the minimum protocol level acceptable to moOde. The moOdeOS and the Samba server negotiate the highest protocol level acceptable to both during a negotiation phase.

For example, I have mounted my "MUSIC" share (yes, it's all-caps on my server) from my NAS named "omv-hc1" specifying the path

Code:

omv-hc1.local/MUSIC

and accepting moOde's default mount flags.

When I check using the mount command from the command line I see the following line in the midst of the output

Code:

//omv-hc1.local/MUSIC on /mnt/NAS/OMV type cifs (ro,relatime,vers=3.1.1,cache=strict,username=Guest,uid=0,noforceuid,gid=0,noforcegid,addr=10.0.0.2,file_mode=0777,dir_mode=0777,soft,nounix,serverino,mapposix,rsize=61440,wsize=65536,bsize=1048576,echo_interval=60,actimeo=1)

This says moOde and my OpenMediaServer negotiated vers=3.1.1 as the protocol level. In any case, I'd expect a different error message if the protocol specification were incorrect.

The error message I responded to in an earlier port suggests, rather, that the share name is being entered incorrectly but I can only guess what it likely to be from the evidence provided or from the WD documentation.

Sorry I missed that you'd mentioned "Public" earlier but you'd also mentioned "PUBLIC". They aren't the same.

Have you tried specifying the path "MYBOOKLIVE/Public/Shared Music"?

Regards,
Kent

[Phil323UK]

Hi,
Have you tried adding 'SMB version' to your Mount flags?
start with vers=1.0 and work your way up.

Regards,
Phil.

TBH Phil, I'm not sure much about it (RPI newbie, w/no Linux background).

Mount Flags are:  ro,dir_mode=0777,file_mode=0777.  

Would I be adding another ", SMB version=1.0" to the existing string, and then go up in version #'s?

Hi Dave,

Your original post mirrors my experience trying to mount an Apple Time Capsule.
I went through every combination of share name possible without success, then found a reference somewhere about adding the vers flag.
At this stage you have nothing to lose in trying the 'vers' flag. you may get to see that elusive green tick.

ro,dir_mode=0777,file_mode=0777,vers=1.0

Hi Kent,

" (The default level is 1.0 if none is specified.) "

This is not my experience, if I remove vers=1.0 from my Mount flags my Time Capsule fails to mount. Then I get exactly the same error message as Dave, I am on Moode 7.6.1.

Regards,
Phil.

[TheOldPresbyope]

@Phil323UK

My bad. 

I was thinking of the SMB.conf options of "min protocol=" and "max protocol=' and didn't check what I said. [1]

Turns out setting "vers=1.0" client-side seems to override the automatic negotiation. In the example I cited of moOde mounting a share from my OpenMediaVault server, if I accept moOde's default share parameters, I get a mount at vers=3.1.1 but if I set "vers=1.0" explicitly that's the version used for the mount. Similarly, setting "vers=2.0" forces that protocol version.

Sadly, the Samba documentation is a mixed bag of too much information about some things and too little about others. I tried searching on the phrase "automatic negotiation" and couldn't find a good description of how it proceeds---even though the phrase is used in the description of the min and max protocol settings.

Thanks for keeping me honest! I'll have to go back and edit my post.

Having said all that, I am still perplexed by the reported error message, which seems unrelated to protocol version. I'll have to spin up a test server where I can do some more experiments. Sigh.

Unfortunately, moOde is just the client here. Like my NAS, it's based on the open-source Samba codebase. We don't know what's going on in the various server implementations in Windows and MacOS, or in appliances like the WD MyBook series, various network routers, yada yada yada.

Regards,
Kent

[1] My dad was fond of saying "it's not what you don't know that gets you in trouble, it's what you think you know that ain't so."