- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: CIFS for OpenVMS: Slow connect, leaves ~400 li...
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-25-2012 06:13 AM
05-25-2012 06:13 AM
CIFS for OpenVMS: Slow connect, leaves ~400 lines in .LOG file
Fellow VMSers,
Here's another puzzle that I cannot solve myself.
Fresh installation of CIFS for OpenVMS V1.2 ECO1 on OpenVMS V8.4 (Integrity blade 870c i2), recent patches applied, including UPDATE-V0600, SYS-V0200, ACRTL-V0100, as well as PS00_1 and PS00_2 for Samba.
Samba configured as MEMBER SERVER in a Windows 2008R2 Active Directory domain (SECURITY=ADS).
When I connect (using SMBCLIENT on either Linux or OpenVMS), a long time (>25 seconds) passes after entering the password and before receiving the "smb: \>" prompt., even though both client and server are idle. Each attempt to connect leaves about 400 lines of text in the SAMBA$ROOT:[VAR]<servername>_<clientname>.LOG file:
[2012/05/25 13:26:20, 1] SAMBA$SRC:[SOURCE.NSSWITCH]IDMAP_TDB.C;1:(397)␊
idmap uid range missing or invalid␊
idmap will be unable to map foreign SIDs␊
[2012/05/25 13:26:20, 0] SAMBA$SRC:[SOURCE.NSSWITCH]IDMAP.C;1:(749)␊
ERROR: Initialization failed for alloc backend, deferred!␊
These five lines repeat 79 times (for a 79*5 = 395 lines total, with the timestamps incrementing), followed by
[2012/05/25 13:26:34, 1] SAMBA$SRC:[SOURCE.SMBD]SERVICE.C;1:(1042)␊
<clientname> (172.45.10.194) connect to service <sharename> initially as user <username>
At first, I tried with WINBIND disabled (first option in SAMBA$CONFIG), but turning it on and supplying IDMAP UID / IDMAP GID ranges does not change the situation. I need to have all VMS accounts created and mapped manually, rather than automatically by Samba.
Any ideas what may be amiss and how to get a connection within a reasonable amount of time?
Do I need to collect more information for you to give good advice?
Regards,
Andreas
- Tags:
- CIFS
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-26-2012 05:30 AM
05-26-2012 05:30 AM
Re: CIFS for OpenVMS: Slow connect, leaves ~400 lines in .LOG file
Hi Andreas,
I saw a similar thing once that was related to DNS lookups. When a client established a new session the cifs server was sending itself DNS name queries even though the system wasn't configured as a bind server.?.
After setting 'log level = 4' in smb.conf and duplicating the problem, the log file samba$root:[var]<hostname>_smbd.log revealed the delay (though it was 40 seconds):
[2011/08/26 14:02:10.546161, 3] SAMBA$SRC:[SOURCE.LIBSMB]NAMEQUERY.C;1:(1044)
resolve_hosts: Attempting host lookup for name AAP44<0x20>
[2011/08/26 14:02:50.558442, 3] SAMBA$SRC:[SOURCE.LIBSMB]NAMEQUERY.C;1:(981)
resolve_lmhosts: Attempting lmhosts lookup for name AAP44<0x20>
(The <hostname>_smbd.log contains messages logged prior to the successful authentication of users. Once authenticated, CIFS closes the smbd log and opens a <hostname>_<client-name>.log to which it logs all subsequent messages).
The source of the problem couldn't be found quickly, so they avoided it by changing the 'name resolve order' values from the default of:
name resolve order = lmhosts wins host bcast
to
name resolve order = lmhosts wins bcast
However, they are using DOMAIN, not ADS, security mode. ADS security mode relies heavily on doing DNS name lookups to locate network resources (while DOMAIN security mode relies heavily on NetBIOS name resolution). Thus, I don't think removing DNS from the 'name resolve order' is a viable option for you...
Paul
- Tags:
- DNS
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-27-2012 08:05 PM
05-27-2012 08:05 PM
Re: CIFS for OpenVMS: Slow connect, leaves ~400 lines in .LOG file
Hi,
I just tried smbclient here and the response is instant to our domain controller or the VMS machine...
Here's an edited version of our core_smb.conf
[global]
netbios name = RX2600
workgroup = XXXXXX
security = ADS
require strongkey = yes
realm = XXXXXX.LOCAL
password server = ORCA
passdb backend = tdbsam
domain master = no
domain master = no
local master = no
preferred master = no
os level = 0
idmap uid = 6000-7000
idmap gid = 8000-9000
log file = /samba$root/var/%h_%m.log
username map = /samba$root/lib/username.map
printing = OpenVMS
load printers = no
[End of file]
We're using Winbind and also have an empty username.map in samba$root:[lib]
In the above Orca is the domain controller - this is Windows Server 2008 R2 and this is also the DNS server
RX2600 (very original) is the VMS machine
Did you successfully join the VMS machine to your domain during the CIFS install?
Have you started Kerberos?
Cheers,
Mark