You don't have permission to read

[Guest]

I have been asked to modify a database that has not been touched for over a
year. Using Admin as my login I get the above message. I get the same error
message when trying to open any object. The owner of the database and each of
the objects is shown as <unknown>. I have also tried to export objects but
again get the same error message. Any suggestions. Thanks - Len

 

[Joan Wild]

When you say 'using Admin as my login', are you referring to an Access
username, or a Windows username. In other words, do you get a
username/password prompt while opening the mdb?

 

[Guest]

I am using a desktop shortcut as follows:

"C:\Program Files\Microsoft Office\Office10\MSACCESS.EXE"
"s:\external\external.mdb" /wrkgrp "s:\external\soni.mdw"

There are no problems in running the system using either Admin or another
user login that was set up. The problem is changing objects. I cannot change
any objects - get the message "You don't have permission to read - object
name". I then checked the owners of the database itself and the objects -
showed <unknown>. Tried to specifically change the permissions of an object
and again got a similar message - don't have permission to read. Also
compacted and repaired with no problem thinking that might fix problem.

Thanks - Len

 

[Joan Wild]

OK, then you are opening the secured database using a secure workgroup. In
a secured mdb, generally the Admin user does not have permission to do
anything.

You should log in using a username that does have permissions.

That said, the fact that the owner shows as unknown, indicates that you are
not using the workgroup file that was used to secure it with. You need to
find that workgroup file, if logging in as another user doesn't do it.
There has to be at least one user that is a member of the Admins Group - can
you log in as that user?

 

[Tom Stoddard]

Joan,

I assume that if owner is 'unknown', that means that the owner does not
exist in the workgroup file currently being used. Could this result from the
owner of the database objects being deleted from the workgroup? If so, then
Len might be using the original workgroup file. Is this possible?

I don't know if it will make a difference in this case but I'm curious.

Thanks!

 

[Joan Wild]

Joan,

I assume that if owner is 'unknown', that means that the owner does
not exist in the workgroup file currently being used.
True.

Could this
result from the owner of the database objects being deleted from the
workgroup?

It's possible, but usually the owner is a member of the Admins Group, and
often the only member. Since the Admins Group must have at least one
member, one wouldn't be able to delete it. However, there wouldn't be a
problem if the Admins Group had other members.

If so, then Len might be using the original workgroup

file. Is this possible?

What do you mean 'original' - system.mdw? But the command line switch
indicates that he's using soni.mdw, so not sure what you mean by original.

It's also possible that soni.mdw is a production mdw, and not the one used
to secure the mdb during development.

 

[Guest]

Joan and Tom, Thanks for your suggestions but the database seems to be stuck.
I have checked the Admins group and their are 3 ids including Admin - none of
which work. I have tried saved mdw files with the same result.
Is there another way to get the objects opened and/or copied to create a new
database and then create a new security file.
Any additional suggestions would be appreciated.
Len

 

[Joan Wild]

Try searching at Google.

 

[Tom Stoddard]

Joan and Tom, Thanks for your suggestions but the database seems to be
stuck.
I have checked the Admins group and their are 3 ids including Admin - none
of
which work. I have tried saved mdw files with the same result.
Is there another way to get the objects opened and/or copied to create a
new
database and then create a new security file.
Any additional suggestions would be appreciated.
Len

Len,

You haven't said whether or not the 'Admins' group has permission to view or
modify the design of any objects. It's possible to be in the Admins group
and not have those permissions. However, if a user is in the Admins group
then they would have the ability to grant those permissions.

Try logging in to your database as one of the users who is in the Admins
group and then go into Tools - Security - User and Group Permissions. Select
the user that you are logged in as and select an object that you want to
have permission to view in design view or edit the design of. Check the
"Read Design" and "Modify Design" check boxes and click ok to exit the form.
Then try to open the object you just granted permissions for in design view
and see what happens.

Good Luck!

 

[TC]

You haven't said whether or not the 'Admins' group has permission to view or
modify the design of any objects. It's possible to be in the Admins group
and not have those permissions.

Um, are you sure? Memembers of the Admins group should always have
those permissions, by virtue of their membership of that group - even
when their individual (user level) permissions have been revoked
explicitly. That /group/ has the permissions in question, so the
members of that group will all have those permissions, due to the
additive nature of group & user permissions.

