No permission to use file.mdb problem

[Brian Morris]

Hello,
I have an app that has a FE.mde and Temp.mdb on the user's local drive and
BE.mdb on the fileserver.
Temp.mdb and BE.mdb are linked to FE.mde
Temp.mdb is used to store lookup tables and temporary data during the
session. It is never deleted or recreated.
My programs don't mess about with any windows file permissions.
All users are Win2000/XP in a 2000Server domain.
OpLocks is off
The weird thing...
User A is an Windows Admin user.
User B is not an Windows Admin user.
User B logs into Windows as B and runs the app no problem.
User A logs into Windows as A and runs the app no problem.
User B logis into Windows as B and runs the app. FE.mde opens but stops and
says No permission to use Temp.mdb
When you check the windows file security settings all the windows file
security settings are gone
and only User A and Administrator have permissions to Temp.mdb and the
option to inherit permissions is off. FE.mde has all of its normal
settings - no change. Only Temp.mdb is affected.
To fix it an Administrator has to log in, change the option to inherit
permissions to on.
Are there some special combination of windows file permissions that I should
use? I've asked my network guys but they say it should work.

Thanks a lot
Brian

 

[Joan Wild]

All users should have read/write/modify/delete permissions on the *folder*
where the mdb files are.

 

[Joan Wild]

I would double check this. Since this is on their local machine, I assume
you have some routine that copies/creates the temp.mdb at least occasionally
so that they have access to updated lookup lists.

Is this message an Access message, or a Windows message? It sounds like an
Access message. Is the mdb secured?

 

[Joan Wild]

Based on what you're saying, I don't see what is causing the problem. Just
opening and closing an application does not change file permissions.

 

[Brian Morris]

Ever heard of a similar problem?

Based on what you're saying, I don't see what is causing the problem. Just
opening and closing an application does not change file permissions.

 

[Joan Wild]

Ever heard of a similar problem?

No I haven't. Just one more thought. Is tempdb set to compact on close? -
that'll create a new mdb in the process, and the new file will inherit the
permissions set on the folder.

 

[Brian Morris]

Wait, YES it does compact on close, I forgot this. But the folder's
permissions are the same as what I see on FE.mdb and that does not change
while Temp.mdb gets a whole different set of permissions.
If this is the cause how do I fix?
Is there a way to copy permissions from one file to another if you are not
an administrator?
Thanks
Brian

 

[Joan Wild]

Wait, YES it does compact on close, I forgot this. But the folder's
permissions are the same as what I see on FE.mdb and that does not
change while Temp.mdb gets a whole different set of permissions.
If this is the cause how do I fix?

That doesn't make sense. Are you certain you are checking all the options
on the file. On the security tab for the file, ensure 'Allow inheritable
permissions from parent to propagate to this object'. On the folder's
permissions tab check 'Reset permissions on all child objects and enable
propagation of inheritable permissions.'

You could always not have it 'compact on close'.

Is there a way to copy permissions from one file to another if you
are not an administrator?

Check out http://www.trigeminal.com/usenet/usenet028.asp?1033

 

[Brian Morris]

I know it does not make sense, that's why I gotten a few more grey hairs.
To be honest I'm not sure if what I'm seeing on the folder permissions is
correct in the first place.
They gave Administrators full control and Everyone full control. On the
folder, "Inherit from parent the permission entries..." is ticked. On the
file, 'Allow inheritable permissions from parent to propagate to this
object' is ticked but as soon as the Admin users closes Temp.mdb and logs
off the machine and the non-admin user tries to open Temp.mdb the file
setting is gone.
What is even stranger is that if the Administrator deletes Temp.mdb and
copies a fresh copy from the server and logs out and lets the non-admin user
log in, it works.
Do you know what groups/permissions I should have on the folder?

Since you point out it may be the compacting causing the problem I will
double check to see if the setting is gone right after compacting or if it
is at some later point.
If it is losing it at the compact I will try the app without the compacting.
Tell me, I decided to compact the Temp.mdb because I saw it growing to
10-15MB but after compacting 1MB. Should I expect a performance hit by not
compacting it?

