Exercise your brain. Permissions issue.

[N11]

I have a problem with a share that I am unable to resolve. The server is an NT 4.0 member server running pervasive 7 and housing several large shares, one of which is causing some issues.

The server has been running fine for several years, and there have been no reported or documented issues with this particular share that I have seen or I've been informed of.

The share has several hundred directories underneath and is approximately 7GB in size. Directory is shared out to everyone and security permissions are assignining full control to 'everyone' as well as 'system' 'domain users' 'domain admins' and a few others I added while troubleshooting.

Three users are not able to write to any aspect of the share. They can read and execute but not write. There is no consistency within the 3 users. One was just created in the 2000 domain structure, another has existed for several years and was a part of the NT domain before the migration, and a third was working several days ago until the users computer name was changed and the system was logged back into the network with his credentials.

I've uncovered a workaround which requires adding each user account to an administrative group. Only then are they able to write. I've reapplied security permissions several times allowing the entire world full control of the share but they are still not able to write. I also reapplied service pack 6 with no luck.

There may be a very simple solution to this problem, but I am not sure what to do at this point. It is imperitive that all users access this share and if this starts to spread to other users it would be a mission critical problem.

I've already got a second server online and ready to go in the event that it gets worse. I'm wondering if this may warrant a call to microsoft?

 

[netsysadmin]

N11...this sounds like just a permissions issue...are the users having the same problems on every computer??...I would go over all the share permissions and groups and make sure something is not overlapping...thats usually the problem...I have seen users/groups added to two groups and one group has no access so then your user automatically has no access to that share...if there are any users or groups that have a deny access I would start with those shares...just keep looking Im sure you will find something

 

[N11]

the share is wide open and everyone has been given full control.

 

[bsobel]

Remember there are two sets of permissions to deal with. The first set on the share itself, this controls who can connect via the share. But the file system rights come into play also. Sounds like, possibly, the directory rights by default are not giving write access to these users (maybe it's set to write for certain groups they are not apart of). Anyhow, check the directory security I suspect you'll find the issue there.

Bill

 

[Tanner]

I would make sure that there are no "deny" permissions in a parent directory to the one in which you are having problems.

 

[stash]

You should consider locking down the share and NTFS permissions a little. Giving everyone full control can sometimes lead to problems such as this, since any user can take ownership and change permissions on any file or directory.

For the share permissions I would give domain admins full control and authenticated users change. For NTFS, you should give domain admins full control, and authenticated users modify. This will allow all the regular (non-admin) users to view, edit, delete, create any files, but they wouldnt be able to change any permissions on anything (a permissions best left to an admin).

Anyway, I agree with bsobel--you should check the NTFS permissions. Better yet, just set the top level NTFS permissions of the share to what I outlined above and propogate it down. This will ensure a uniform security structure. I can almost guarantee some user(s) got into something they shouldnt have, and purposely or inadvertantly changed permissions for those 3 users.

 

[N11]

A few of you hit it right on the head. Parent share turned out to be the problem. Ridiculous almost how simple the solution was.

The problem came about with a batch file needing to be executed. Batch file calls various other executables several layers down in the problematic directory, every file executes except for one in particular at a specified line in the file...which in retrospect must be writing somewhere in the directory structure. And the simple solution was checking the permissions on the parent directory which I wasn't even paying attention to given the problematic sub directory was also shared out.

Thank you for the thought stimulation. Even if the solution was this simple!

And stash, full control was designated during the troubleshooting process. However, notes left by prior administrative staff indicate the archaic software application being executed within this directory requires every user and the system full control. I have not had the opportunity to discuss this with the developers or modify and test given the mission critical nature of the application being utilized.

 

[Tanner]

glad U figured it out!