Right click the shortcut.
Click Security tab.
Click "Change" next to the shield icon.
Type your username and click Check Names to make sure that it is valid.
Right click the shortcut.
Click Security tab.
Click the Edit button.
Select your username (click Add button, type username, click OK if it doesn't appear in the list).
Check "Full Control".
As I said:" ...yes, I have tried fiddling with Securities tab ..". I am logged in as "on line user" with hotmail account. system is telling me I need to be off-line user with no microsoft account associated.
AFAICS adding my explicit user name does not work ...
Type "net user" into command prompt. See if you can identify your real user name.
I am logged in as "connected account". Connected to my hotmail account. And yes in security properties "Effective Access" tab I can see that I have all the rights and ownership of the said url files. But "Still no baby" ... System is refusing to change the "file properties".
"net user" is not listing any but to local user names.
But. I have noticed "something". "File Access Denied" messages are actually about the folder these two *.url shortcuts are in. Not the files.
And yes I have made sure I am the owner with full access rights to the folder too. But. Still the same problem. Can not change file propterties on theese url shortcuts.
If I create new file in this folder owner is this "Local" user" which indeed appears as admin "DefaultAccount" on this machine. AND me (the "connected" admin user I am logged in as) has the full access rights. Which is OK. But Windows 10 it seems has problems with changing "file properties" on these files? For example if I create new Word document (with a standard right click way) and then if I try to change (using file explorer "Details Pane") any of the file properties I get this error message:
Same error happens if I try File properties --> Details --> "Remove Properties and Personal Information" and then try to remove all properties.
So the problem is not just about *.url files.
I would recommend running sfc /scannow in an administrator command prompt. https://support.microsoft.com/en-us/kb/929833
Thanks, but. Issue is user name. Create local user (ie non connected account). Play around with files/folders. Then connect this same user with Microsoft account, and you will transform it into so called "connected account" .
Then go back to your files/folders. You will notice they are still owned by previous now non existing user.
Local Admin User: john-doe
Crete few files/folders . They are all owned by john-doe.
Connect john-doe with Microsoft account firstname.lastname@example.org. It becomes: (whatever) email@example.com
Go to previous files they are still owned by john-doe. Now non existent user.
I have no time for deep diving into this. Right now it seems it is a Win10 bug. (gasp!)
It also seems it imposes no obvious problems unless one tries to edit file properties (using file explorer) of files or folders owned by non-existent aka previous user (john-doe in this example) ...
Thanks for watching ...
Nevermind. In Command Prompt, type net user and press Enter then look for your old username. Type that into the Owner box instead of your first and last name and email.
Clarification for anybody else who dropped by here with a similar problem:
If you created an user as a local user, then signed into a Microsoft account on that user, you type your original username. So if I created a local account (I didn't sign into a Microsoft account or create one) and chose "TENFORUMS" as my user's name, then I decided to sign into a Microsoft account on TENFORUMS, my actual username is still "TENFORUMS" and I should type this when changing permissions on files, although my name may appear as what my first and last name is in the Start menu and logon screen, and in the permissions.
If you created a Microsoft account initially, your actual username is the first five characters of your email.
Well thank you for your clarification of my clarification but I think it was not necessary
This issue is now muddled over here and we/you should open a new thread with clear diagram for explanation.
of course other good people have noticed this issue too ...
And what about MSFT? This is yet another case of over engineering of otherwise clear solution (use user UID). To a self inflicted problem.
In any case this is not how modern OS should be coded. This is a BUG. And the clear indication of lack of UAT.