Win2000 Pro-whole drive set to read-only!!!
One of the users on a Windows 2000 Pro machine was given Administrator privileges and he set the permissions for the whole C drive to read-only for the Everyone account.
The drive is NTFS.
Now none of the accounts, including the Administrator account can log in, the machine just goes into endless reboots, just before the password prompt would normally appear.
What can I do to make this drive bootable, short of wiping it and starting over? Is there a utility that would allow me to reset the permissions from a CD bootup or floppy? I have the passwords for all the accounts on the machine, so that's not an issue.
I know that Partition Magic would reformat the drive to FAT or FAT32, but would that solve my permissions problem?
Thanks,
Eufracia
The drive is NTFS.
Now none of the accounts, including the Administrator account can log in, the machine just goes into endless reboots, just before the password prompt would normally appear.
What can I do to make this drive bootable, short of wiping it and starting over? Is there a utility that would allow me to reset the permissions from a CD bootup or floppy? I have the passwords for all the accounts on the machine, so that's not an issue.
I know that Partition Magic would reformat the drive to FAT or FAT32, but would that solve my permissions problem?
Thanks,
Eufracia
If Partition Magic can convert an NTFS partition to a FAT32 partition without wiping the data, and if the reboot loop is actually being caused by the permissions problem, then yes PM should solve the problem. I've never converted from NTFS back to Fat32, just the other way around. You might try booting to the Win2k CD and doing a repair installation. Also, the tool CACLS.EXE can change permissions from the command line. If you can get the system to boot to the recovery console, which to me pretty much equates to booting to a command prompt, you might be able to change permissions on system files like pagefile.sys. I'd be supprised if changing the Everyone group's permissions would actually restrict the LOCAL admin account from accessing files. Although WinNT/2K takes the more restrictive between Share and NTFS perms, NTFS perms have a cummulative effect as long as you don't have No Access, or Deny Access(whatever it's called). So it sounds like the user would have to have not only restricted Everyone to Read Only, but also removed the Local Admin ID from the ACL. So my answer in short, Repair installation, or Recovery Console and CLI permissions changing, or last ditch try partition conversion.
BTW, a reboot loop can be caused by something as simple as a command, like "shutdown /r", strategically placed in the Registry, like in the Run key. If the machine is locked in a reboot loop, how do you know the status of the permissions?
BTW, a reboot loop can be caused by something as simple as a command, like "shutdown /r", strategically placed in the Registry, like in the Run key. If the machine is locked in a reboot loop, how do you know the status of the permissions?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thanks benhanson, I'll try the repair you suggested from the install disk. Is there anything special I need to do to get to the Recovery Console?
I only know the status of the permissions from what the user told me. He said he went to a tab of the User Setup control panel item and set the C drive and all subfolders to read-only. I assumed that since his account is a member of the Administrator group that he can set the rights for all other users, including the local Administrator.
I walked him through rebooting into Safe mode, it gets as far as the Win2000 logo screen but reboots before the password screen comes up. He told me the first few times he rebooted he did get the password screen and he tried to login, but it immediately rebooted as soon as he entered the admin password, or his own password. Now he doesn't even get to where he can enter one.
I only know the status of the permissions from what the user told me. He said he went to a tab of the User Setup control panel item and set the C drive and all subfolders to read-only. I assumed that since his account is a member of the Administrator group that he can set the rights for all other users, including the local Administrator.
I walked him through rebooting into Safe mode, it gets as far as the Win2000 logo screen but reboots before the password screen comes up. He told me the first few times he rebooted he did get the password screen and he tried to login, but it immediately rebooted as soon as he entered the admin password, or his own password. Now he doesn't even get to where he can enter one.
ASKER
Thanks for replying, tobyk.
I can put the drive in a different Win2k machine. Where do I find xcacls?
--Eufracia
I can put the drive in a different Win2k machine. Where do I find xcacls?
--Eufracia
ASKER
I found xacls on the MS Support site. Anybody know the syntax to use on xacls.exe to make all of the C drive writeable?
At least, I think that's what I need to do, just to make the PC bootable. Any ideas?
--Eufracia
At least, I think that's what I need to do, just to make the PC bootable. Any ideas?
--Eufracia
Here is the syntax and some examples:
I will use
XCACLS x:\ /T /E /C /G Administrator:F
to give Local Administrator the Full rights.
X is the drive on wich you change the permissions from the root.
Displays or modifies access control lists (ACLs) of files
XCACLS filename [/T] [/E] [/C] [/G user:perm;spec] [/R user [...]]
[/P user:perm;spec [...]] [/D user [...]] [/Y]
filename Displays ACLs.
/T Changes ACLs of specified files in
the current directory and all subdirectories.
/E Edit ACL instead of replacing it.
/C Continue on access denied errors.
/G user:perm;spec Grant specified user access rights.
Perm can be: R Read
C Change (write)
F Full control
P Change Permissions (Special access)
O Take Ownership (Special access)
X EXecute (Special access)
E REad (Special access)
W Write (Special access)
D Delete (Special access)
Spec can be the same as perm and will only be
applied to a directory. In this case, Perm
will be used for file inheritence in this
directory. If not omitted: Spec=Perm. Special values
for Spec only:
T NoT Specified (for file inherit,
only for dirs valid)
At least one access right has to follow!
Entries between ';' and T will be ignored!
/R user Revoke specified user's access rights.
/P user:perm;spec Replace specified user's access rights.
for access right specification see /G option
/D user Deny specified user access.
/Y Replace user's rights without verify
Wildcards can be used to specify more that one file in a command.
You can specify more than one user in a command.
You can combine access rights.
The following table lists and describes all XCACLS parameters.
Parameter Description
filename The name of file or directory to which the access control list (ACL) or access control entry (ACE) should be applied. All standard wildcard characters can be used.
/T Recursively walks through the current directory and all its subdirectories, applying the chosen access rights to the matching files and/or directories.
/E Edits the ACL instead of replacing it. If you specify the following command line:
XCACLS test.dat /G Administrator:F
only the Administrator has access to TEST.DAT. All ACEs applied earlier are lost.
/C Causes XCACLS to continue if an "access denied" error occurs. If /C is not specified, XCACLS stops on this error.
/G user:perm;spec Grants access to user to the matching file or directory. The perm access is applied to files and represents the special file-access-right mask for directories. The spec part is only applied to directories.
This notation does not correspondent to the display of Explorer or File Manager. Nevertheless, the notation has been preserved to guarantee that older CACLS scripts work with XCACLS as well.
The access options for files (for directories, special file access and special directory access) are identical. For detailed explanations of these options, see the Windows NT operating system documentation.
For directories only, it is possible to set an ACE for the directory itself without specifying an ACE that is automatically applied to new files created in that directory. To accomplish this from the command line, the specifier T follows the ";". All access rights specified between the ";" and the T are ignored. At least one access specifier must follow the T. This means that only an ACE for the directory will be created.
All other options, which can also be set in Explorer or File Manager, are subsets of all possible combinations of the basic access rights. Therefore, there are no special options for directory access rights like LIST or READ.
/R user Revokes all access rights for the specified user.
/P user:perm;spec Replaces access rights for user. The rules for specifying perm and spec are the same as for the /G option. Some examples are given below in this documentation.
/D user Denies access to the file or directory for user.
/Y Disables confirmation when replacing user access rights. By default, CACLS asks for confirmation. Because of this feature, when CACLS is used in a batch routine, the routine hangs until the right answer is entered. The /Y option was introduced to avoid this confirmation, so XCACLS can be used in batch mode.
3.2. Examples
XCACLS *.* /G administrator:RW /Y
This command replaces the ACL of all files and directories found in the current directory, without scanning any subdirectories and without confirmation.
XCACLS *.* /G TestUser:RWED;RW /E
This command edits the ACL of a file or a directory, but its effect on a directory is different. The ACE added to the directory is also an inherit ACE for new files created in this directory.
In this example, the command gives TestUser read, write, execute and delete rights on all new files created in this directory, but only read and write permissions on the directory itself.
XCACLS *.* /G TestUser:R;TRW /E
This command grants read and write permissions on a directory without creating an inherit entry for new files. Therefore, in this example, new files created in this directory get no ACE for TestUser. For existing files, an ACE with read permissions is created.
I will use
XCACLS x:\ /T /E /C /G Administrator:F
to give Local Administrator the Full rights.
X is the drive on wich you change the permissions from the root.
Displays or modifies access control lists (ACLs) of files
XCACLS filename [/T] [/E] [/C] [/G user:perm;spec] [/R user [...]]
[/P user:perm;spec [...]] [/D user [...]] [/Y]
filename Displays ACLs.
/T Changes ACLs of specified files in
the current directory and all subdirectories.
/E Edit ACL instead of replacing it.
/C Continue on access denied errors.
/G user:perm;spec Grant specified user access rights.
Perm can be: R Read
C Change (write)
F Full control
P Change Permissions (Special access)
O Take Ownership (Special access)
X EXecute (Special access)
E REad (Special access)
W Write (Special access)
D Delete (Special access)
Spec can be the same as perm and will only be
applied to a directory. In this case, Perm
will be used for file inheritence in this
directory. If not omitted: Spec=Perm. Special values
for Spec only:
T NoT Specified (for file inherit,
only for dirs valid)
At least one access right has to follow!
Entries between ';' and T will be ignored!
/R user Revoke specified user's access rights.
/P user:perm;spec Replace specified user's access rights.
for access right specification see /G option
/D user Deny specified user access.
/Y Replace user's rights without verify
Wildcards can be used to specify more that one file in a command.
You can specify more than one user in a command.
You can combine access rights.
The following table lists and describes all XCACLS parameters.
Parameter Description
filename The name of file or directory to which the access control list (ACL) or access control entry (ACE) should be applied. All standard wildcard characters can be used.
/T Recursively walks through the current directory and all its subdirectories, applying the chosen access rights to the matching files and/or directories.
/E Edits the ACL instead of replacing it. If you specify the following command line:
XCACLS test.dat /G Administrator:F
only the Administrator has access to TEST.DAT. All ACEs applied earlier are lost.
/C Causes XCACLS to continue if an "access denied" error occurs. If /C is not specified, XCACLS stops on this error.
/G user:perm;spec Grants access to user to the matching file or directory. The perm access is applied to files and represents the special file-access-right mask for directories. The spec part is only applied to directories.
This notation does not correspondent to the display of Explorer or File Manager. Nevertheless, the notation has been preserved to guarantee that older CACLS scripts work with XCACLS as well.
The access options for files (for directories, special file access and special directory access) are identical. For detailed explanations of these options, see the Windows NT operating system documentation.
For directories only, it is possible to set an ACE for the directory itself without specifying an ACE that is automatically applied to new files created in that directory. To accomplish this from the command line, the specifier T follows the ";". All access rights specified between the ";" and the T are ignored. At least one access specifier must follow the T. This means that only an ACE for the directory will be created.
All other options, which can also be set in Explorer or File Manager, are subsets of all possible combinations of the basic access rights. Therefore, there are no special options for directory access rights like LIST or READ.
/R user Revokes all access rights for the specified user.
/P user:perm;spec Replaces access rights for user. The rules for specifying perm and spec are the same as for the /G option. Some examples are given below in this documentation.
/D user Denies access to the file or directory for user.
/Y Disables confirmation when replacing user access rights. By default, CACLS asks for confirmation. Because of this feature, when CACLS is used in a batch routine, the routine hangs until the right answer is entered. The /Y option was introduced to avoid this confirmation, so XCACLS can be used in batch mode.
3.2. Examples
XCACLS *.* /G administrator:RW /Y
This command replaces the ACL of all files and directories found in the current directory, without scanning any subdirectories and without confirmation.
XCACLS *.* /G TestUser:RWED;RW /E
This command edits the ACL of a file or a directory, but its effect on a directory is different. The ACE added to the directory is also an inherit ACE for new files created in this directory.
In this example, the command gives TestUser read, write, execute and delete rights on all new files created in this directory, but only read and write permissions on the directory itself.
XCACLS *.* /G TestUser:R;TRW /E
This command grants read and write permissions on a directory without creating an inherit entry for new files. Therefore, in this example, new files created in this directory get no ACE for TestUser. For existing files, an ACE with read permissions is created.
ASKER
Thanks, I'll try these fixes this morning and let everyone know. I really appreciate the help, guys!
--Eufracia
--Eufracia
ping
ASKER
Well, I discovered when I installed the drive in another Win2000 machine that I could right-click and reset the permissions using the Sharing tab.
Tobyk, you were suggested installing the drive in a second machine, so I'm giving you the points, though I didn't have to use XCACLS. Actually I tried using XCACLS with the syntax that longbow suggested but kept getting syntax errors, maybe because the drive was read-only?
Anyway, 100 points to you, Tobyk, I'll have EE send 50 to benhanson for his efforts.
--Eufracia
Tobyk, you were suggested installing the drive in a second machine, so I'm giving you the points, though I didn't have to use XCACLS. Actually I tried using XCACLS with the syntax that longbow suggested but kept getting syntax errors, maybe because the drive was read-only?
Anyway, 100 points to you, Tobyk, I'll have EE send 50 to benhanson for his efforts.
--Eufracia
Thank you, Eufracia, I responded to you in Community Support with greater detail, but will give brief instructions here as well.
Please post a new question in this topic area, entitle it
Points for behhanson for the other 50 points you wish to award, and in the comment field paste this link, to keep the relationship with the additional point flow.
https://www.experts-exchange.com/admin/adminShow.jsp?qid=20278111
benhanson will then either comment or Propose an Answer which you accept to grade and close it. That'll complete this point split transaction and allow all your point history to remain within your personal profile, which is not the case if a Moderator posts these Points for questions for you.
Thanks,
Moondancer - EE Moderator
Please post a new question in this topic area, entitle it
Points for behhanson for the other 50 points you wish to award, and in the comment field paste this link, to keep the relationship with the additional point flow.
https://www.experts-exchange.com/admin/adminShow.jsp?qid=20278111
benhanson will then either comment or Propose an Answer which you accept to grade and close it. That'll complete this point split transaction and allow all your point history to remain within your personal profile, which is not the case if a Moderator posts these Points for questions for you.
Thanks,
Moondancer - EE Moderator
https://www.experts-exchange.com/jsp/qShow.jsp?ta=win2k&qid=20278490
Points for benhanson posted above by Eufracia
Moondancer - EE Moderator
Points for benhanson posted above by Eufracia
Moondancer - EE Moderator
change the extension to .exe and pop a floppy in the drive then reboot with this floppy - everything
is pretty self-explanatory.
(change the extension on the download from .z19 to exe)
then change the local administrator password and set the permissions on the drive back to the way they were.
Then knock that user who had admin rights down to user status. . .