Are some of your directories showing up as read-only? Join the crowd. It’s a common problem in Windows 7, but there are a few ways to address it.
Recently, a friend reported that since the April 13th Windows security patch, her copy of 64-bit Windows 7 is marking all folders as “read only” and she couldn’t find an easy way to fix it. She’s not alone. But this isn’t a problem that’s unique to either 64-bit Windows 7 or this particular set of patches. Instead, it seems to be an endemic problem with Windows 7 and Windows Vista.
It seems that several things can cause this problem. Among the causes: patching the system, upgrading from one version of Windows to another, and saving files to the top-level directory (C:\). Microsoft knows this is an issue, but for some reason the company doesn’t call it a bug.
According to Microsoft Support’s most relevant support document, “You cannot view or change the Read-only or the System attributes of folders in Windows Server 2003, in Windows XP, in Windows Vista or in Windows 7,” that’s probably because:
“The Read-only attribute for a folder is typically ignored (!) by Windows, Windows components and accessories, and other programs. For example, you can delete, rename, and change a folder with the Read-only attribute by using Windows Explorer. The Read-only and System attributes is only used by Windows Explorer to determine whether the folder is a special folder, such as a system folder that has its view customized by Windows (for example, My Documents, Favorites, Fonts, Downloaded Program Files), or a folder that you customized by using the Customize tab of the folder’s Properties dialog box.”
So, since the folder’s permission setting is usually ignored, can you ignore it? No, you can’t.
The read-only setting will get in the way of writing some files and, as Microsoft admits, “If a network share that has a large amount of folders set to Read-only, it can cause Explorer to take longer then what is expected to render the contents of that share while it waits on the retrieval of the Desktop.ini files. The slower the network connectivity to the share the longer this process can take to the point where Explorer may timeout waiting for the data and render nothing or appear to hang.”
Thus, if you’re using Libraries and HomeGroups to share files in a branch office or a Windows 7 system as a BranchCache server, this issue could lead to serious network performance problems. Adding insult to injury, you can’t address this issue using Windows Explorer because, according to Microsoft, “Windows Explorer does not allow you to view or change the Read-only or System attributes of folders.”
Fixing and Side-Stepping the Problem
I wish I could say that there’s a perfect solution to this problem. There’s not. Some methods work for some users and some don’t. I really wish that Microsoft would address this problem since it does show up fairly often, it’s been showing up since Windows XP, and it can prove extremely troublesome in small networks. I mean, come on, this is file permissions. How hard can it be?
In short, you use
Attrib at a command prompt (
Cmd.exe) to view or to remove the Read-only or the System attributes of folders. You do this by logging in as the Admin user and then following these steps:
- Click Start, click Run, type
cmd, and then press Enter. (If the Run command is not listed on the Start menu, Click Start, click All Programs, click Accessories, and then click Run.)
- To remove the Read-only attribute, at the command prompt type the following command:
- You may also need to remove the System attribute. In that case, use the command:
attrib -r drive:\<path>\<foldername>
attrib -r -s drive:\<path>\<foldername>
If this works, you can now bore yourself to tears by running it as needed on other folders.
If you have multiple folders (or even systems) with file permission problems like this, you might think that it would be easier by far to use a PowerShell script to clean up the trouble automatically. You’d be wrong.
As Don Jones, a PowerShell expert, explained in a TechNet article, “Now, please don’t get mad, but I have to say that this is not a task for which Windows PowerShell is currently well-suited. I know, I’m sorry. It’s just that Windows file permissions are terrifically complicated little beasts.” (I can only add that is one situation where Linux, and the rest of the Unix family, does the job far better.)
That Didn’t Work. Now What?
What should you do if the command-line method doesn’t work? You can always try turning off the UAC (User Account Control). Unlike Windows Vista, where doing so was a binary choice, Windows 7 lets you choose different levels of UAC. Unfortunately for your system security, turning it all the way off seems to offer the best chance of eliminating the problem.
To do this, once more Click Start and click Run. This time enter
UAC and then pull the slider to the bottom, as you see here:
Now, reboot. And, if the stars are in the right position, the problem should have disappeared.
No such luck? Well, Microsoft suggests, you might have a corrupted user profile. To see if that’s the problem, Microsoft suggests creating a new user profile. You do this by following these steps:
- Open User Accounts. Do so by clicking the Start button, clicking Control Panel, clicking User Accounts and Family Safety (or clicking User Accounts, if you are connected to a network domain), and then clicking User Accounts.
- Click on Manage another account. If you are prompted for an administrator password or confirmation, type the password or provide confirmation.
- Click Create a new account.
- Type the name to give the user account, click an account type, and then click Create Account.
If you can now create folders without having them automatically turn into read-only folders, your next move is to try to repair the corrupted user account using the steps described in Fix a corrupted user profile. This is a rather complicated affair; I highly recommend backing up any system before trying to tackle it.
Still in trouble? Well, besides letting Microsoft know that this isn’t just an “issue” to you but a “bug, you can try to work around it by only using Windows 7′s Public Folders. Of course, this comes with the wee problem that any sub-directories and files in these folders will be available to anyone with a user account and password on the computer. Since this problem is most troublesome when a Windows 7 system is sharing files with other users, this can be a real security annoyance even if multiple users aren’t sharing a single PC.
Unfortunately, if this file permission foul-up is giving your users real problems, this may be your only practical solution. Still, I’d make this attempt to get around the read-only bug my last resource. If I tried everything else, and it still didn’t work, I think I’d try reorganizing the branch’s file-sharing arrangements by adding another server before resorting to this measure. Your usage may vary. Good luck.
Want more like this? Sign up for the weekly IT Expert Voice newsletter so you don’t miss a thing!