Bitcoin Core 'unable to open file' causes reindexing to fail
An exhaustive survey of Google searches relating to the failure to read blknnnn.dat files implicated data corruption on the hard drive or in files such as wallet.dat and/or blknnnn.dat.  In my case, however, I was able to rule out these factors.  I ruled out hard drive failure by using a clone of my virtual machine that ran on a substitute hard drive.  I also ruled out corruption in wallet.dat by reindexing a substituted wallet.dat that had recently worked fine.  In this case the file that could not be opened was blk1637.dat. After about four unsuccessful reindexing attempts, I looked at the file permissions for the defective block and noted that file permissions were only allowed for root user. Prior blocks were permissioned for a non-root user.  The obvious solution to this lack of uniformity in file permissions was to conform the file permission settings of the errant file, but alas making this change and then reindexing the chain did not work, for the same failure to open the block file happened again.  I noted a comment someone made in a Google search that init.cpp in the client software used the umask command to change file permissions for the block files.  Using the sudo command saved me in this situation.  After all, I have everything contained within a virtual machine environment and this security risk was nominal.  In the appropriate folder, I ran sudo ./bitcoin-qt, waited for it to catch up with the syncing, then I started up Armory.  Ordinarily, using sudo in order to force a resort to root privileges is not a good idea.  But in this case it enabled me to transfer my bitcoin to a hardware wallet, freeing me up to run a new node on a virtual machine where the block data files have a consistent 6 0 0 file permissions setting unaltered by an errant system shutdown.