[Search for users]
[Overall Top Noters]
[List of all Conferences]
[Download this site]
| Title: | *OLD* ALL-IN-1 (tm) Support Conference |
| Notice: | Closed - See Note 4331.l to move to IOSG::ALL-IN-1 |
| Moderator: | IOSG::PYE |
|
| Created: | Thu Jan 30 1992 |
| Last Modified: | Tue Jan 23 1996 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 4343 |
| Total number of notes: | 18308 |
3182.0. "Shared Document Not Filed in The Right Folder" by MIMS::BEKELE_D (My Opinions are MINE, MINE, all MINE!) Mon Aug 23 1993 23:36
Hello,
I appreciate if someone can shed some light on the following problem:
When users with "create", "edit" & "read" access for an advanced shared
drawer either create or edit a document the document intermittently ends
up in the "RECOVERED DOCUMENTS" with a "reserved" status and no entry is
found in the original folder when they gold/f it.
Accounting shows that there has been a privilege problem on the directory
of the shared folder. Yet, both the user and the server have access to
the directory. I had the customer enable server tracing and a status of
"55804434" (OafcDocReservedByYou) results.
Has anyone else experienced this problem?
Kind regards,
Dan
Directory & ACCESS.DAT protection:
ZUSIN9RZZ.DIR;1 [SYSNEW,AI1V2_WORK] (RWED,RWED,,E)
(DEFAULT_PROTECTION,SYSTEM:RWED,OWNER:RWED,GROUP:,WORLD:E)
ACCESS.DAT;1 [SYSNEW,AI1V2_WORK] (RWED,RWED,,)
(IDENTIFIER=[COMBANEW,NYKBJCA],ACCESS=READ+WRITE+DELETE)
(IDENTIFIER=[COMBANEW,NYKBIPE],ACCESS=READ+WRITE+DELETE)
(IDENTIFIER=[COMBANEW,NYKBGHA],ACCESS=READ+WRITE+DELETE)
(IDENTIFIER=OA$G_ZUSIMSMOJ,ACCESS=READ+WRITE+DELETE)
Security alarm (SECURITY) and security audit (SECURITY) on NNEW02, system
id: 10
Auditable event: Attempted file access
Event time: 17-AUG-1993 09:21:55.28
PID: 27804974
Username: NYKBRPI
Image name:
$10$DUS103:[ALLIN1_DEV.][AI1V2.LIB_SHARE]OA$MAIN.EXE
Object name: _$10$DUS103:[ALLIN1_DEV.AI1V2.MGR]ZUSIN9RZZ.DIR;1
Object type: file
Access requested: READ
Status: %SYSTEM-F-NOPRIV, no privilege for attempted
operation
note: User NYKBRPI has the group identifier (OA$G_ZUSIMSMOJ).
| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 3182.1 | | COL01::KLOCKE | J�rg Klocke, RPS-OIS Cologne, GY | Tue Aug 24 1993 10:45 | 15 |
| Even it is a little bit confusing, but this seems to be the right behavior.
If you create an advanced shared drawer you will be asked to enter users
or groups which will have access to that drawer. So anybody not mentioned
here will never be able to select that drawer and work with it.
On a second form you will be asked for the standard access to the documents.
These are the groups or users which will have access to any documents by
default. It makes sence if you allow anybody any access to the drawer to
give him the same rights for the standard access to the documents. Only somebody
having management privileg to all or a single document can alter the access
rights of a specific document (using the option ?? on 2. form of FC,(I am
using the german Version so I don't know the english options)).
I hope this lights up the dark a bit.
Joerg
|
| 3182.2 | Directory in the chain? | IOSG::MAURICE | Differently hirsute | Tue Aug 24 1993 11:31 | 10 |
| Hi,
From the Manager's account go to Drawer Management, select the drawer
and type R to read it. Any errors shown? The thing to check is
whether there is a directory in the chain leading to the drawer
directory that is causing denial of access.
Cheers
Stuart
|
| 3182.3 | Why the inconsistency? | MIMS::BEKELE_D | My Opinions are MINE, MINE, all MINE! | Tue Aug 24 1993 16:17 | 29 |
| Re: .1
> ...So anybody not mentioned here will never be able to select that
> drawer and work with it.
I don't follow... If you are suggesting that the problem was encountered
by someone who is not given access to the drawer then you may have
missed the last line in .0. (the user has access to the drawer via a
group identifier). The users are also given the same level of access
at the document level.
Re: .2
Stuart, I have checked and double checked access to the directory chain.
Also, the "Manager" owns these directories and I have the customer
do a "read" on the drawer at your suggestion and encounterred no error.
What I do not understand is why it only happens INTERMITTENTLY?
The same user could refile it out of her "RECOVERED DOCUMENTS" folder
and into the "advanced shared drawer" folder, edit and Gold/F it
and there won't be any problem until the next random incident.
BTW, this problem is not restricted to any particular drawer or user.
I am told, however, one drawer which is heavily accessed shows up in the
complaint list more often than other drawers that are not accessed as
frequently.
Thanks!
Dan
|
| 3182.4 | | IOSG::MAURICE | Differently hirsute | Fri Aug 27 1993 11:30 | 19 |
| Hi,
Intermittent problems are always hard. Here are some questions which I
hope will give us a clue:
1. Which editor is the user using?
2. Is Patch V3.0-1 installed?
3. Any customisations on the system?
The actual error is saying that a user is trying to READ the directory
file, but in fact the user only has EXECUTE access to the directory.
This implies the code the user is running is trying to do a directory
listing, but this should not be happening!
Cheers
Stuart
|
| 3182.5 | Some answers | MIMS::BEKELE_D | My Opinions are MINE, MINE, all MINE! | Thu Sep 02 1993 23:10 | 13 |
| Staurt,
They use WPSPLUS, have minimal customization (a few menu forms)
and they have applied the patch. As far as a "READ" access
failure on the shared directory goes, the user reported "no
problem" eventhough a similar ALARM error was logged this morning.
I suspect the error may be generated when the user tries to do an
"Index?" But, I have yet to establish a connection between that
problem (which, as I understand, should be done by OA$MAIN rather
than the server) with the problem of documents ending up in
"RECOVERED DOCUMENTS" folder (which is server related failure).
Dan
|