Tech Blech

Monday, September 10, 2012

Undeletable Files on NTFS File System

Maintaining a web server on Microsoft Windows Server 2008 has mostly been straightforward and not very time-consuming.  But recently I was confronted with a small but extremely annoying hassle, having to do with 3 files within the web server's area that could not be read, could not be deleted, and could not even be included within a .zip file.  It was this last issue that first got my attention; I had been accustomed to .zip up the entire wwwroot area from time to time to ship it off-disk as a backup.  This began to fail.

I knew right away that I had introduced the problem while attempting to administer permissions on Pmwiki, a third-party application written in PHP that was never intended to run on a Microsoft web server.  Permissions for the upload folder kept reverting so that uploading attachments to the wiki failed, and it was while wrestling with this periodically recurring conundrum that I shot myself in the foot by somehow removing my ownership of those three files.  To get around this boondoggle, I had made an entire new upload folder (from a backup), and just renamed the old "stuck" upload folder.

Then, the next time I tried my handy .zip-it-all-up backup trick, I got an error.  The error, of course, happened right at the end of a long .zip process, and the entire archive failed to be created.  I now had no off-disk backup happening, all due to these three "stuck" files, which I could see in the folder, but which I could neither read, delete, nor could I change permission on them.  How anyone could deal with such problems without Google, I cannot imagine.  Thank the universe for search engines.

Within minutes of beginning my search, I found this support page on Microsoft's site.  At the very bottom, I found what I needed, which was the "if all else fails" strategy, which Microsoft called "Combinations of Causes" (that gave me a chuckle).  This strategy required me to use a utility called "subinacl.exe" which the support page cited as being part of the Resource Kit.

Googling some more, I soon found that the Resource Kit was a very expensive (as in $300) book with tools on a disk in the back.  I wasn't going to buy it.  Then it occurred to me just to search for "subinacl.exe", and thankfully, I found that Microsoft had made it available as a download.  So I downloaded it.  But idiot that I am, I failed to note where it had installed itself (somewhere obscure, I promise you).  Had to uninstall it, and then reinstall, this time noting down the install location, which for those of you going through the same thing, I will state here was C:\Program Files\Windows Resource Kits\Tools\.

So then I took a deep breath, constructed the command line that I needed in Notepad, then opened a command window, browsed to the obscure install folder shown above, and carefully pasted my unwieldy command into the window, then (holding my breath), I hit return.  A frightening amount of techno babble appeared as the command executed.  After a few tries, I got it to succeed, though it still gave warnings.  I had to do this four different times, once for each file and then for the containing folder.  The model command line is:

subinacl /onlyfile "\\?\c:\path_to_problem_file" /setowner=domain\administrator /grant=domain\administrator=F

View this joyful output here:
command window

Altogether, the failures of Pmwiki and Microsoft file permissions have indeed cost me hours of hassle over the five years while I have managed the server.  This latest offense was just the crowning jewel.  Managing file uploads on IIS is a challenge at any time, as the web server really is leery of anyone writing into a file zone that it serves.  But this doggy PHP open source piece of software (Pmwiki) that was tested only on Linux is, in retrospect, hardly worth the effort.  I haven't tried installing other wiki software yet (no time for the learning curve!) but surely I hope there might be another one that works better than this when running on a Windows server.

Microsoft's support page did do the trick.  The problem shouldn't be possible anyway.  The big Administrator account should always be able to delete a file--what were they thinking?--but at least they provided the necessary utility to dig myself out of the pit. Still, I'm not exactly feeling kindly towards Microsoft at this moment.  Or towards Pmwiki.


Post a Comment

Links to this post:

Create a Link

<< Home