HPE GreenLake Administration
- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- CIFS 1.1 PDC/account handshake configuration?
Operating System - OpenVMS
1828415
Members
3432
Online
109977
Solutions
Forums
Categories
Company
Local Language
back
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Forums
Discussions
Discussions
Discussions
Forums
Discussions
back
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
Discussion Boards
Blogs
Information
Community
Resources
Community Language
Language
Forums
Blogs
Go to solution
Topic Options
- 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
03-25-2009 10:35 AM
03-25-2009 10:35 AM
I'm lookin for help in getting CIFS 1.1 successfully deployed
in a domain trust relationship with an existing Windows PDC emulator
and Windows XP SP3 workstations.
We don't want SAMBA to use the DEFAULT account,
but evidence suggests it is doing just that
and causing my shares access problem:
Extract from samba$smbd_startup.log
$ smbd := $samba$exe:samba$smbd.exe
$
$ SET PROC/DUMP
$ smbd
%SYSTEM-F-USERDISABLED, account is disabled
%TRACE-F-TRACEBACK, symbolic stack dump follows
image module routine line rel PC abs PC
SAMBA$SHR 0 000000000018AF18 00000000001DCF18
SAMBA$SHR 0 0000000000230224 0000000000282224
SAMBA$SHR 0 0000000000499364 00000000004EB364
SAMBA$SHR 0 0000000000499E24 00000000004EBE24
SAMBA$SHR 0 0000000000349484 000000000039B484
SAMBA$SHR 0 0000000000292974 00000000002E4974
SAMBA$SHR 0 0000000000293DA8 00000000002E5DA8
SAMBA$SHR 0 00000000002BB1B4 000000000030D1B4
SAMBA$SHR 0 000000000022E048 0000000000280048
SAMBA$SHR 0 000000000022E490 0000000000280490
SAMBA$SHR 0 000000000022FB48 0000000000281B48
SAMBA$SHR 0 000000000021CB28 000000000026EB28
SAMBA$SMBD 0 00000000000300D4 00000000000300D4
SAMBA$SMBD 0 000000000003006C 000000000003006C
SAMBA$SMBD 0 00000000000303A4 00000000000303A4
0 FFFFFFFF8037DCE4 FFFFFFFF8037DCE4
%TRACE-I-END, end of TRACE stack dump
SAMBA$SMBD job terminated at 25-MAR-2009 13:39:05.12
changing the DEFAULT account to /FLAG=NODISUSER changes the failure to:
$ SET PROC/DUMP
$ smbd
%SYSTEM-F-OPCCUS, opcode reserved to customer fault at PC=FFFFFFFF80FA1A04, PS=0
000001B
%TRACE-F-TRACEBACK, symbolic stack dump follows
image module routine line rel PC abs PC
DECC$SHR_EV56 0 0000000000109A04 FFFFFFFF80FA1A04
SAMBA$SHR 0 0000000000431594 0000000000483594
SAMBA$SHR 0 000000000022FF1C 0000000000281F1C
SAMBA$SHR 0 0000000000499364 00000000004EB364
SAMBA$SHR 0 0000000000499E24 00000000004EBE24
SAMBA$SHR 0 0000000000349484 000000000039B484
SAMBA$SHR 0 0000000000292974 00000000002E4974
SAMBA$SHR 0 0000000000293DA8 00000000002E5DA8
SAMBA$SHR 0 00000000002BB1B4 000000000030D1B4
SAMBA$SHR 0 000000000022E048 0000000000280048
SAMBA$SHR 0 000000000022E490 0000000000280490
SAMBA$SHR 0 000000000022FB48 0000000000281B48
SAMBA$SHR 0 000000000021CB28 000000000026EB28
SAMBA$SMBD 0 00000000000300D4 00000000000300D4
SAMBA$SMBD 0 000000000003006C 000000000003006C
SAMBA$SMBD 0 00000000000303A4 00000000000303A4
0 FFFFFFFF8037DCE4 FFFFFFFF8037DCE4
%TRACE-I-END, end of TRACE stack dump
SAMBA$SMBD job terminated at 25-MAR-2009 15:03:59.50
\\
Product/patch details:
CIFS 1.1 distribution
V/A 8.3 with VMS83A_ACRTL V5.0 and Update V8 applied
TCPIP 5.6 ECO 3
CIFS 1.1 / Samba 3.0.28A test SMB.CONF file:
# Global parameters
[global]
server string = Samba %v running on %h (OpenVMS)
workgroup = WILMA
netbios name = %h
security = DOMAIN
encrypt passwords = Yes
# update encrypted = Yes
name resolve order = lmhosts host wins bcast
# passdb backend = tdbsam
#
# JYC recommended addition
#
# password server = W2K3AD
Password server = *
log file = /samba$log/log.%m
printcap name = /sys$manager/ucx$printcap.dat
guest account = DYMAX
create mask = 0777
print command = print %f/queue=%p/delete/passall/name="""""%s"""""
lprm command = delete/entry=%j
map archive = No
printing = OpenVMS
log level = 10
[S]
comment = Application shared tree and operating system
path = /dym$disk/000000
read only = No
create mask = 0775
guest ok = Yes
[printers]
comment = All Printers
path = /dym$disk/smb_scr
create mask = 0700
guest ok = Yes
printable = Yes
browseable = No
{end}
I'm presuming that I have successfully created a trust relationship
between the SAMBA 3.0.28A test node (DYMC) and the PDC based on this test
on the test node:
$ @samba$root:[bin]samba$define_commands
$ net rpc testjoin
Join to 'WILMA' is OK
Workstation access from RR account is failing to access the test
SAMBA share configured on the test node.
Succeeds from same workstation, same account, same domain and
production Samba node.
Workstation network browse to the test share returns:
My Computer =>
Network Places =>
Entire Network =>
Microsoft Windows Network =>
Wilma =>
Samba 3.0.28a running on Dymc =>
"\\Dymc is not accessible.
You might now have permission to use this network resource.
Contact the administrator of this server to find out if you have access permissions.
The specified network name is no longer available."
$ net usersidlist
returns the following detail for the RR account:
WILMA\rr
S-1-5-21-52566010-122973185-317593308-1412
S-1-1-0
S-1-5-2
S-1-5-11
RR account exists on DYMC:: node
RR account has aligned password on Domain, production and test SAMBA nodes.
DYMC::SYS$SYSDEVICE: is DSA0:
DSa0:[000000] protection is (RWED,RWED,RE,RE)
DSA0:[DYMAX] (RWE,RWE,RWE,RE)
\\
I am successfully using JYC SAMBA 2.2.8-20050817
on a V/A 8.3 w/patches, TCPIP 5.6 ECO 3 in the same environment.
SAMBA 2.2.8 SMB.CONF file:
# Global parameters
[global]
workgroup = WILMA
netbios name = DYMA
security = DOMAIN
encrypt passwords = Yes
update encrypted = Yes
#
# JYC recommended addition
#
Password server = *
log file = /samba_log/log.%m
# deadtime = 10
#
# try reduce re-access time to share after first
# and subsequent timeout
#
# deadtime = 480
deadtime = 4320
printcap name = /sys$manager/ucx$printcap.dat
default service = default
guest account = DYMAX
create mask = 0777
print command = print %f/queue=%p/delete/passall/name="""""%s"""""
lprm command = delete/entry=%j
map archive = No
share modes = No
# max xmit = 8192 #tried with no effect on sigon problem
#
# JYC recommendation (override stat cache = yes default)
#
stat cache = no
[Q]
comment = DYMA ODS-5 data store
path = /$1$DKC200/000000
read only = No
create mask = 0775
guest ok = Yes
share modes = Yes
[R]
comment = select user data
path = /DSA1/000000
read only = No
create mask = 0775
guest ok = Yes
share modes = Yes
[S]
comment = Application shared tree and operating system
path = /dym$disk/000000
read only = No
create mask = 0775
guest ok = Yes
share modes = Yes
[printers]
comment = All Printers
path = /dym$disk/smb_scr
create mask = 0700
guest ok = Yes
printable = Yes
browseable = No
{end}
in a domain trust relationship with an existing Windows PDC emulator
and Windows XP SP3 workstations.
We don't want SAMBA to use the DEFAULT account,
but evidence suggests it is doing just that
and causing my shares access problem:
Extract from samba$smbd_startup.log
$ smbd := $samba$exe:samba$smbd.exe
$
$ SET PROC/DUMP
$ smbd
%SYSTEM-F-USERDISABLED, account is disabled
%TRACE-F-TRACEBACK, symbolic stack dump follows
image module routine line rel PC abs PC
SAMBA$SHR 0 000000000018AF18 00000000001DCF18
SAMBA$SHR 0 0000000000230224 0000000000282224
SAMBA$SHR 0 0000000000499364 00000000004EB364
SAMBA$SHR 0 0000000000499E24 00000000004EBE24
SAMBA$SHR 0 0000000000349484 000000000039B484
SAMBA$SHR 0 0000000000292974 00000000002E4974
SAMBA$SHR 0 0000000000293DA8 00000000002E5DA8
SAMBA$SHR 0 00000000002BB1B4 000000000030D1B4
SAMBA$SHR 0 000000000022E048 0000000000280048
SAMBA$SHR 0 000000000022E490 0000000000280490
SAMBA$SHR 0 000000000022FB48 0000000000281B48
SAMBA$SHR 0 000000000021CB28 000000000026EB28
SAMBA$SMBD 0 00000000000300D4 00000000000300D4
SAMBA$SMBD 0 000000000003006C 000000000003006C
SAMBA$SMBD 0 00000000000303A4 00000000000303A4
0 FFFFFFFF8037DCE4 FFFFFFFF8037DCE4
%TRACE-I-END, end of TRACE stack dump
SAMBA$SMBD job terminated at 25-MAR-2009 13:39:05.12
changing the DEFAULT account to /FLAG=NODISUSER changes the failure to:
$ SET PROC/DUMP
$ smbd
%SYSTEM-F-OPCCUS, opcode reserved to customer fault at PC=FFFFFFFF80FA1A04, PS=0
000001B
%TRACE-F-TRACEBACK, symbolic stack dump follows
image module routine line rel PC abs PC
DECC$SHR_EV56 0 0000000000109A04 FFFFFFFF80FA1A04
SAMBA$SHR 0 0000000000431594 0000000000483594
SAMBA$SHR 0 000000000022FF1C 0000000000281F1C
SAMBA$SHR 0 0000000000499364 00000000004EB364
SAMBA$SHR 0 0000000000499E24 00000000004EBE24
SAMBA$SHR 0 0000000000349484 000000000039B484
SAMBA$SHR 0 0000000000292974 00000000002E4974
SAMBA$SHR 0 0000000000293DA8 00000000002E5DA8
SAMBA$SHR 0 00000000002BB1B4 000000000030D1B4
SAMBA$SHR 0 000000000022E048 0000000000280048
SAMBA$SHR 0 000000000022E490 0000000000280490
SAMBA$SHR 0 000000000022FB48 0000000000281B48
SAMBA$SHR 0 000000000021CB28 000000000026EB28
SAMBA$SMBD 0 00000000000300D4 00000000000300D4
SAMBA$SMBD 0 000000000003006C 000000000003006C
SAMBA$SMBD 0 00000000000303A4 00000000000303A4
0 FFFFFFFF8037DCE4 FFFFFFFF8037DCE4
%TRACE-I-END, end of TRACE stack dump
SAMBA$SMBD job terminated at 25-MAR-2009 15:03:59.50
\\
Product/patch details:
CIFS 1.1 distribution
V/A 8.3 with VMS83A_ACRTL V5.0 and Update V8 applied
TCPIP 5.6 ECO 3
CIFS 1.1 / Samba 3.0.28A test SMB.CONF file:
# Global parameters
[global]
server string = Samba %v running on %h (OpenVMS)
workgroup = WILMA
netbios name = %h
security = DOMAIN
encrypt passwords = Yes
# update encrypted = Yes
name resolve order = lmhosts host wins bcast
# passdb backend = tdbsam
#
# JYC recommended addition
#
# password server = W2K3AD
Password server = *
log file = /samba$log/log.%m
printcap name = /sys$manager/ucx$printcap.dat
guest account = DYMAX
create mask = 0777
print command = print %f/queue=%p/delete/passall/name="""""%s"""""
lprm command = delete/entry=%j
map archive = No
printing = OpenVMS
log level = 10
[S]
comment = Application shared tree and operating system
path = /dym$disk/000000
read only = No
create mask = 0775
guest ok = Yes
[printers]
comment = All Printers
path = /dym$disk/smb_scr
create mask = 0700
guest ok = Yes
printable = Yes
browseable = No
{end}
I'm presuming that I have successfully created a trust relationship
between the SAMBA 3.0.28A test node (DYMC) and the PDC based on this test
on the test node:
$ @samba$root:[bin]samba$define_commands
$ net rpc testjoin
Join to 'WILMA' is OK
Workstation access from RR account is failing to access the test
SAMBA share configured on the test node.
Succeeds from same workstation, same account, same domain and
production Samba node.
Workstation network browse to the test share returns:
My Computer =>
Network Places =>
Entire Network =>
Microsoft Windows Network =>
Wilma =>
Samba 3.0.28a running on Dymc =>
"\\Dymc is not accessible.
You might now have permission to use this network resource.
Contact the administrator of this server to find out if you have access permissions.
The specified network name is no longer available."
$ net usersidlist
returns the following detail for the RR account:
WILMA\rr
S-1-5-21-52566010-122973185-317593308-1412
S-1-1-0
S-1-5-2
S-1-5-11
RR account exists on DYMC:: node
RR account has aligned password on Domain, production and test SAMBA nodes.
DYMC::SYS$SYSDEVICE: is DSA0:
DSa0:[000000] protection is (RWED,RWED,RE,RE)
DSA0:[DYMAX] (RWE,RWE,RWE,RE)
\\
I am successfully using JYC SAMBA 2.2.8-20050817
on a V/A 8.3 w/patches, TCPIP 5.6 ECO 3 in the same environment.
SAMBA 2.2.8 SMB.CONF file:
# Global parameters
[global]
workgroup = WILMA
netbios name = DYMA
security = DOMAIN
encrypt passwords = Yes
update encrypted = Yes
#
# JYC recommended addition
#
Password server = *
log file = /samba_log/log.%m
# deadtime = 10
#
# try reduce re-access time to share after first
# and subsequent timeout
#
# deadtime = 480
deadtime = 4320
printcap name = /sys$manager/ucx$printcap.dat
default service = default
guest account = DYMAX
create mask = 0777
print command = print %f/queue=%p/delete/passall/name="""""%s"""""
lprm command = delete/entry=%j
map archive = No
share modes = No
# max xmit = 8192 #tried with no effect on sigon problem
#
# JYC recommendation (override stat cache = yes default)
#
stat cache = no
[Q]
comment = DYMA ODS-5 data store
path = /$1$DKC200/000000
read only = No
create mask = 0775
guest ok = Yes
share modes = Yes
[R]
comment = select user data
path = /DSA1/000000
read only = No
create mask = 0775
guest ok = Yes
share modes = Yes
[S]
comment = Application shared tree and operating system
path = /dym$disk/000000
read only = No
create mask = 0775
guest ok = Yes
share modes = Yes
[printers]
comment = All Printers
path = /dym$disk/smb_scr
create mask = 0700
guest ok = Yes
printable = Yes
browseable = No
{end}
Solved! Go to Solution.
3 REPLIES 3
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-25-2009 02:05 PM
03-25-2009 02:05 PM
Solution
Rodman,
I can't reply to the specific problem; I've got nowhere to run CIFS 1.1 right now. However there is an ECO '1' release available. Without downloading I don't see the full release notes available but it lists:
"HP CIFS V1.1 ECO1 for OpenVMS contains additional features, bug fixes, PDC migration support and improvements compared to HP CIFS V1.1 for OpenVMS."
It might be worth looking at that before spending too much time on the original release of 1.1.
http://openvms.compaq.com/network/cifs_v1_1.html
I can't reply to the specific problem; I've got nowhere to run CIFS 1.1 right now. However there is an ECO '1' release available. Without downloading I don't see the full release notes available but it lists:
"HP CIFS V1.1 ECO1 for OpenVMS contains additional features, bug fixes, PDC migration support and improvements compared to HP CIFS V1.1 for OpenVMS."
It might be worth looking at that before spending too much time on the original release of 1.1.
http://openvms.compaq.com/network/cifs_v1_1.html
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-26-2009 08:03 AM
03-26-2009 08:03 AM
Re: CIFS 1.1 PDC/account handshake configuration?
Upgrading the same setup to CIFS 1.1 ECO 1
(Alpha version) resolved the SMBD component start failure issue!
(Alpha version) resolved the SMBD component start failure issue!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-26-2009 08:05 AM
03-26-2009 08:05 AM
Re: CIFS 1.1 PDC/account handshake configuration?
The CIFS 1.1 ECO 1 kit solved the specific problem described.
The opinions expressed above are the personal opinions of the authors, not of Hewlett Packard Enterprise. By using this site, you accept the Terms of Use and Rules of Participation.
Company
Support
Events and news
Customer resources
© Copyright 2025 Hewlett Packard Enterprise Development LP