Member Avatar for noorahch

Main_Error.png

scree_2.png

screen1.png

scree_3.png

Hi,

My windows 7 laptop died due to some reason yesterday won't start so I took the hardisk out and made an external drive, atleast everything in the drive and desktop etc all accessable apart from these files / one folder which I really need the most lol as it has my passwords saved inside. But won't let me open it! I tried with everything but adding permission to everyone etc etc but still no luck can any body guide me on this please? the folder / files were never password protected orignially at my laptop. four screenshots added thanks !!!

  • 3 Contributors
  • 2 Replies
  • 250 Views
  • 1 Hour Discussion Span
  • Latest Post Latest Post by Reverend Jim

Dani AI

Generated

This is a common NTFS ownership/ACL vs. encryption problem when a drive is moved to another PC. ’s note that most files are readable but one folder is not strongly suggests either (a) the folder is still owned/locked to the original Windows account or (b) the files are encrypted (EFS or app-level/DPAPI). ’s advice to check attributes and ’s admin/Linux suggestions are on target — the steps below expand those ideas with concrete, safe actions.

Open an elevated Command Prompt on the machine with the external drive (replace X: with the actual drive letter) and take ownership, then grant full control to the Administrators group:

takeown /F "X:\Path\To\Folder" /R /D Y
icacls "X:\Path\To\Folder" /grant Administrators:F /T

takeown makes the running account the owner; icacls updates the ACLs so administrators can open files. Use quotes if the path contains spaces.

Check for encryption and attributes next. Encrypted (EFS) files often show as green names in Explorer or have Properties → Advanced → “Encrypt contents to secure data” checked. Many browser or password-manager files are additionally protected by DPAPI or an application master password; copying those files alone will not decrypt saved passwords on a new machine.

To inspect attributes and rule out hidden/system flags or corruption, run:

attrib "X:\Path\To\Folder\*.*" /S

If permission fixes don’t work, a quick disk health check can help (chkdsk X: /f), and a Linux live USB can read NTFS data ignoring Windows ACLs (useful for copying) — but Linux won’t decrypt EFS/DPAPI-protected content. If EFS is involved, recovery requires the original user’s EFS certificate/private key (a .pfx backup or export from the old profile); without it the encrypted files cannot be decrypted. Recommended sequence: confirm drive letter → takeown → icacls → verify encryption type → recover EFS cert or use original user profile to decrypt.

Recommended Answers

All 2 Replies

Member Avatar for rproffitt

There's more to this than what is revealed above. Files can be set READ ONLY and all you shared above would be true yet you get an error message.

Get to the command line (it's been with us for what?, over 3 decades) and check out what the file's Attrib output reports.

Also, accessing other user's files can cause this. Even moreso across a network share. You have more to look into if your login is not "x0r".

Edited by rproffitt because: Spelling fix. Attib was not right.
Member Avatar for Reverend Jim

The first thing I'd try is opening a command shell as Administrator and see if you can access the files. Failing that you can (still as admin) go to the root of the drive and type

cacls * /e /t /g everyone:f

/e = edit the ACLs (instead of replacing them)
/t = apply the changes to all sub-folders and files
/g = grant permission

If you don't want to muck with the ACLs then you could create a Linux Live CD or USB (google it) and boot off it. You should be able to get at all the files from there.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.