Of course, it has to be the Admins group /of the workgroup file which
was in effect when the database was first created/. Members of the
Admins group of /other/ workgroup files, will not have any
administrative permissions to the database, unless that other workgroup
file was created with the same company, organization name & workgroup
ID (WID).

HTH,
TC

 

[Tom Stoddard]

Um, are you sure? Memembers of the Admins group should always have
those permissions, by virtue of their membership of that group - even
when their individual (user level) permissions have been revoked
explicitly. That /group/ has the permissions in question, so the
members of that group will all have those permissions, due to the
additive nature of group & user permissions.

The database I'm looking at works the way I described it. I am able to go
into User and Group Permissions and add or take away permissions from the
/group/ Admins. If I take away the Read Design and/or Modify Design
permissions for that group and I log out and log back in as a user who has
membership in the /group/ Admins but is not the owner of the object in
question, I am no longer able to open that object in design view.

I am using the workgroup file which was in effect when the database was
first created. I'm using Access 2003.

Please try it and tell me if I'm hallucinating.

Thanks

 

[Joan Wild]

The database I'm looking at works the way I described it. I am able
to go into User and Group Permissions and add or take away
permissions from the /group/ Admins. If I take away the Read Design
and/or Modify Design permissions for that group and I log out and log
back in as a user who has membership in the /group/ Admins but is not
the owner of the object in question, I am no longer able to open that
object in design view.

But as a member of the Admins Group, you can modify permissions back. One
doesn't have to be the owner to change the permissions.

 

[Tom Stoddard]

But as a member of the Admins Group, you can modify permissions back. One
doesn't have to be the owner to change the permissions.

That's precisely my point. Len's posts state that he can log in and use the
database but he can't modify any objects. All that I'm trying to point out
is that just because he's logged in as a user who is a member of the Admins
group doesn't mean that he automatically has permission to modify objects.
Len never stated whether or not the "Admins Group" has the necessary
permissions required to modify the objects he's trying to modify. It is
possible that the Admins Group does not have those permissions. No one
bothered to ask him that question.

TC seems to think that any user who is a member of the Admins Group would
automatically have permission to modify any object. In a sense, that's true
because of what Joan is saying which is that any member of the Admins Group
has the ability to grant themselves that permission. I believe I stated that
in one of my earlier posts. My point is that just because the user has the
ability to grant those permissions to himself, doesn't mean that he has
granted those permissions. In that case then he won't have those permissions
even though he is a member of the Admins Group.

Sorry if I'm confusing this issue. I'm just trying to help Len do what he's
trying to do.

 

[Joan Wild]

The fact that objects show the owner as 'unknown' tells us that he's not
using the workgroup file that was used to secure it. So therefore the
Admins Group is not the same.

 

[Guest]

Thanks for all your help. I have tried to change permissions as Admin and as
a user who is a member of the Admins group. Same error message. If I am fact
not using the workgroup file that was used to secure it originally - then
what? - Len

 

[Joan Wild]

Locate it on a backup, or recreate it using the same name/WID as the
original.

 

[TC]

Ok, we're all correct

- I am correct in stating that a user has the permissions of the
group(s) to which he belongs, even if those permissions have been
revoked at the user level. But that's not really relevant to what you
were talking about.

- You are correct in saying the the Admins group might /not/ have the
normal permissions, if those permissions have been temporarily revoked
from that group;

- Joan is right in saying that any member of the Admins group can
always re-assign the lost permissions.

When talking about permissions, I normally say: "blah blah has (or can
regain) the permission to blah blah" - but I forgot the phrase in the
middle, this time!

Cheers,
TC

 

[Guest]

Although I'm answering this much later than all the discussion, I wanted to
let everyone know that the discussion process helped me solve a similar
problem. We were attempting to relocate a database on a shared file, and in
the process, a new workgroup file was created or copied without our
knowledge. When I read through this discussion and saw some discussion about
the "*.mdw" files, I did a search in our system for all files with that
extension. I found the original file, "joined" the group, and was then able
to access the components in the database.

Thanks for all the help!

 

[TC]

Well done! Long live usenet.

TC [MVP Access]