cifsmount problem - HP UX
This is a discussion on cifsmount problem - HP UX ; I'm testing cifs access from HP-UX (11i v2) to a Netapp filer (and not NFS).
i encounter multiple problem
# cifsmount //netapp/administration /mnt/smb -U Administrateur -D
-s
Administrateur's password on netapp:
LOC: Netbios name lookup failure
LOC: Netbios name lookup ...
-
cifsmount problem
I'm testing cifs access from HP-UX (11i v2) to a Netapp filer (and not NFS).
i encounter multiple problem
# cifsmount //netapp/administration /mnt/smb -U Administrateur -D
-s
Administrateur's password on netapp:
LOC: Netbios name lookup failure
LOC: Netbios name lookup failure
# cifsmount //172.x.x.x/administration /mnt/smb -U Administrateur -D
-s
Administrateur's password on 172.x.x.x:
Administrateur's password on 172.x.x.x:
LOC: Connection lost
/var/opt/cifsclient/debug/client-log.3982
07-25 10:32:02.382 [0] server: srvConnect server=172.20.4.150,
connectTimeout=5000, requestTimeout=60000
07-25 10:32:02.383 [16] pslsocket: connection reset by server
if i test cifsmount against other server:
* samba linux server
# cifsmount //server1/tmp /mnt/smb -U nobody
nobody's password on storage:
LOC: Netbios name lookup failure
LOC: Netbios name lookup failure
with its IP
# cifsmount //172.x.x.x/tmp /mnt/smb -U nobody
nobody's password on 172.x.x.x:
=> OK
* windows server
# cifsmount //server2/tmp /mnt/smb -U Administrateur -D
Administrateur's password on server2:
LOC: Netbios name lookup failure
LOC: Netbios name lookup failure
i've check the fw and netbios is opened, no log of some blocked packets.
DNS work ok but hpux cifsmount seems to use a netbios old trick to
resolve name ???
else why access to filer doesn't work ? (ok from linux and win)
thanks
regards
-
Re: cifsmount problem
Julien,
Which version of the CIFS Client are you using? You should be able to
connect to the NetApp server, and it may be easiet to simply open a
support call with HP to resolve your name-resolution issues. Support
will probably suggest (as I would) that you upgrade to the latest
version. Only A.02.xx and later support WINS; that may not be the
issue, but it may provide a solution.
Here are a few observations:
(1) Your use of
cifsmount //ip_addr/share...
is not supported. To specify the ip address of the server, the syntax is:
cifsmount -I ip_addr //server/share...
where "server" is the netbios name.
(2) You can find details about the CIFS Client's name-resolution
procedures on pp.37-38 of the Admin Guide, here:
http://www.docs.hp.com/en/B8724-90079/B8724-90079.pdf
In particular, check how to set up an individual-server section in the
config file; here you can specify the ipAddress of the server. However,
this is really needed only as a last-resort, if no name-resolution
method (WINS, NetBIOS broadcast, or DNS) can resolve the address of the
server.
(3) Starting at version A.02.02 of the CIFS Client, SMB-over-TCP is
supported. This completely by-passes NetBIOS. In this case, you can use:
cifsmount //server/share...
and even a fully-qualified DNS name for "server" should work. The
caveat here is that the server must support SMB-over-TCP (Windows NT
does not; later Windows servers do. I'm not sure about NetApp; I'd be
surprised if it does not). This may be your easiest fix. Just set
smbOverTcp = yes;
in /etc/opt/cifsclient/cifsclient.cfg, issue "cifsclient restart", and
try cifsmount again.
Finally, please clarify what you mean by this:
> i've check the fw and netbios is opened, no log of some
> blocked packets.
Please post your results.
-Eric Raeburn
HP CIFS Client Lab
julien Touche wrote:
> I'm testing cifs access from HP-UX (11i v2) to a Netapp filer (and not NFS).
> i encounter multiple problem
>
> # cifsmount //netapp/administration /mnt/smb -U Administrateur -D
> -s
> Administrateur's password on netapp:
> LOC: Netbios name lookup failure
> LOC: Netbios name lookup failure
> # cifsmount //172.x.x.x/administration /mnt/smb -U Administrateur -D
> -s
> Administrateur's password on 172.x.x.x:
> Administrateur's password on 172.x.x.x:
> LOC: Connection lost
>
> /var/opt/cifsclient/debug/client-log.3982
> 07-25 10:32:02.382 [0] server: srvConnect server=172.20.4.150,
> connectTimeout=5000, requestTimeout=60000
> 07-25 10:32:02.383 [16] pslsocket: connection reset by server
>
>
> if i test cifsmount against other server:
> * samba linux server
> # cifsmount //server1/tmp /mnt/smb -U nobody
> nobody's password on storage:
> LOC: Netbios name lookup failure
> LOC: Netbios name lookup failure
> with its IP
> # cifsmount //172.x.x.x/tmp /mnt/smb -U nobody
> nobody's password on 172.x.x.x:
> => OK
> * windows server
> # cifsmount //server2/tmp /mnt/smb -U Administrateur -D
> Administrateur's password on server2:
> LOC: Netbios name lookup failure
> LOC: Netbios name lookup failure
>
>
>
> i've check the fw and netbios is opened, no log of some blocked packets.
> DNS work ok but hpux cifsmount seems to use a netbios old trick to
> resolve name ???
> else why access to filer doesn't work ? (ok from linux and win)
>
>
> thanks
> regards
-
Re: cifsmount problem
eric raeburn wrote on 09/08/2006 23:18:
> Which version of the CIFS Client are you using? You should be able
> to connect to the NetApp server, and it may be easiet to simply open
> a support call with HP to resolve your name-resolution issues.
> Support will probably suggest (as I would) that you upgrade to the
> latest version. Only A.02.xx and later support WINS; that may not be
> the issue, but it may provide a solution.
a had a call with HP support but they only contact me today ...
i solve the case with these:
- updating from A.02.01 to 02.02
- using smbOverTcp = yes
- adding dns to hosts in /etc/nsswitch.conf
that's work now, but, with a speed of 3-4 MB/sec, it seems a bit slow
(both side and network are 1000F/no autoneg).
any advices to tune that ?
thanks
regards
-
Re: cifsmount problem
julien Touche wrote:
> eric raeburn wrote on 09/08/2006 23:18:
>
>>Which version of the CIFS Client are you using? You should be able
>>to connect to the NetApp server, and it may be easiet to simply open
>>a support call with HP to resolve your name-resolution issues.
>>Support will probably suggest (as I would) that you upgrade to the
>>latest version. Only A.02.xx and later support WINS; that may not be
>>the issue, but it may provide a solution.
>
>
> a had a call with HP support but they only contact me today ...
>
> i solve the case with these:
> - updating from A.02.01 to 02.02
> - using smbOverTcp = yes
> - adding dns to hosts in /etc/nsswitch.conf
>
> that's work now, but, with a speed of 3-4 MB/sec, it seems a bit slow
> (both side and network are 1000F/no autoneg).
>
> any advices to tune that ?
>
> thanks
> regards
Hello, Julien,
I'm glad you got the connection part working. I have since been
informed that Samba has only limited support SMB-over-TCP (see
http://www.samba.org/samba/docs/man/...html#id2551620).
If you have connection problems with Samba servers, refer to the Admin
Guide, which explains how to set up the config file such that the CIFS
Client can be used both with servers that support this feature and those
that do not.
Regarding performance, first ensure you don't have any logLevels turned
on in addition to the defaults. Compare the config file to the default
(cifsclient.cfg.default in the same directory). The default logging is
minimal and does not affect performance, but when you enable more
levels, things can slow down dramatically.
Then I suggest you make some comparisons to NFS and Windows clients.
The HP CIFS Client should be **roughly** similar. Between NFS and CIFS
one stack is faster on reads, one on writes (I don't remember which).
The comparison is also somewhat dependent on file size. The comparison
to Windows is difficult for the HP client, since it is not implemented
in the kernel, but might be useful.
Performance is notoriously difficult to measure, because it depends on
so many external factors (buffer cache, lan latency, local and remote
disk activity, other activity on the server, etc.). If you think there
is a real problem, please follow up with support. You can try adjusting
the parameter nfsKernelCacheTime (see the discussion in the Admin
Guide). We always leave this at its default (0), however, and have not
seen any performance problems.
Good luck,
Eric