smbmount and passwords

[NAS]

Im being an idiot and im sure i worked out the answer before but when i try:

 

smbmount //tower2/ /mnt/tower2

 

its connecting but always asks for a password. Have i inadvertently added a password somewhere cause no GUI browsers on linux or windows needs one.?

[purko]

Im being an idiot and im sure i worked out the answer before but when i try:

 

smbmount //tower2/ /mnt/tower2

 

its connecting but always asks for a password. Have i inadvertently added a password somewhere cause no GUI browsers on linux or windows needs one.?

 

The above won't work.  You mount shares, not servers.  "//tower2/" is a server.

What would work is:  smbmount  //tower2/disk1  /mnt/tower2/disk1

 

If you don't want it to prompt you for the blank password, do this: 

smbmount  //tower2/disk1  /mnt/tower2/disk1  -o pass=

 

[NAS]

Yeah sorry i used to short an example. Same results using disk1 etc

 

The problem is a blank password will not work.

[jupilerman]

smbmount  //192.168.xxx.xxx/disk1  /mnt/tower2/disk1

 

This should work

[NAS]

your post sparked a thought. seems it works with the ip and not with the box name

 

what had me perplexed is that it asked for  a password.

 

so i check the ip that pinging the hostname gives

 

67.215.65.132

 

so this is opendns silly default when it cant find one.

 

curious

[Ford Prefect]

your post sparked a thought. seems it works with the ip and not with the box name

 

what had me perplexed is that it asked for  a password.

 

so i check the ip that pinging the hostname gives

 

67.215.65.132

 

so this is opendns silly default when it cant find one.

 

curious

 

This sparks another thought on my side...this is what i observed from

my stock unRAID in a VM:

 

The hostname (not FQDN) is propagated into /etc/hosts but for the loopback interface.

For eth0 (on DHCP) the hostname and FQDN is propagated back to DNS (and not into /etc/hosts)

So a ping to "tower" locally in an unraid shell will resolve to loopback not the

real net interface.

 

-> every external client can resolve fine, but a local app could end up in resolving

the IP wrong (incoming through an external trigger though, but what if resolve-calls

are internally nested somehow?).

 

Giving the IP instead of hostname would make this behaviour disappear.

 

So...is it a bug or feature?

unRAID without a real net makes no sense.

Giving the hostname to loopback in /etc/hosts is considered as bad manners in some parts of the world 

I'd vote for a bug 

[Von Loghausen]

I once had this behavior when I put my external hostname as the search parameter in /etc/resolv.conf

 

What happens is that once the dns lookup can't find the host, it adds that part to it and searches again.

That way if my host would be client123.myisp.net it would come up with tower.client123.myisp.net. That way, if a domain couldn't be resolved, it would always come up with my external ip. Very nasty indeed.

[Ford Prefect]

I once had this behavior when I put my external hostname as the search parameter in /etc/resolv.conf

 

What happens is that once the dns lookup can't find the host, it adds that part to it and searches again.

That way if my host would be client123.myisp.net it would come up with tower.client123.myisp.net. That way, if a domain couldn't be resolved, it would always come up with my external ip. Very nasty indeed.

 

...but what you used is a feature.

Putting a hostname into parts of the system that would only allow domain-names

is just satisfying a system the wrong way. So the behaviour you describe is

only to be expectd 

Put hostnames, which should resolve locally into /etc/hosts and you are fine...

[NAS]

I don't think it i unreasonable to expect that a system of two unRAIDs that are called TOWER1 and TOWER2 should by default be configured to know about each other.

 

 

[Ford Prefect]

I don't think it i unreasonable to expect that a system of two unRAIDs that are called TOWER1 and TOWER2 should by default be configured to know about each other.

 

Hmm...I am not sure if I understand that right...

 

I would agree on the feature of "knowing each other" in terms of

name resolution for easy connectivity as reasonable.

 

In terms of "configuration", which I would understand as a feature to provision each unRaid install

locally with the right config, I would think that this is unreasonable.

 

The first can be achieved by setting up your network DNS and IP provisioning and would not require to

change the config of a single unRAID instance if changes occur (when using DHCP).

 

The second would call for central maintenance, deployment and provisioning

infrastructure (what happens in a scenario where TOWER3 should be added later...this

will result in a need for change of TOWER1 and TOWER2, wouldn't it?)

[Von Loghausen]

...but what you used is a feature.

Putting a hostname into parts of the system that would only allow domain-names

is just satisfying a system the wrong way. So the behaviour you describe is

only to be expectd 

Put hostnames, which should resolve locally into /etc/hosts and you are fine...

Hey, I was young and put the wrong vars in the wrong places .

I misread and didn't know that said IP belongs to opendns, my bad.

[NAS]

I don't think it i unreasonable to expect that a system of two unRAIDs that are called TOWER1 and TOWER2 should by default be configured to know about each other.

 

Hmm...I am not sure if I understand that right...

 

I would agree on the feature of "knowing each other" in terms of

name resolution for easy connectivity as reasonable.

 

In terms of "configuration", which I would understand as a feature to provision each unRaid install

locally with the right config, I would think that this is unreasonable.

 

The first can be achieved by setting up your network DNS and IP provisioning and would not require to

change the config of a single unRAID instance if changes occur (when using DHCP).

 

The second would call for central maintenance, deployment and provisioning

infrastructure (what happens in a scenario where TOWER3 should be added later...this

will result in a need for change of TOWER1 and TOWER2, wouldn't it?)

 

I perhaps kept it to simple.

 

Let me put it another way.

 

If I plug a random windows box into my LAN and ping TOWER1 then the correct IP replys.

 

If i plug a new unRAID into my LAN and ping TOWER1 then an incorrect IP replys.

 

Keeping away from the technical reasoning for this at the moment this is what i was referring to as "I don't think it i unreasonable to expect that a system of two unRAIDs that are called TOWER1 and TOWER2 should by default be configured to know about each other."

[Ford Prefect]

I perhaps kept it to simple.

 

Let me put it another way.

 

If I plug a random windows box into my LAN and ping TOWER1 then the correct IP replys.

 

If i plug a new unRAID into my LAN and ping TOWER1 then an incorrect IP replys.

 

Keeping away from the technical reasoning for this at the moment this is what i was referring to as "I don't think it i unreasonable to expect that a system of two unRAIDs that are called TOWER1 and TOWER2 should by default be configured to know about each other."

 

Ha!...OK, that's a usecase and feature I can understand