Bug 85116 - smbmount can't connect to XP share, confuses IP addresses
smbmount can't connect to XP share, confuses IP addresses
Status: CLOSED CANTFIX
Product: Fedora
Classification: Fedora
Component: samba (Show other bugs)
rawhide
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jay Fenlason
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-02-25 16:39 EST by Eugenia Loli-Queru
Modified: 2014-08-31 19:24 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-01-12 10:07:51 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Eugenia Loli-Queru 2003-02-25 16:39:44 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0

Description of problem:
I tried to mount the share via the command line. I did this:
smbmount //EUGENIA/ShareDir /home/eugenia/samba -o username=Eugenia1
password=XXX ip=10.0.0.10

The error I was getting was that there is no route to host for 10.0.0.19.
However, my PC is 10.0.0.10 and I even specifically ask for this IP via the ip
attribute in the command line (but it seems the app
defaults to the requested PC name first). I got to XP's control panel and
checked around if my PC broadcasts more than 1 IP address, and I was right. I
have a VMWare virtual ethernet device there, which has a 10.0.0.19 address!

Older Samba version other distros use is able to see the right IP address from
the real ethernet device, and not the "virtual" device
VMWare is exposing for its needed NAT abilities.

I checked all my settings on my XP PRO and they all seem fine.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
 smbmount //EUGENIA/ShareDir /home/eugenia/samba -o username=Eugenia1
password=XXX ip=10.0.0.10

    

Actual Results:  Error that there is no route to host 10.0.0.19

Expected Results:  To be able to mount the right share from the right IP address
on /home/eugenia/samba

Additional info:
Comment 1 giulioo 2003-02-25 17:45:02 EST
Shouldn't you use
-o param=value , param=value 
instead of
-o param=value param=value
?

I think that without "," only the 1st is processed.

Comment 2 Eugenia Loli-Queru 2003-02-25 18:44:54 EST
I tried that too, no good. The problem here is that smbmount is trying to 
connect to 10.0.0.19 and not to the .10.
However, this morning I tried to mount the share by IP address 
(smbmount //10.0.0.10/ShareDir etc) and by doing so this way, it gave me two 
error messages, but it did managed to mount the share successfully. But doing 
so the normal way, by machine name, it won't do it because it gets confused by 
the two IPs.
Comment 3 Jay Fenlason 2003-03-06 15:31:33 EST
It sounds like you have a generic problem in hostname lookup.  What does
getent hosts eugenia
display?
Comment 4 Eugenia Loli-Queru 2003-03-09 21:28:54 EST
It displays nothing... getent gets its values from some "databases" and my 
WinXP machine is not registered in these dbs under the linux installation. It 
doesn't have to anyway, it should just look up the network for the requested 
value if it can't find it in the dbs.
Comment 5 Eugenia Loli-Queru 2003-09-30 00:50:00 EDT
New info: I installed Fedora Core, and the bug is _still_ there.
I speak of a bug and not of something else, because Slackware 9.1 on the _same
machine_ sees these samba shares just fine! I did not configure _anything_,
nautilus on Slackware just works with my windows shares. On the brand new Fedora
instllation and RHL9, it just doesn't work!
Comment 6 John Thacker 2006-10-29 17:52:18 EST
[This is a mass update sent to many bugs that missed earlier such messages due
to having their version set to a test version.]

This bug was originally filed against a version of Fedora Core which is no
longer supported, even for security updates.  Many changes have occured since
then.  Please retest this bug against a still supported version.  Note that FC3
and FC4 are supported by Fedora Legacy for security fixes only.  If
it still occurs on FC5 or FC6, please assign to the correct
version.  Otherwise, if this a security issue, please change the
product to Fedora Legacy.  Thanks, and we are sorry that we did not
get to this bug earlier.

This bug will be closed after a few weeks if no information is given indicating
that the bug is still present in a supported release.
Comment 7 John Thacker 2007-01-12 10:07:51 EST
Closing per lack of response to previous request for information.
This bug was originally filed against a much earlier version of Fedora
Core, and significant changes have taken place since the last version
for which this bug is confirmed.

Note that FC3 and FC4 are supported by Fedora Legacy for security
fixes only.  Please install a still supported version and retest.  If
it still occurs on FC5 or FC6, please reopen and assign to the correct
version.  Otherwise, if this a security issue, please change the
product to Fedora Legacy.  Thanks, and we are sorry that we did not
get to this bug earlier.

Note You need to log in before you can comment on or make changes to this bug.