Can't paste *.exe file inside Program Files folder

Will be posting here to provide solutions or workarounds.

And will try with another laptop. Trying to rule out hardware issues. I know it's redundant since a clean install was done and no error was obtained, but it won't hurt to try.

Thank you all in advance! Have a good night.

Take ownership of the folder this way. Don't miss a step. Taking ownership of files and folders on Windows 10

Savonarola said:

Or even try with the admin account

Click to expand...

This could be the total issue.

Porthos said:

This could be the total issue.

Click to expand...

Don't say it can't but makes little sense.

The @outlook account is admin.
The local user account is admin.
Can administrator have anything extra? It shouldn't, but since it's a non-active user, I'm going to activate it and see what comes out of this.

Gonna try this for documentation issues and if it doesn't work, proceed with @glasskuter solution.

Kudos for y'all!

FYI-Administrator is a system account. It's not a user account and doesn't work like a user account works. That's why it's hidden.

glasskuter said:

FYI-Administrator is a system account. It's not a user account and doesn't work like a user account works. That's why it's hidden.

Click to expand...

Well, what's it's funny is that supposedly, if a user is admin, it has the same privileges than the administrator account regarding the run as, for instance.

Members of the Administrators groups can run apps with elevated permissions without using the Run as Administrator option.

Click to expand...

@Microsoft

This is making little or no sense to me, since I had no problem with administrator plus clean install (just to be sure it can be done in mint state), but an account that is part of the same Administrators group had issues. It shouldn't since:

The first local user account that is created during installation is placed in the local Administrators group.

Click to expand...

Same link as above.

Usually, our laptops get an admin account created that allows them software installation, etc. They never had any issues, apart from some WSUS issues, but that's another story.

Either way, thank you all for your help. Will be resuming some more tests with this.

If all else fails, you can boot from one of the linux distros on bootable usb stick. Run it directly from the stick without installing it and copy the file you need. Linux doesn't care about permissions within a windows installation. I'm not a Linux fangirl but it has gotten me out of a few jams in the past when I was copying and pasting large numbers of files in a recovery operation from an old hard drive.

Well, had enough of tryouts and executed the set of instructions your link provided.

Perfect pitch there.

So far, no issues with this fix.

Tried to emulate this and I believe it's a software+admin mix. I just followed a similar procedure with a database file smash, in a folder, inside the Program Files, and no errors or similar behaviour.

Highly doubt it's the executable file 'cause I smashed an *.exe in the procedure and worked like charm.

My two cents...

Normally the folders inside Program Files and Program Files (x86) and all files inside them are created by Windows Installer with specific access rights like TrustedInstaller or System and should not be directly changed by user; ordinal User account doesn't have enough rights to create/copy or otherwise modify these parts of OS. It's a kind of protection against some malware or wrong manual actions of non-professional user. If you use the software which doesn't have any installer, like simple utilities or portable versions, it's supposed to install (copy) it elsewhere, like to a folder in %userprofle% or on any non-OS internal or external drive.

From my practice, however, I use specific areas for such files inside both Program Files and Program Files (x86), although it's not recommended for typical user. They are Program Files\OS and Program Files (x86)\Tools (I use these names by historical reasons). Both have Administrator rights (ownership and full control access) and I can copy, modify or delete the files inside as Administrator (note that User still doesn't have full control rights there). Tools is used for many 32-bit utilities like Rufus, Tcpview, Dosbox, Testdisk etc, while OS is used for a few 64-bit utilities like CPU-Z, Process Explorer, Process Monitor.

Irrespective of alleged piracy, even a user with admin privileges cannot just paste into Program Files directly. Windows will still ask you to elevate your privileges too (presumably to add those of SYSTEM et al. as well). Since user is in the admin group, said request will be honored, but you still can't paste automagically.

Question, though, is why? I've had portable software I stuck in Program Files once, just for good measure, that can indeed be udated by just clobbering over it. But normally, there's no real good reason to manually patch an .exe like that. But, as others have pointed out, if his user is admin, he should be able to paste into Program Files just fine.

Savonarola said:

Nope. Still here.

Click to expand...

Glad that you came back. People here (not everyone though) like to assume a lot of things.

Savonarola said:

executed the set of instructions your link provided.

Click to expand...

Glad it worked for you. I have had to resort to that method many times when trying to recover data from corrupted accounts or old hard drives that belonged to other people. When dealing with a lot of folders there's nothing fun about it. That's why I suggested the Linux method. Linux doesn't care about permissions. For years I've kept a distro of Linux on bootable media for no other purpose than file recovery. When one copies a file or folder to external media none of its permissions follow.