I tried the copyfileperms routine to copy the permissions from FE.mde to
Temp.mdb but it did nothing, just returned false.

Thanks a lot
Brian

 

[Joan Wild]

I know it does not make sense, that's why I gotten a few more grey
hairs. To be honest I'm not sure if what I'm seeing on the folder
permissions is correct in the first place.
They gave Administrators full control and Everyone full control. On
the folder, "Inherit from parent the permission entries..." is
ticked.

OK, maybe check folders further up the tree - if there is some setting
further up that disallows inheriting from the parent; or that is inheriting
from a parent, but it's inheriting the wrong permission...

 

[Brian Morris]

I'll do that.
Thanks
Brian

OK, maybe check folders further up the tree - if there is some setting
further up that disallows inheriting from the parent; or that is inheriting
from a parent, but it's inheriting the wrong permission...

 

[Brian Morris]

Ms Wild,
You were very right about the compact on close. I can therefore stop doing
that as a short-term solution but sooner or later I think Temp.mdb is going
to have to be compacted.
I put my app in C:\MyApp and looked at the permissons on both C:\ and
C:\MyApp.
C:\
Administrators - Full Control
Creator Owner - Nothing
EveryOne - Nothing
System - Full Control
Users - Read & Execute but not Modify not Write

C:\MyApp
UserB - Nothing
Administrators - Full Control
Creator Owner - Nothing
Domain Users - everything EXCEPT Full Control
System - Full Control
Domain Users - everything EXCEPT Full Control

In the advanced options both folders have a tick in "Inherit from parent the
permission entries that apply to child objects. Include these with..."
I don't know where else to look for the option that would tell a file NOT to
inherit permissions from its folder.
Are you expert on Win2000 security or should I move to the Win2000
newsgroup?
Thanks
Brian

 

[Joan Wild]

Ms Wild,
You were very right about the compact on close. I can therefore stop
doing that as a short-term solution but sooner or later I think
Temp.mdb is going to have to be compacted.
I put my app in C:\MyApp and looked at the permissons on both C:\ and
C:\MyApp.
C:\
Administrators - Full Control
Creator Owner - Nothing
EveryOne - Nothing
System - Full Control
Users - Read & Execute but not Modify not Write

C:\MyApp
UserB - Nothing
Administrators - Full Control
Creator Owner - Nothing
Domain Users - everything EXCEPT Full Control
System - Full Control
Domain Users - everything EXCEPT Full Control

In the advanced options both folders have a tick in "Inherit from
parent the permission entries that apply to child objects. Include
these with..."
I don't know where else to look for the option that would tell a file
NOT to inherit permissions from its folder.

I don't think there is such an option. A new file has to inherit
permissions from somewhere. In the process of compacting, a new file is
created.

Are you expert on Win2000 security or should I move to the Win2000
newsgroup?

I'm not an expert, no. But I can assure you that many people use compact on
close and they don't have this problem. It is a windows permission problem,
so yes perhaps you should pursue in the win2000 group. I would appreciate
that, once you have it resolved, you post back here.

 

[Brian Morris]

Thank you so much for your time.
I will try the other group.
Brian

 

[Brian Morris]

Ms Wild,
I found that when I was compacting the file I had forgotten to specify the
path for the compacted file, it therefore 1st creates the new file in the
MyDocuments folder and then moves it to the C:\MyApp folder. Apparently the
transfer of the permissions in this case would cause the file to belong to
the current user.
The solution was to force it to compact in the C:\MyApp folder..
Thanks
Brian

 

[Joan Wild]

Ms Wild,
I found that when I was compacting the file I had forgotten to
specify the path for the compacted file, it therefore 1st creates the
new file in the MyDocuments folder and then moves it to the C:\MyApp
folder. Apparently the transfer of the permissions in this case
would cause the file to belong to the current user.
The solution was to force it to compact in the C:\MyApp folder..
Thanks

I'm glad you got it sorted, however I always thought that if you didn't
specify a target file, it would create the compacted file in the same
folder.