0

I have an XP Pro system using Simple File Sharing. Sharing is enabled for a particular folder, as well as "Allow network users to change my files".

When copying (reading) the shared files from another machine, some of them (about 20 out of 1000, give an Access Denied error. No programs have the files open.

I have to go to the machine that is sharing the files and run

CACLS C:\MySharedFolder\*.* /T /e /g Everyone:c

This fixes the problem and all the files can be accessed. But it is inconvenient to have to run that command. After a few days or weeks, the error returns.

What is the root cause of this error? It seems that program that accesses the files (In this case Eudora) is incorrectly setting the permissions - but why only on this machine? I have other machines with identical configurations of shared folders that never have this problem.

2
  • Next time it happens, run a "cacls <path and filename of bad file>" and see what the screwed-up permissions look like. You can compare them to the folder w/ running a "cacls <folder path>" and see how they differ. Jul 8, 2009 at 21:30
  • You may also like to look at the permissions settings on the folder, especially the inheritance. Jul 8, 2009 at 21:49

3 Answers 3

1

Classically, this can be caused by users cutting and pasting files into a share. This means that if the files (at source) were set to not inherit permissions from the parent folder, when they are cut & paste to the destination, they keep their old permissions.

1
  • 1
    You're close. Files pasted within a single volume (or share) will keep the permissions they were assigned/inherited at the time of creation, even if they're moved into a folder that would assign different permissions to them (if they had been created in that folder) later. Permission inheritance happens at creation only! Copying / moving files between shares or volumes is a create / copy (and delete of source if moving), so permission inheritance does occur in those circumstances. Have a look at: serverfault.com/questions/31709/… Jul 8, 2009 at 21:33
0

This is not really an answer but further information (can't use comment due to char limit). I'm still trying to understand and solve this issue.

Here's what a "bad" file's permissions looks like in CACLS ( the permissions prevent copying from another machine):

C:\...\Mail\descmap.pce BUILTIN\Administrators:F
                        NT AUTHORITY\SYSTEM:F
                        MARS\Tim:F
                        BUILTIN\Users:R

Here's what a "good" file looks like:

C:\...\Mail\In.mbx Everyone:C
                   BUILTIN\Administrators:F
                   NT AUTHORITY\SYSTEM:F
                   MARS\Tim:F
                   BUILTIN\Users:R

Here's what the "Mail" (parent) folder's permissions look like:

C:...>cacls mail
C:...\Mail Everyone:(OI)(CI)C
           BUILTIN\Administrators:F
           BUILTIN\Administrators:(OI)(CI)(IO)F
           NT AUTHORITY\SYSTEM:F
           NT AUTHORITY\SYSTEM:(OI)(CI)(IO)F
           MARS\Guest:F
           CREATOR OWNER:(OI)(CI)(IO)F
           BUILTIN\Users:R
           BUILTIN\Users:(OI)(CI)(IO)(special access:)
                                     GENERIC_READ
                                     GENERIC_EXECUTE

           BUILTIN\Users:(CI)(special access:)
                             FILE_APPEND_DATA

           BUILTIN\Users:(CI)(special access:)
                             FILE_WRITE_DATA

The "Everyone:C" and the "BUILTIN\Administrators:F" attributes somehow get removed from the problem files. Different files are affected at different times. There doesn't seem to be any consistency.

0

This is not an solution but something to compare notes on...

I have nearly the same exact problem. However, in my case, I had a user id logging into a Samba-3 server acting as PDC (so I have machines joined to the domain).

This user id could access a file from WinXP box but on Win7-PRO machine they would get access denied error. The file was not moving from share to share or folder to folder. It was just a public folder that everyone in the company had access too.

I tried everything to resolve and the only thing I found was restaging the workstation with clean copy of Windows-7 fixed the issue.

In my case, Windows7's interaction with SAMBA appeared to be the issue. Interesting is that I have other Win7 boxes that the problem did not happen on with other users but this one particular particular user id only had the problem on Win7 boxes.

I even deleted the user id and recreated it, and purging their roaming profile did not fix the issue. I also found if I told the user to use a newly created user id that did not match the old user id, the problem would still be there.

It was if this one windows-7 workstation caused the problem to appear with the user's ID which there after it traveled with that user id to other Win-7 workstations.

Restaging the one Win-7 workstation make the problem go away.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .