| 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 |
My customer is having intermittent problems accessing files in
a group common share.
The situation is:
This customer uses Alpha 4100s running OVMS V7.1 with
PWRK V5.0E and approximately 100 DEC Intel 200 MHz Pentiums
running WindowsNT 4.0. Their organization is broken up
into about 15 departments that must read/write share files
in each group and read only share file between groups.
The customer has set up a number of 'common' shares that
users connect to via a
NET USE N: \\SERVER\SHARE passwd /USER:group
command. The top level directory is permitted so that
all groups have full access RWCXDAP. There are then
subdirectories for each group. Each groups subdirectory
is permitted so that the 'owning' group has RWCXDAP
permission and all other groups have RX permission only.
This allows each group to RW there own subdirectory tree,
while other groups can read the files in that group
subdirectory. V4 compatibility is turned off on this PW server.
The group name is not the same as the user name that was used
to log into their NT workstation with. Several group members
will user the same group name when connecting to the share via
the NET USE command.
The problem is that intermittently after a group member
connects to this share they may or may not get full RW access to
their subdirectory. Disconnecting are reconnecting may
then give them the full access. There have been occasions
where a group member may have been happily reading and writing
files into thier group's subdirectory tree and out of the
clear blue he will start getting 'access denied' error while
trying to write. He must then disconnect and reconnect to
the problem share. We have even seen where a user will write
a file into a subdirectory and that file will 'disappear'.
Looking into the directory from VMS we see the file but the
'missing' file has no ACL attached and is invisible to
the WinNT system.
Anyone have any ideas on what is happening here?
Any suggestions on how to fix this or make this more stable.
The customer is very frustrated.
Thanks in advance,
Tom
303-341-3045
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 4215.1 | VMSNET::P_NUNEZ | Wed Mar 19 1997 13:59 | 26 | ||
Tom,
Look around this conference in recent notes and you'll see issues
regarding multiple sessions from NT clients and issues around file
access exactly as you describe. If you look at these clients sessions
using $ NET SESSIONS, you'll likely see one is connected as GUEST
(which is why they suddenly get the access denied error).
Recent notes in the JAMIN::PATHWORKS32 conference are discussing it as
well. I think there's a workaround (ie, if one's workgroup name is NOT
the same as the domain name)...
For your customer, can't he get away from using /USER:<group> when
connecting to the shares? He should just use LANMAN user groups (1 per
dept) and then make the appropriate users members of that group. Then
assign that group the appropriate permissions to the appropriate
directories w/i the shares.
Then the user logs on to the domain as a normal user would and when the
net use command is issued that user's credentials are passed for ALL
connections to any server in the domain. But I'm not sure this is
enough to avoid the multiple session issue.
HTH,
Paul
| |||||
| 4215.2 | Seen and reported | VMSNET::ALLERTON | Episode d'Azur | Fri Mar 21 1997 11:15 | 10 |
Tom,
There have been a number of cld's generated recently for 5.0e and
"phantom" (blank) or guest sessions (tied to NT 4.0 computernames) that
displace an initially established user context session for a given
computer...$ net sessions command will bear this out (a \\computername
listed with a GUEST or (BLANK) user session context only).
Steve
| |||||
| 4215.3 | CPEEDY::FLEURY | Fri Mar 21 1997 12:37 | 8 | ||
Some of the problems reported here are fixed in V50E-ECO1. We have
since found another instance where this symptom can appear. We believe
that we have a fix for this too. We will be testing this shortly.
Note: The final complete fix will be a patch to ECO1.
Dan
| |||||
| 4215.4 | Waiting for ECO1 | CUJO::TOBIASSEN | Ride a Bicycle for Fun & Fitness | Mon Mar 24 1997 11:28 | 4 |
Thank you for the replies. We will wait patiently for ECO1.
Tom
| |||||
| 4215.5 | TKTVFS::ANAZAWA_H | NO SKIN OFF MY ASS | Sat Mar 29 1997 23:41 | 10 | |
hi, Dan > Note: The final complete fix will be a patch to ECO1. really? Yesterday, my customer version up to V5.0E-eco1 from V5.0D-eco3. greate "PHANTOM" session still appear! All user can't access file from client (WNT V3.51). /ana | |||||
| 4215.6 | Fix is a PATCH to ECO1. | CPEEDY::FLEURY | Mon Mar 31 1997 08:57 | 6 | |
re: .5
Please re-read my original reply. I stated that the final fix is in a
PATCH to ECO1. This patch is now available via the IPMT process.
Dan
| |||||
| 4215.7 | sorry... | TKTVFS::ANAZAWA_H | NO SKIN OFF MY ASS | Wed Apr 02 1997 12:01 | 5 |
> -< Fix is a PATCH to ECO1. >-
I misunderstood, try to get a new PWRK$LMSRV.EXE .
Thank you.
/ana
| |||||