Here’s the simplest repro case possible.
I had a similar problem. I resolved it by adding the user to the public role. But if you didn't want to do that, I also found that it could be resolved by giving the user permission to the view sys.extended-properties (in System Views within the database that you're trying to access)
SSMS tries to get the extended properties of the table using fn_listextendedproperty. According to MSDN the required permisions to view a table's extended properties is
ALTER on table OBJECT
Your login test should have this permsision as owner of the test table (it is the owner, right?). But even if you don't have permissions on the table, the query for extended properties should return emtpy result set, not access denied. The fact that you get an access denied error on a sys object in the resource database indicates that the code signing of the system resource database (mssqlsystemresource) is broken. Did you drop any of the '##' certificates from master? did you manually altered any object in the resource database?
Anyway, you have a what looks like a corrupted instance at this moment and I'd recommend you contact product support on how to get it back into a coherent state.
"By creating the SQL server db with an account, that account is owner and has all needed access"
No need for further enhancements in permissions.
This approach removed the access error which this thread seems about. I encountered the access error in SSMS, as well as Visual Studio (EF), using windows authentication and having created the SQL server DB with the Administrator account.
Practical solution for me was :
SSMS > start as administrator, sql server logon : with windows authentication - NOT to create an SQL server db - but to give an account 'create db any' permission on 'master'
then SSMS logon with that account (that has 'create db any' permissions on master) - to create the (empty) database
(VISUAL STUDIO xtra : then, in visual studio, connect to sql server with that account and compare schema's between LocalDB (source) and sql server db (target). works out well : the target db gets the schema and data content)
Please check that you didn't check db_denydatareader
DB role. By removing that check it worked for me.
I had similar problem and resolved that by removing two roles db_denydatareader and db_denydatawriter for that user and add other roles. I used sql management studio.