Cannot edit files, even though I have full control over them

    General discussion

  • On Windows Server 2008 R2, we have an application installed that has some plain text configuration files. My team needs to be able to edit these files regularly.

    All my team have dedicated admin accounts that are full Administrator on these servers, many are Domain Admin and Enterprise Admin too. The servers are critical infrastructure and we do not want to switch off UAC.

    Trying to access these text files located in C:\<appname>\app\product\client\network\admin  from the interactive console of the server results in Access Denied. We cannot create a new file in the folder (the only option is new folder). Viewing security shows the group Servername\Administrators as having full rights, the Effective Permissions tab will show that each user account has all access rights to the folder and to the file.

    From a Windows XP client, we can connect to \\servername\c$\<software>\app\product\client\network\admin  with the same username as had access denied before, and full control is granted - the file can be edited.

    We don't want to switch off UAC on these servers. We don't want to change ownership to an individual user on these files, just so the file can be edited.

    How do we change the configuration of these folders so that we are able to actually use the permissions that have been specifically assigned to the system?

    Tuesday, November 2, 2010 6:24 AM

All replies

  • Good Day Christian,


    When accessing the files from the interactive console, are you logging on via admin shared such as c$ or are you instead connecting via normal network share using SMB/CIFS?

    From what I can see its purely a permission issue. You must ensure that the group of users (admins) have Change permissions under the sharing tab and then minimum of Write permissions under the security tab.

    Depending how you connecting to the resource can affect things a lot and from what I can see its not actually a shared folder.

    Please let us know and we can assist further


    Tuesday, November 2, 2010 7:35 AM
  • Thanks for your reply Tim, did you read the question? Obviously I was not clear enough.

    As I pointed out in my original question, I am having problems when accessing files from the interactive console, accessing the files locally through direct file path with Explorer to the C drive. When logged in locally to the server there is no reason why anyone should be trying to access local files through a share - we access them locally and directly, not through a share of any type. This is a part of the administrative tasks for the application, editing these files needs to be done whilst making changes to the system. The problem we are having is with local access to local files where we have all the access permissions specified that we should be able to edit the files.

    As stated in my original question, it works fine when accessing it remotely through the administrative share (C$) when using the same accounts, from a remote Windows XP or Windows 7 desktop, or from a remote Windows 2008 R2 server - they all work and the user is able to edit the text file.
    I have re-tested your strange approach of accessing the file through an administrative share locally on the server back to itself - and with the Windows 2008 R2 server it results in access denied. It is therefore evident that this is not a permissions issue and is related to something within the console of the server.

    As stated in my original posting, this is not "purely a permission issue" as I stated that the users who are having problems editing the file have FULL AND TOTAL access specified in the security tab of the folder and the file itself. The users are a member of the local administrators group and the local administrators group HAS got Change and Write. You will also notice that the SUBJECT line of THIS POSTING shows that we have full control over the files. I also stated that we have used the Effective Permissions tab to analyse if a user has access to the file and folder, and these show that the user has Change and Write access, along with Full Control.

    Forget that I ever mentioned shares as it has obviously confused you. Go back to the original statement that we cannot edit a file locally on the server even though we have full control over the file. Also we cannot create new files in the folder from Windows Explorer.

    Just to verify - similar problems occur on ALL of our Windows 2008 and Windows 2008 R2 servers - that is over 170 servers. This is not "purely a permission issue" and is not specifically related to an administrative misconfiguration or corruption.

    Can anyone assist - is there a hidden NTFS flag or a specification somewhere that the folder is "system" or otherwise set to prevent the administrator from using it? Attributes on the file don't show anything about it being system etc.

    MCP, MCSE, VCP, CCNA, CNE, 17 Years Experience in Windows Server operating systems (yes - from Windows 3.0, NT 3.51).

    Tuesday, November 2, 2010 11:04 PM
  • Hi Christian,

    Though you mentioned "don't want to switch off UAC and don't want to change ownership to an individual user on these files", I would like to know whether you tried to add one of the users to Security tab of the folder and give it full control, then logon the user to test?

    I just would like to know whether it is caused by UAC as users are actually working as standard users.

    Have you tried to "Run as Administrator" and type the admin password to access the folder?


    Shaon Shan| TechNet Subscriber Support in forum| If you have any feedback on our support, please contact
    Wednesday, November 3, 2010 9:24 AM
  • Thanks for the reply.

    For the parent folder for these text files, when we change security;

    • If the security on the folder is changed to add a specific user, then that user CAN change files.
    • If the security of the folder is change to add a group, then any member of that group is NOT able to change files.

    As best practice is to apply security based on groups, instead of individual users - we would like to be able to follow this instead of specifying 12 different administrators over the multiple directories and over a hundred servers where they need access.
    Is this configurable behaviour on the system? Why is this forcing us into poor practice?

    When using "Run as Administrator", we get the following;

    • If Windows Explorer is "Run as Administrator", the user can NOT change the text files
    • If Notepad is "Run as Administrator", then the user CAN change the files

    And we are not prompted to enter the administrator's password when we choose "Run As Administrator" - because we ARE administrator (as I have mentioned several times). It just asks for confirmation that we want to do what we have just asked to do (which in the case of Windows Explorer, is two right clicks or pressing Ctrl+Shift when clicking on the icon).

    So where are the inconsistencies? Is this something I can re-configure without screwing up my system and making it insecure and difficult to manage?

    Thursday, November 4, 2010 4:10 AM
  • Hi,

    "If the security of the folder is change to add a group, then any member of that group is NOT able to change files. "

    Here Group means a default group or a customized group? Have you tried to create a group such as named "admins", then add all 12 administrators accounts to the group, give it full control on the target folder?

    Here is the explanation of the UAC feature:

    User Account Control Step-by-Step Guide

    Shaon Shan| TechNet Subscriber Support in forum| If you have any feedback on our support, please contact
    Thursday, November 4, 2010 6:49 AM
  • Thanks for your reply.

    Yes, I have tried it with a built-in local group  - such as local "Administrators" group on the local server - a member of that group cannot change the files
    Yes, I have tried it with an AD group we have created - the "Database Administrators" group - a member of that group can change the files
    Yes, I have tried it with a default AD group - "Domain Admins" - a member of that group cannot change files

    So, this shows that the groups that exist on every system (Domain Admins and Administrators) are effectively useless and pointless and actually reduce a user's access - but if we create a new group (such as "New Domain Admins" and "Admins that actually works" and grant these groups to have access permissions through either local group policy or NTFS file permissions, then it will work EVEN IF THIS IS IDENTICAL to the existing inherent [no, apparently no longer inherent] rights that the local Administrators and Domain Admins are meant to get.
    Going back to my original posting, when we enter the username into the "Effective Permissions" tab, it shows that they are effectively capable of the Change permission - and this is derived from that user being a member of the "Administrators" group - but this has no effect on the actual rights of the user.

    Is there a patch for this? A fix to make rights and permissions actually take effect? Are the groups "Domain Admins" and "Administrators" broken? These specific groups don't work the same as in 2003...

    Thanks for the link to UAC basics for running applications in Vista - but what about modifying FILES. As I have said before, we don't want to switch off UAC or be forced into bad security practices to bypass this control - we just want the assigned permissions to actually work and take effect.


    Friday, November 5, 2010 1:49 AM
  • Hi Christian,

    First I can understand the confuse which caused by the change. UAC is first added in Windows Vista, which causes some changes like "pop up message keep occurs" and "permission settings works different" (as this case). Here is my personal understanding of the behavior:

    As I mentioned in previous reply, start from Windows Vista, as UAC is added, all accounts in Administrators group (except Administrator) are working as standard users. The differece is these accounts can "Run as Administrator" when needed, while standard users will need to input an admin account/password to do the job (or just be blocked).

    So when we add Administrators group to Security tab, it actually means "accounts included in the group can run as admin", or "the accounts are allowed to full control when run as admin" (this is my personal understanding). So if we disable UAC, accounts will able to access these folders directly as they are working as admin after UAC is disabled.

    If we add these accounts (directly or using a customize group), it means we allow these accounts to access as a standard user (my personal understanding), so we can directly access though UAC is enabled.

    UAC make the security become complex, but the starting point is for security.

    Thank you for your undertstanding.

    Shaon Shan| TechNet Subscriber Support in forum| If you have any feedback on our support, please contact
    Friday, November 5, 2010 7:35 AM
  • Not very helpful. Also showing that you have not understood the issue.

    I understand how User Account Control works and how the Administrator token is not granted to users unless they partake in the GUI-only response to elevate priviledges which prevents scripted or other non-user initiated actions. This is all good and this is why we don't want to switch off UAC - we consider it useful and appropriate.

    But - as I pointed out earlier - User Account Control only seems to be protecting members of the default groups; the local Administrators group. Any other group that is granted permissions over files and folders does not get any prompt for a request for elevation. Effectively this means that the only people who are protected are the members of Administrators - and all we need to do is simply create a new group and grant it rights - the we can bypass all UAC protection.

    That's what we will do. We will ignore the groups Administrators and Domain Admins and replace them with our own - then we can use rights and permissions in the way that worked before.

    Monday, November 8, 2010 12:05 AM
  • Hi,

    You can correct t hat if we add a user or a group to Security tab, we can bypass UAC.

    However to add a user or a group, you will need to be an Administrator first. So the step "add a user or a group to Security tab" means you gain permission to the user or the group to bypass UAC.

    Shaon Shan| TechNet Subscriber Support in forum| If you have any feedback on our support, please contact
    Monday, November 8, 2010 2:33 AM
  • Hi Christian,

         I am having the same problem in WS2008.  I have tried setting the UAC features "Behavior of the elevation prompt for administrators..." to "Elevate without prompting",  as well as disabling the "Run all administrators in Admin Approval Mode" within the UAC settings, with no luck.  No admin rights happen unless I use the local admin account.  I have not tried adding individual domain user accounts to the local admins group, as to me that is like you said, bad practice, and there MUST be a different solution, or Microsoft needs to address it.

    Basically the issue seems to be that server 2008 does not recognize the members of domain groups as 2003 did.   It seems if you log in with a local account, or even grant the "local" group of "everyone" to be members of the local admin group it works, but not a domain based security group such as domain admins.  Obviously I only added the group "everyone" with admin rights as a quick test and removed it, as that would completely circumvent the point of any security settings if that were the only way to accomplish this.

    Has anyone found a way to make 2008 respect or behave according to group policy (my domain admins are local admins members via Restricted Groups in Group Policy domain wide)?

    Could my current functional domain level be the cause?  I still have a couple 2003 r2 domain controllers and thus my functional domain level is 2003, maybe 2008 doesn't respect the older domain level's groups?

    Hey Microsoft, does a 2008 box recognize a 2003 functional domain level's security groups?



    Thursday, January 6, 2011 7:54 PM
  • I just have to add this discussion thread describes the EXACT scenario I experience too with Server 2008 & 2008 R2. UAC is enabled on the machines and we do not want to disable it. I connect via Remote Desktop to them and log in with a Domain Admin account. Whenever I tried to edit a file directly on one of the local drives (ie c:, d:) it says access denied. If I try and delete them, etc via Windows Explorer it says "administrator permission required". I look at NTFS permissions and Domain Admins and Local admins have full permissions to the drive and all subfolders and files. Effective permissions says I have full access for my specific account, which is a domain admin. I followed the idea in this thread and created a new AD security group "NEW Domain Admins" and added myself and other domain admins to it. Then went back to the server and added this special security group to the NTFS permissions of the drive with Full Access and inheritance. Wow! Now I can delete and edit files and folders without any problems. Basically it feels like this Domain Admins group is deprecated and not as powerful as it used to be.

    Rico Mundy

    Thursday, January 13, 2011 7:30 PM
  • I have to agree with seeing this inconsistency. Running WIndows Server 2008 R2, 64-bit. I have an .ini file that I need modify. The entire directory is set to allow local admins and domain admins full control. However, I cannot modify the .ini file. (I am a member of the domain admins group, and the domain admins group is also a part of the local admins group.) If I add my own domain user account to the directory with full control, voila, I can then modify the .ini file with no difficulty at all. Seems to be a strange "feature" in 2008 R2. Sean
    Wednesday, March 2, 2011 8:27 PM
  • Reghack to "fix" this, without having to turn off the UAC for admins:

    "This happens because the fact that Explorer.exe cannot be elevated the normal Windows Explorer does not see that the user account should be able to access that folder. It is easy to verify as you can actually run Explorer.EXE elevated by changing the registry setting “RunAs” to “_RunAs” in HKEY_CLASSES_ROOT\AppID\{CDCBCFCA-3CDC-436f-A4E2-0E02075250C2}. Thanks goes to Andre Ziegler for this finding."

    I tested it, and it works when you launch Windows Explorer as admin. (Something you couldn't do before modifying the registry value)

    Andreas Hultgren

    Saturday, March 26, 2011 11:09 AM
  • I don't believe that the registry hack is required to do what you recommend, there are two alternative techniques;

    1. Go to Start, type explorer, right-click on the Windows Explorer search result and choose to Run as Administrator

    2. If Windows Explorer is docked to the task bar, right click on the icon - it will show pinned/frequent items and an icon near the bottom for Windows Explorer - right click on that icon to get a further menu to be able to Run as Administrator.

    This second technique (two right clicks) can also be applied to most other docked items (I use it for PowerShell and Internet Explorer - but it does not work for Office apps).

    But, this was not my issue - my problem is that accounts that should have inherent rights (i.e. those that are members of Local Administrators and Domain Admins) get less rights than those that have been directly added to a folder.

    Monday, March 28, 2011 9:21 AM
  • I have been having an issue that seems to be related to this post. Even if it is an old one I hope this helps admins understand a possible cause to this issue. I have not resolved my issue yet but after weeks of searching this following post on a blog explained the situation which I now believe is my issue.

    I am running Windows 8 and it seems there was an upgrade to ntfs.sys version which windows server 2012 may also have. Files created in older version are not able to be properly read at file sizes over 32kb. This fits my issue exactly so I hope there may be someone that can offer a possible solution. I have already reset ntfs permissions entirely and even formatted and reinstalled Windows 8 pro on my primary SSD.  The issue only occurs on files within my basic extended partitions. The files were created with my Windows 7 and Windows 8 consumer preview. They may have accessible after my initial RTM install and issue began after a system refresh using the new Windows 8 feature. On files that I can fully access the attributes are "A" with full control and the corrupted files over 32kb have attribute of "APL". I cannot change any permissions manually as the "edit" or "change permissions" buttons have the UAC logo over them and options greyed out. Even using tools to auto take ownership or change attributes fail. If I delete files using the "shift" right click function the file perminatley deletes and cannot recover them and the hard drive free space does not seem to increase.

    Also, under the system volume information (full path: "L:\System Volume Information\Dedup\ChunkStore\{85DE4A9A-B138-4F5E-9419-D87CC6934A83}.ddp)\Data" system folder there are 1,668 .ccc and .cd files. the .ccc files are over 1GB in file size and am hoping that my files are all here and able to somehow restore.

    Quoted text w/out screenshots

    "I read somewhere that Windows 2012 deduplication is not part of a new NTFS version, but it is instead a sort of a engine which is layered on the file system. To test this I decided to mount a NTFS-Windows-2012-deduplicated-external-USB-drive on a Windows 2008 R2 server (which since Windows XP has the same NTFS version, 3.1). 

    If the initial statement is right and the NTFS version is the same, I should be still able to read this external deduplicated drive with Windows 2008 R2. My test revealed this to be true. I can see the USB drive and browse its folders but, when I try to open any file bigger than 32 kbytes, I get the following error message:

    Now if I check with Powershell the attributes of any of these files stored on the deduplicated drive and whose size is larger than 32KB, I get:

    Get-Item 40kb.txt | select Attributes | fl
    Attributes : Archive, SparseFile, ReparsePoint
    On smaller files, only the 'archive' attribute is present:
    Get-Item 20kb.txt | select Attributes | fl
    Attributes : Archive
    So, the attributes of a deduplicated file are: sparse and reparse point.

    I thought it would be useful to share my experience on this in case somebody need it."

    Friday, January 18, 2013 7:54 PM
  • Hi, this was certainly useful to me. Originally I had a Windows Server 2012 server which I had been experimenting with Storage Spaces and deduplication. After rebuilding to Windows Server 2012 R2, I had an entertaining time getting the Storage Spaces reattached; I discovered the IsManualAttach defaulting to true for imported virtual disks (Powershell Get-VirtualDisk). I was then still getting 0x80070780 errors accessing the data an a couple of drives. Adding the deduplication feature has solved that error, thanks.
    Saturday, May 31, 2014 9:38 AM
  • I couldn't' figure out why my share, which had sharing and security permissions set for a specific user, was denying this particular user (even Admin group) to not be able to make changes to the directories. 

    What I found is that by re-creating the share (for me, it was creating a single share out of the larger shared directory to a single folder), added the permissions for the user in security and sharing, and then I browsed to that share through Network (bypassing the original share) logged in as the user on a separate VM (as was originally attempted), accessed the share (via Network or browser), and was able to make the modifications needed. 

    Just to put this into more perspective, this share is between two servers (1 physical "C:" and 1 VM on the same machine, but VM and VM share are both in the SAN "D:").

    I was trying to access a folder to, let's say, D:\parent\subfolder. I tried enabling the permissions for security and sharing on the subfolder, then parent, and, finally, disk level, each without success. 

    What I did was created a new share for "subfolder", and now when I browse to it, instead of going D:\parent\subfolder, I can just go D:\subfolder (this would be similar to \\COMPUTERNAME\subfolder instead of \\COMPUTERNAME\parent\subfolder), which let me make the modifications needed.

    On a side note, do you know if you're using file-system encryption? I enabled this on an external HDD a few years ago, and unless I had the keys installed in my private store, I wasn't able to even copy data from it.
    • Edited by Tyler Scafidi Saturday, September 16, 2017 12:56 PM to add more detail.
    Saturday, September 16, 2017 12:43 PM