Hardware

Ask something
Question Locked

File permissions being mysteriously changed.

0 helpful
20 replies

by computech911 1 view

Closed to new repliesThis discussion is closed. It stays readable, but it takes no new replies.

I have a client who is using simply accounting in multiuser mode. The setup is 2 workstations both with XP pro. The simply data is stored in a shared folder on workstation 1. Workstation 2 accesses the shared folder via mapped network drive.

It then so happens about 3-4 days later workstation 2 gets an 'access denied' error when opening the simply data file. So I check the permissions on the shared folder and everything checks out... workstation 2 can even still access the folder (just not the simply data file). So I check off the "replace permission entries on all child objects..." box on the shared folder and everything then works again... for about 3-4 days.

So it appears something is messing with the file permissions of the simply data files. Any idea how I can permanently resolve this?

Thanks guys.

20 replies

by dumphrey

my first thoughts are; 1) Is this a multiuser database appliation, or are the issues from one copy "locking" the file for use? and 2) Does the owner of the file change? Meaning is one copy of the software taking ownership of the file?

Ohh, and have you double checked share ermissions, not just file system permissions?

by computech911

1) Simpy Accounting can be setup as a multiuser database application. It uses its own proprietary DB format and doesn't run any SQL services or anything like that. It has 2 data files one called .SDB (which is the data file) and .SDW (which is the security file). From what I gather about the situation this doesn't seem to be a application issue at all. It seems to be a windows issue.

2) No, I don't believe the owner of the file changes. The files are not being moved nor re-created in any way. The owner being the default user on workstation 1. There is only one user account per workstation.

3) Yes I have checked the share permissions and NTFS security permissions on the shared folder which do not seem to change at all. It is the NTFS security permissions on those two Simply Accounting files that seem to be mysteriously changing.

by dumphrey

to change, an account with admin priv must change them. I would some program is running as a system service, accessing the system account, and modifying permissions.
Any new software added? And what methode are you using to share out the data? local setting or scripted?
And if i read your original post, one computer always ends up with access? And is it always the same computer?
May want to check ownership next time the file gets to be unreadable, its probably not the case, but best to rule it out for sure.

Sage recomends that the data be stored in a shared folder at the root of the C:\ drive and not in Program Files, and all users accessing it need full permissions. Dunno where your share is, but its worth looking.

EDIT: since this is only effecting the Simply data files, do your users have admin rights to the machines? Could one of them be acting like an ass? Or, could there be a mis config in the Simply, multi-user setup?

by computech911

Ok I am at said client location right now and have checked out your suggestions.

It looks as if the .SDB file is being stripped of all permissons other than Administrators (group), the local user's account, and SYSTEM (group).

What is curious is that the "inherit from parent permissions..." check box is UNCHECKED. Which is the only reason it is able to strip these necesssary permissons.

I checked the owner of the file and it belongs to the user's account (workstation 1)

As for the way the shared folder is setup. It is just a folder off of c:\ the share permissons are administrators have full control and Everyone has change and read. The local user account does have admin privs.

So I guess the only thing I need to do now is find out what is removing that "inherit from parent..." check box and why it is stripping permissons on that one file.

by dumphrey

if its at the root of the C drive, there will not be much to inherit from. the good thing is that you can set what permissions you want. Are these computers in a workgroup or domain? And is simple sharing still active if in a workgroup?

I would turn off simple file shareing, rebuild permissions on the share, make sure the users in questions have full access on share permissions. On file system permissions, add the users, go to advanced and set allow inheritence check box, and let it do its thing. Check permissions on the folder and child objects. If the permissions are not correct, set them on the folder, inheritence should pass them down, if not use the replace on child objects box.
And honestly, as a last resort, set up a third computer as a linux box running samba to act as a file server for the 2 other boxes =\

by computech911

The workstations share a workgroup and simple file sharing was disabled long ago.

As for your other suggestions, I've already done all those... I just wish I could replicate the process that is stripping the permission off the .SDB file.

The one thing I did do differently then all the other time was check the "inherit from parent" box in the NTFS security permissions for the .SDB file. Everything else checked out fine. So we'll wait and see.

Thanks for the advice.

by dumphrey

for you =) If not, repost or send me a pm and I will help you dig at it some more. I have found that most of the time, having someone to bounce things off of helps more then an answer... if that makes sense...

by computech911

I'm almost 99% certain this isn't network or a network share issue. The permissions on the shares do not change at all.

This has to be a local machine issue with workstation 1.

Other than windows itself, what types of software generally change NTFS file permissions on files? What level of privilege do you you need to change NTFS file permissions?

Perhaps if I can not solve this problem directly I could at least use windows user access control to lock down this file so permissions can not be changed. Does the modify priv. imply the ability to change NTFS permissions on files?

by computech911

Again today after the remote session I saw that on the .SDB file itself the "inherit from parent" box had been unchecked again and that the permissions had been stripped down to the Administrators, SYSTEM and the local user's account (again).

So today I've decided to come at this from a different perspective, as I am starting to suspect the F-PROT AV as being the reason for this grief.

