| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 3075.1 | Mini checklist | IOSG::MAURICE | Differently hirsute | Tue Jul 27 1993 18:01 | 20 |
| Re .0
Some things to check:
1. As the ALL-IN-1 Manager type SM MFC MD (manage drawers) and select
the drawer. Type R to read it and check that there are no errors
on the listing.
2. Do the other users who have been given CONTROL access to this drawer
have any problems?
3. Can the user edit documents in the drawer?
4. Can the user read documents in the drawer?
5. Is the drawer an ADVANCED SHARED drawer or REGULAR SHARED?
Cheers
Stuart
|
| 3075.2 | Checklist results | KIRKTN::GMURRAY | Have Mercy I Cry City ! | Wed Jul 28 1993 14:55 | 51 |
|
Hi Stuart,
Thanks for the reply. I've checked the 5 points and come up with the
following answers:
1. SM MFC MD gives no apparent errors:
Date: 28-Jul-1993 File Cabinet Drawer Full Report Page: 1
===============================
Drawer MASALA::"[ESG]MAIN"
System MASALA::
Owner ESG
Drawer name MAIN
Description
Directory DISK$ALLIN1_SD1:[SHARED_DRAWERS.ESG]
You have CONTROL access to the drawer
Drawer is shared with other users
Drawer is located on this system
Drawer type is REGULAR SHARED
List of users who may access the drawer
=======================================
Shared Delete/
User or Group VMS Acct Read Create Edit Refile Control
AMSG Y Y Y Y Y Y
ROSS.JOHN Y Y Y Y Y
FOX.RON Y Y Y Y Y
HARRIS.BRUCE Y Y Y Y Y
HUTCHEON.GRAEME Y Y Y Y Y
CRAWFORD.MARTIN Y Y Y Y Y
2. Other CONTROL users do NOT have any problems Creating/Editing in the
drawer.
3. The user is unable to Edit - getting:
%OAFC-I-NOACCESS, Insufficient privilege for requested operation
4. However, he can Read documents in the drawer.
5. It's a REGULAR SHARED drawer.
All this points to a problem with the users' account. Disk quota seems
OK (approx 6K free blocks).
Could it be something in his profile ?
Cheers,
Gil
|
| 3075.3 | More questions | IOSG::MAURICE | Differently hirsute | Wed Jul 28 1993 15:34 | 11 |
| Hi,
> Could it be something in his profile ?
Yes. The VMSUSR and DIRECT fields have to be correct. Does the user login
to ALL-IN-1 by just typing $allin1, or does the user specify a /USER or
/DIRECT parameter? Has the profile been customised?
Cheers
Stuart
|
| 3075.4 | Hmmm... | KIRKTN::GMURRAY | Have Mercy I Cry City ! | Thu Jul 29 1993 11:30 | 49 |
|
Hi,
He invokes ALL-IN-1 with /USER=fox.ron
DIRECT and VMSUSR look normal:
DIRECT=INFORMATION_SERVICES:[RFOX.ALLIN1]
VMSUSR=RFOX
The profile itself hasn't been customised. However, I noticed that he had a
(now redundant) form library in his FRMLIB, and removed it.
Interestingly, he still can't Edit or Create, but on Create the error
has changed to:
%OAFC-I-NOACCESS, Insufficient privilege for requested operation
%OA-I-LASTLINE, The document cannot be accessed for editing
%OA-I-LASTLINE, No document was created
Privs/protection ?
The protection on the shared drawer files looks OK I think:
DISK$ALLIN1_SD1:[SHARED_DRAWERS]ESG.DIR;1
ESG.DIR;1 [SYSTEM] (RWE,RWE,E,E)
DISK$ALLIN1_SD1:[SHARED_DRAWERS.ESG]ACCESS.DAT;1
ACCESS.DAT;1 [SYSTEM] (RWED,RWED,,)
(IDENTIFIER=[ALLIN1],OPTIONS=HIDDEN,ACCESS=READ+WRITE+DELETE+CONTROL)
(IDENTIFIER=[MANU,JROSS],ACCESS=READ+WRITE+DELETE+CONTROL)
(IDENTIFIER=[INFORM,RFOX],ACCESS=READ+WRITE+DELETE+CONTROL)
(IDENTIFIER=[INFORM,BHARRIS],ACCESS=READ+WRITE+DELETE+CONTROL)
(IDENTIFIER=[INFORM,GHUTCHEON],ACCESS=READ+WRITE+DELETE+CONTROL)
(IDENTIFIER=[INFORM,MCRAWFORD],ACCESS=READ+WRITE+DELETE+CONTROL)
Confused,
Gil
|
| 3075.5 | Next check | IOSG::MAURICE | Differently hirsute | Thu Jul 29 1993 12:34 | 14 |
| Hi,
Everything looks OK there. For some reason ALL-IN-1 and VMS think the
user has proper access to the drawer, but the File Cabinet Server
doesn't.
In the user's own drawer can the user successfully use the RSV
(reserve) and URV (unreserve) commands on his own documents? This will
tell us if the user has a general problem using the FCS, or whether it
is particular to the drawer.
Cheers
Stuart
|
| 3075.6 | Need to know who FCS thinks you are... | CHRLIE::HUSTON | | Thu Jul 29 1993 17:29 | 20 |
|
Turn on FCS logging and see what the FCS thinks the username is, my
guess is that it does not understand something about the /user.
Remember that all authentication is via VMS username,
my guess is that the connect to the FCS is not passing something
to tell it that this guy is not acting as himself, but is acting
as someone else.
Stuart,
Helmut once told me that when the connect is made to the FCS the
username and password passed are the local username, if the person
is doing a /user=x, then if there is a differenet VMS name associated
with this, it would cause problems with the above, can you find out
what happens when a connect is done from INDEX$ when the user
came in via /user=x?
--Bob
|
| 3075.7 | Errors show up in OAFC$SERVER.LOG - relevant ? | PAKORA::GMURRAY | Have Mercy I Cry City ! | Mon Aug 02 1993 12:02 | 30 |
|
Hi Stuart, Bob,
Sorry for the delay....
RE .5 Bang on target ! When the user tries to RSV one of his own MAIN
documents, he gets:
%OAFC-I-NOACCESS, Insufficient privilege for requested operation
%OA-I-LASTLINE, The document could not be reserved
RE .6 I checked OAFC$SERVER.LOG (correct ?) and found these two
errors:
28-JUL-1993 09:09:35.66 Server: MASALA::"73=" Error:
%OAFC-E-INTERR, Internal error in File Cabinet Server Message: CsiOpenDrawer;
DOCDB file/dev id does not match IUID in partition, continuing
29-JUL-1993 11:44:06.65 Server: MASALA::"73=" Error:
%OAFC-E-INTERR, Internal error in File Cabinet Server Message: CsiOpenDrawer;
DOCDB file/dev id does not match IUID in partition, continuing
Should we assume that these errors belong to the user, and if so, what
do they mean ?
Cheers,
Gil
|
| 3075.8 | Errors fixed on the fly | CHRLIE::HUSTON | | Mon Aug 02 1993 16:36 | 7 |
|
Nope, those errors will be fixed up on the fly by the FCS.
They should go away.
--Bob
|
| 3075.9 | Trace results | PAKORA::GMURRAY | Have Mercy I Cry City ! | Mon Aug 02 1993 17:51 | 64 |
| Hi Bob,
The user has reported the same problems on a different drawer now.
I switched tracing on, and attempted to Create in the original drawer,
from his account. The trace log proved tricky to look at as it was in
Stream_LF format, but after conversion I got the following (not too
revealing I'm afraid):
11 7919856
Task Start 2-AUG-1993 16:17:54.51 OafcOpenCabinetW
11 7919856PAKORA.FOX.RON
Connection Rcv'd 2-AUG-1993 16:17:54.58 OafcOpenCabinetW
PAKORA
11 7919856PAKORA.FOX.RON
Connection Rejected 2-AUG-1993 16:18:00.22 OafcOpenCabinetW
RFOX
11 7919856PAKORA.FOX.RON
Task Complete 2-AUG-1993 16:18:00.39 OafcOpenCabinetW
55804138RFOX
7919856PAKORA.FOX.RON
Disconnect Done 2-AUG-1993 16:18:00.87
11 7936768
Task Start 2-AUG-1993 16:18:00.43 OafcOpenCabinetW
11 7936768THERAJ.FOX.RON
Connection Rcv'd 2-AUG-1993 16:18:01.61 OafcOpenCabinetW
PAKORA
11 7936768THERAJ.FOX.RON
Connection Rejected 2-AUG-1993 16:18:05.13 OafcOpenCabinetW
RFOX
11 7936768THERAJ.FOX.RON
Task Complete 2-AUG-1993 16:18:05.18 OafcOpenCabinetW
55804138RFOX
7936768THERAJ.FOX.RON
Disconnect Done 2-AUG-1993 16:18:05.24
Am I right in thinking that this doesn't really tell us much ?
Cheers,
Gil
P.S. Am I missing an easy way to look at the Trace log ?
|
| 3075.10 | Easy to read trace file... | CHRLIE::HUSTON | | Mon Aug 02 1993 18:08 | 16 |
|
> P.S. Am I missing an easy way to look at the Trace log ?
Yup, there is a trace formatter, sys$system:oafc$print_trace_file.exe
(or something close to that), set it as a VMS symbol, then pass
the trace file in as P1, it will nicely format and dump this to the
screen for you, or you could re-define sys$output to a file and have
the output go there.
If one drawer is showing it, chances are mulitple drawers will show it.
anything that can change the physical location of a drawer (ie the
file id for instance) like a fc reorg will cause this. As I said the
FCS fixes it on the fly.
--Bob
|
| 3075.11 | How long to self-correct ? | KIRKTN::GMURRAY | Have Mercy I Cry City ! | Tue Aug 03 1993 12:38 | 19 |
|
Thanks for the pointer to the trace log formatter - that'll make life a
lot easier !
You're right. Every shared drawer the user tries to Create in is now
failing - same error.
You say that errors like this are fixed "on the fly" by the FCS - what
worries me is how long it's taking.... the user tells me that he first
noticed the problem some 3 weeks ago !
Is there anything I can do to speed up the process - maybe fool the FCS
into fixing it faster ?
Cheers,
Gil
|
| 3075.12 | Fixes as it finds it | CHRLIE::HUSTON | | Tue Aug 03 1993 15:05 | 12 |
|
the FCS should be fixing it as it discovers it.
There is also a system management option to fix it (I think), if not,
I can tell you how to write up a quick and dirty C program to do it,
real easy, but I know there is a way to fix it besides the FCS.
Sounds like there may be another problem here as well since this
doesn't seem to go away.
--Bob
|
| 3075.13 | CASE resolved and closed. | WAYOUT::TALBOT | Trevor Talbot | Fri Aug 06 1993 13:00 | 19 |
| Hi,
There was another problem here!
By doing the following commands the protection problem
can be highlighted easily without wading through yards of
trace etc...
1)set audit/alarm/enable=file=fail
2)reply/enable
3)set term/broad
4)get user to perform tricks..
5)fix file protection from output on screen
In this case the users directory lacked system access for
RWE, once corrected the user had no further problems.
-Trev
|