| Title: | Kit: Note 4229; Please use NOTED::PWDOSWIN5 for V4.x server |
| Notice: | Kit: Note 4229; Please use NOTED::PWDOSWIN5 for V4.x server |
| Moderator: | CPEEDY::KENNEDY |
| Created: | Fri Dec 18 1992 |
| Last Modified: | Fri Jun 06 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 4319 |
| Total number of notes: | 18478 |
Here's another odd problem, though we're not sure it started with
v5.0E.
Customer has a volume set named dms$disk:
$ sh dev dms$disk:
Device Device Error Volume Free
Trans Mnt
Name Status Count Label Blocks
Count Cnt
DSSI12$DIA220: Mounted 0 DSK11 87882
1 2
DSSI12$DIA230: Mounted 0 DSK12 81087
1 2
DSSI12$DIA240: Mounted 0 DSK24 8124849
1 2
DSSI13$DIA340: Mounted 0 DSK25 8125506
1 2
DSSI14$DIA440: Mounted 0 DSK19 81981
1 2
$4$DIA5: (DSSI35) Mounted 0 DMSVOL4 75000
1 2
He connects to hidden share DSK11$ (the autoshare for the root volume
of the set) as an ADMIN-privileged user. He does DIR from DOS. The
listing isn't consistent with what he sees if he does $ DIR
DMS$DISK:[000000] nor DSSI12$DIA220:[000000] nor DISK$DSK11:[000000] -
all of which are valid ways to reference the volume set.
So I had him create a file on the drive connected to DSK11$. He called
it AA.AA. I then looked at [000000] on each of the member volumes and
found the directory he's connected to is $4$DIA5:[000000]. $4$dia5 is
the last volume in the set. Why is this happening?
$ NET SHARE DSK11$ returns:
$ net share dsk11$
Sharename DSK11$
Path DSK11:
Remark ODS-2 volume DSK11:
Permission RWCXDAP
Max. users No limit
Users THAMSC
The command completed successfully.
$ sh log *dsk11*
(LNM$PROCESS_TABLE)
(LNM$JOB_8A76C740)
(LNM$GROUP_000001)
(LNM$SYSTEM_TABLE)
"DISK$DSK11" = "DSSI12$DIA220:"
(DECW$LOGICAL_NAMES)
$ SEARCH PWRK$LANMAN:LANMAN.INI AUTO
autoshare=DSSI14$DIA430=D18,$3$DIA3=U4,DSSI13$DIA320=D14,DSSI14$DIA410=D16,
DSSI13$DIA330=D15,$3$DIA1=U2,$3$DIA0=U1,$3$DIA4=U5,$1$DIA0=S0
noautoshare = dad, _dfs
$ lmshare -l dsk11$
0> DSK11$:d:ODS-2 volume
DSK11::rwcxdap:UNLIMITED:_DSSI12$DIA220::::0::0:0:0::::
We also had a ton of trouble getting the server to recognize
directories in [000000] on the root volume. For example, they had a
share pointing to a dms$disk:[dms_drawings]. After the upgrade to
v5.0E, users could connect to it, but couldn't see any files in the
root of the share (in [dms_drawings]). Had a user with ADMIN
privileges connect to it and even they couldn't see anything (lanman
only security mode). However, users (priv'd or otherwise) could CD
<subdir> (as long as they knew the directory was there) and it would
succeed. Then they could do DIR of subdir and see the files. Believe
me, I checked everything I could think of, plus even users with ADMIN
priv were having the problem.
Also, I couldn't add a share that pointed to the [dms_drawings]
directory nor to two other directories I had created on
DMS$DISK:[000000]. The net sharecommand returned the error NET2116:
The device or directory does not exist.
So to work-around the problem I did:
$ create/dir dms$disk:[dummy]
$ net share dms_drg /delete
$ rename dms$disk:[000000]dms_drawings.dir dms$disk:[dummy]
$ net share dms_drg=dms$disk:[dummy.dms_drawings]
But note that I still couldn't do $ NET SHARE name=DMS$DISK:[DUMMY] -
I'd get NET2116. However, I could simply hit my up arrow to recall the
command, make it $ NET SHARE name=DMS$DISK:[DUMMY.DMS_DRAWINGS] and it
worked w/o error.?!?
We had to do the same with PCCOMMON share on another volume set. Yet
on a third volume set, they're not having any problems with a share
directory off [000000].
I went to lunch, came back, dialed-in, and tried to reproduce the
problem creating a share - I couldn't - the problem was gone. I could
add shares pointing to DSM$DISK:[somedir] w/o errors. Neither the system
nor PATHWORKS had been restarted.
Comments? Any body else out there with volume sets and v5.0E that can
attempt some of the things above?
paul
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 4159.1 | Position on Volume Sets? | VMSNET::P_NUNEZ | Wed Feb 19 1997 16:17 | 10 | |
Well, my testing with a volume set has turned up some problems very
similar to what was seen at the customer site and is reproducible.
However, so far it involves using the device reference for a device
which is not the root volume in the set. So...
What's the official position from engineering on support for bound
volume sets, especially in the area of autoshare/noautoshare?
Paul
| |||||
| 4159.2 | Direct access to non-root drives is illegal. | CPEEDY::FLEURY | Thu Feb 20 1997 08:33 | 8 | |
Paul,
Please provide additional information. Direct access to individual
volumes of a volume-set is not supported by OpenVMS and is a violation
of the "spirit" of volume-sets. All access to the drives should be
through the volume-set name or logical (ie the root volume).
Dan
| |||||
| 4159.3 | What I know so far... | VMSNET::P_NUNEZ | Thu Feb 20 1997 09:27 | 55 | |
Dan,
I know you're not "suppose to" access the volume set drives by anything
other than the volume set name or the name of the root volume in the
set, but because we don't advise customers to NOAUTOSHARE non-root
volumes, they end up with autoshares for all physical volumes w/i the
set. Thus, we allow customer's to get themselves into trouble.
But what's worse is I'm able to duplicate a situation whereby adding a
single share whose path includes a non-root volume in a volume set will
subsequently make adding ANY share to the volume set fail (even when
using the volume set name or root volume name). The error returned is
NET2116: The device or directory does not exist. If I connect (PWV60
or native NT client) to the autoshare of _THE ROOT VOLUME_ and do DIR,
I see the MFD of the last volume in the set (not the MFD of the volume
set).
If I then remove all shares that have the non-root volume in their path
(except the autoshares for the non-root volumes) and restart PATHWORKS,
I can now add shares to the volume set and from DOS (and NT) client I
see the MFD of the volume set.
Another glitch is if I connect to a share that has the non-root volume
in it's path (connecting works fine), I can do wildcard directory
operations w/o problem. But if I try to list a file explicitly (ie,
DIR T.TST), I get File not found (yet, DIR T.TS*, DIR T.T*, DIR T*.*,
etc, all work). Also, if I try to create a file on this share as an
ADMIN-priv'd user, I get a Path not found error. But this only happens
in the root directory off the MFD - I can do non-wildcard directory
operations for files in the MFD - totally weird.
To make matters worse, do all this in a cluster and you'll see
different behavior on the other member. That is, with the problems
evident on one node in the cluster, I started PATHWORKS on the other
member. I could connect into that cluster member to the autoshare for
the volume set and see the MFD of the volume set, while at the same
time be connected thru the other member to the same autoshare and see
the MFD of the last volume in the set. And I can add a share that
points to the volume set on the one cluster member but not the other
(because it's looking at the MFD of the last volume in the set and
the directory I specified doesn't exist in the MFD of the last volume,
but does exist on the volume set MFD).
I'm going to be out the rest of today, but plan on doing more testing
Friday and beyond until I can further isolate the cause. But,
obviously, something's amiss, no?
I do now believe this problem has been evident since day one. I've got
a customer seeing some of this behavior on a v5.0C ECO3 server and
another who ran into after upgrading from v5.0C ECO3 to v5.0E (he had
to remove and re-add a bunch of shares due to the autoshare hole that
was closed in v5.0D).
Paul
| |||||
| 4159.4 | PWRK$LMSRV startup code is suspect | VMSNET::P_NUNEZ | Mon Feb 24 1997 10:48 | 69 | |
As I noted in .3, the problem with volume sets when you don't
NOAUTOSHARE non-root volumes occurs after adding a share using a device
reference for a non-root volume (but using a directory spec that IS
only accessible from the root volume/volume set name). But you also
have to stop and restart PATHWORKS for the problem to be evident.
So this points the finger at the code in lmsrv that verifies the path
to each share.
An example:
Volume set logical name DISK$PWRKS, with root volume of $1$DUA6: which
has a volume label of USER6 and a logical name of DISK$USER6:
Disk $1$DUA8:, label USER8:, logical name DISK$USER8: is rvn2
Disk $1$DUA7:, label USER7:, logical name DISK$USER7: is rvn3
The rules for volume sets say you can use the volume set logical name
or any valid reference for the root volume in the set ($1$DUA6:).
$ CREATE/DIRECTORY DISK$USER6:[RIGHT]
$ CREATE/DIRECTORY DISK$USER7:[WRONG7]
$ CREATE/DIRECTORY DISK$USER8:[WRONG8]
If you do $ DIR DISK$PWRKS:[000000], only RIGHT.DIR is seen.
$ PWSTART
You now have autoshares USER6$, USER7$, and USER8$.
$ NET SHARE OK=DISK$PWRKS:[RIGHT]
ok was shared successfully.
No problem; adds the share and $ NET SHARE OK shows USER6:[RIGHT] as
the Path.
$ NET SHARE BAD=DISK$USER8:[RIGHT]
bad was shared successfully.
Adds the share w/o error; but $ NET SHARE BAD shows USER8:[RIGHT] as
the Path.
$ PWSTART
$ NET SHARE OK2=DISK$PWRKS:[RIGHT]
NET2116: The device or directory does not exist.
$ NET SHARE OK2=DISK$USER6:[RIGHT]
NET2116: The device or directory does not exist.
$ NET SHARE OK2=$1$DUA6:[RIGHT]
NET2116: The device or directory does not exist.
But I can now add a share pointing to a directory which exists only on
$1$DUA8: (the non-root volume I pointed the BAD share to):
$ NET SHARE ON8=USER8:[WRONG8]
on8 was shared successfully.
To fix it you have to remove all shares pointing to the non-root
volumes and then restart PATHWORKS...QAR forthcoming.
Paul
| |||||
| 4159.5 | QAR #396 | VMSNET::P_NUNEZ | Mon Feb 24 1997 15:13 | 1 | |
| 4159.6 | CPEEDY::FLEURY | Mon Feb 24 1997 15:47 | 6 | ||
RE: all
I'll be looking into this. I suspect that we'll insert some "don't do
that" messaging, but I'll let you know...
Dan
| |||||
| 4159.7 | We're pushing customer's into a corner | VMSNET::P_NUNEZ | Wed Feb 26 1997 10:33 | 15 | |
Is anything being done to lift the 128 character restriction on the
autoshare/noautoshare lines?
If not, what's a customer to do who is faced with, following our
recommendations, having more drives than can fit w/i this restriction?
Rarely is the wildcarding capability of much use...
As for noautosharing a device, if one simply removes the autoshare
after the server starts, will this have entirely the same affect as
having the device listed in the noautoshare line? I realize a
subsequent $ NET SHARE /SYNC would require the autoshare be removed
again, but...
Paul
| |||||