I logged off the local user's account and logged on the administrator. On the .SDB file itself, in the advanced permissions window I checked "inherit from parent..." then unchecked it to copy the permissions from the parent folder. I then removed the Administrators GROUP and added the Administrator USER. I changed the owner of the file from the local user's account to the Administrator. I removed the FULL CONTROL permissions from the local user's account and use the 'effective permissions' tab to remove the ability to change permissions.

So now after it is all said and done I am left with ONLY the Administrator and SYSTEM having the ability to change permissions on this file.

So without the administrator account being logged in (which it never is) the SYSTEM account is the only group that can change permissions now.

We'll see what happens, but because F-PROT is running as SYSTEM it would make sense that it was the culprit. I also did notice some event log errors regarding its inability to scan its quarantine properly so I fixed that as well.

by dumphrey

A quick note to your earlier post, modify is basicly a create files and folders permission, and mostly it just applies to folders.
As for changing permissoins, it has to be an account that has full permissions to the file, or that has been given explicit permission through special permissions. in my free time, I have been trying to find a way to make an event trigger for when the permissions get changed, then maybe you could know for sure what was doing it.

by computech911

That certainly makes sense Dumphrey!

However again today she is getting the same error on workstation 2

I asked her yesterday when she noticed she couldn't get in, even on the other occasions, and it is ALWAYS in the morning. So again this morning she was unable to get in... but it worked all day yesterday after I had fixed it.

So this is starting to make me think its something happening at night, either scheduled or otherwise. The weird thing is is that they usually turn off their machines before they leave the office. I'm planning a remote session for later today, but I'm running out of ideas.

They are running f-prot AV but I have a hard thinking it could be responsible for such a specific issue like this one. I mean, it's ONE file on the computer. The share permissions DON'T change, it's just the NTFS security permissions on that one .SDB file.

I haven't been this baffled in a while...

by dumphrey

off their computers in the evening, its when they reboot, I would guess, that permissions are being "reset." This would be easy enough to test, reboot station 2, 3, or 4 times and see what happens. Then, I would reboot station 1, leaving station 2 powered on. Then power off station 2, reboot station 1, and then power on station 2. This way we can see which machine is resetting the permissions.

Also, try setting file system permissions on the root of the share, remove all but local machine admin, and unchecking inherite from parent, and check the replace permissions on child objects. So, now, only machine 1's admin should have file system permissions to the folder. Now go in and give Everyone read and execute to the folder. Check to see that they trickled down. Then add \Username full permissions (ie PollyServer\jsmith). Log on as that user and see if access is there. If it works, then add \username with full permissions. And try accessing. Make sure both users have Full share permissions as well.

On a thought, are these workstations on dhcp or static addressing? Are you using any dns?
If dhcp and no dns, I would try switching them to static ips and adding an entry for each in each host file (add machine1 to machine2's host file and vice verca.) That way, UNC paths can be used to map the share, and ip addresses will not change, causing the unc path to fail.

by computech911

I did a various number of reboots yesterday to check for that. I also opened and exited Simply Accounting in a various number of sequences between the 2 machines yesterday as well.

I can not seem to replicate the problem at all when I'm there... And now it seems to be every morning, where as before it was every 3-4 days.

by dumphrey

I guess try the static ips, set the host file and remap the drives. After 3 to 4 days could be an ip renewing from a dhcp server. Of course, this assumes its not already static. But hosts file could play a part in permissions. When you check them, are they visably reset? Or are they just not working right?

Also, we now know its not the rebooting, but the time interval... any scheduled tasks on either machine? Virus scan, defrag, back up...

by thumbsup2

... on another well known accounting application. There are certain tasks/reports run by Workstation 1 that require sole access to the file and force Workstation 1 to log into the software itself with it's own "admin" account. If Workstation 1 forgets to log out as the software "admin" and back in as a normal user, the data file is left in "admin" only mode.

Personally, I would check the way the program is being used at Workstation 1. It might not be a software thing at all, but a user education problem.

Just a thought, since nothing else is making sense.

by dumphrey

computech but that makes sennse to me. Since the permissions are being reset and not just ignored.

by computech911

Since this has happened AGAIN yesterday. With the SYSTEM group being the only active group that has privs. to change permissions on this file, I have pretty much concluded it is an issue with the F-Prot antiviruis software. Still as almost a combination of what ThumbsUp2 described, it seems this only happens when workstation 2 is logged in and then F-Prot does a scheduled scan.

What confused me is that this was only happening in the mornings... then I realised because they were turning thier computers off at night that F-Prot was doing the missed scheduled scan first thing in the morning when they turned on the machines. I also setup a scheduled scan for 3pm and guess what doesn't work afer 3pm?

by thumbsup2

Isn't it fun to troubleshoot a problem, only to find it was something else so innocent that you never would have suspected it at first glance. :D We always want to blame the system. It's ALWAYS the systems fault. ;) Can't possibly be the way we've scheduled things to happen at night and then shut the thing down so it has no choice but to do plan "B" when the machine comes back up.

by dumphrey

And congrats! guess its time for some different AV?

This discussion is closed to new replies.