Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I had a Windows Server 2003 machine running at home, along with my desktop which I use for development. Server went belly up, but since my desktop is reasonably powerful, I figured I would move the disk from the file server (it was OK) into my XP machine to keep all of the files. Disk comes up fine and shows all of the files. I have been getting access denied errors when trying to work with some of the files. When I display attributes in Explorer, none of them are marked Read-Only. When I view properties on the directories, the Read-Only checkbox is not checked, but has a green background(which I thought meant mixed usage for files in the directory). When I click on the checkbox to clear it and click Apply, the disk does some work and all looks well. However, I continue to get the Access Denied errors, the files still don't show any Read-Only attribute and the directory properties shows the green background again on the Read-Only checkbox. I did check the box which says to apply the change to the folder and all files /subfilders under it.

I am assuming that the issue relates to userids/permissions carried over from the Server install. So, why does it let me think I can change the attribute when I can't and how can I correct this problem so that the disk correctly recognizes the ids from XP?

share|improve this question

migrated from stackoverflow.com Nov 28 '09 at 18:17

This question came from our site for professional and enthusiast programmers.

3 Answers 3

Have you tried taking ownership of the files? You'll need Administrator privileges.

From WinXP's explorer, browse to the root of the drive, right-click on a folder or file, select Properties. Go to the Security tab, click Advanced. Go to the Owner tab. It should display the item's current owner, then give you a list of owners you can change to. Select your user ID in the selection box, check the box for "Replace owner on subcontainers and objects", and click OK.

You can probably do this from the commandline with cacls or another command. Unfortunately, WinXP doesn't include a takeown.exe command like Vista and Win7.

share|improve this answer
    
Would this be any different from the first SubInACL command provided below? I do have Adminstrator Privileges and tried a number of options from the properties tab. In all cases, I selected the related "apply to all subfolders/files" checkbox and none of those options succeeded, even though no error was ever returned. –  cdkMoose Nov 30 '09 at 18:43
    
honestly i don't know. presumably they'd use the same internal APIs to do the work, but there's no guarantee the processes would be identical, so it seems worthwhile to mention. –  quack quixote Nov 30 '09 at 18:54

Unfortunately the useful tool takeown doesn't seem to be on XP (not that I can find). What you can do is get the SubInACL tool and run the commands.

subinacl /subdirectories X:\*.* /setowner=user
subinacl /subdirectories X:\*.* /grant=user=F

Replacing user with your username and X:\ with the drive letter the disk is mapped to.

Obviously do this at your own risk :)

share|improve this answer
    
I'll follow this thread when I am home this evening. Thanks. –  cdkMoose Nov 24 '09 at 19:52
    
I tried subinacl, but haven't gotten it to clear the read-only flag. –  cdkMoose Nov 25 '09 at 1:40

I never could make SubInACL do what I wanted. I found what turned out to be a surprisingly simple solution. When I copied the files to a different partition which I formatted on the XP machine, my problems were gone. I was able to process the files in any way I chose, including some of the files which were SQL Server data and log files. I was able to attach the db to the instance of SQL Server 2005 on the XP machine with no problems.

I can only guess that the file owenrship and permissions on those files were tied to IDs that XP had no knowledge of, so any attempts to modify that must have been blocked. I'm wondering of SubInACL wouldn't reassign because it couldn't identify who was being removed.

share|improve this answer
    
more of a workaround, really. when you copy files that don't belong to you, the copies become owned (technically, are created) by you. if nothing else works, copy the data off the wonky drive, reformat, and copy back. –  quack quixote Nov 30 '09 at 18:56

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.