I had pretty much the same issue. Upgraded from Ambari 2.1.0 to 2.2.2. Performed the steps to upgrade the Ambari server database and everything worked except the Manage Ambari view was missing. If I used the URI http://server:8080/views/ADMIN_VIEW/2.2.1.1/INSTANCE/#/ I could access the view, and it would start showing up on my menu, but would be missing again when I next logged in. Followed the suggestion to look for permissions in the Ambari database and look for additional ones. In my scenario, there admin permissions looked like this. select * from adminprivilege where principal_id = 1; privilege_id | permission_id | resource_id | principal_id --------------+---------------+-------------+-------------- 1 | 1 | 1 | 1 52 | 3 | 9 | 1 From querying various tables I found that adminpermissions shows the properties for the permission_id, and the adminresource and adminresourcetype tables combine to show the resource_id properties. In my case the 2 permissions listed are: AMBARI.ADMIN permission on the AMBARI resource (the 1 1 1 1 adminprivilege row) CLUSTER.OPERATE permission on the CLUSTER resource (the 52 3 9 1 adminprivilege row). If I delete the CLUSTER.OPERATION permission (privilege_id = 52) from the adminprivilege table and restart ambari-server I can see the Manage Ambari permission again and admin seems to work properly. If I look at the backup I took of the Postgres database that I made before performing the upgrade, I can see that both of the permissions were there before the upgrade. It appears that the new version of Ambari (2.2.0 in my case) doesn't handle this combination of privileges properly. Just thought I would add some more detail as this looks like it could be an Ambari bug, and ideally, I'm assuming it isn't a normal thing to have to go into the Ambari database and manually delete rows in tables as I assume that making a mistake could likely corrupt the Ambari database. ... View more

I didn't know a possible solution might be to remove and re-add the Pig view. I tried this, creating a new view with the same settings as the old view, and that worked! Maybe there's some sort of bug with the Ambari upgrade that corrupted the Pig view somehow? At any rate, the new version of the Pig view works fine and does not produce the error message listed above. ... View more

I am getting pretty much the same error message. In my scenario, I recently upgraded from Ambari 2.1 to 2.2.2. I was getting other errors in the Hive and Pig views that I found articles suggesting they were fixed in Ambari 2.2 or later. The Hive view is working fine now, but the Pig view returns this error in the Ambari-server.log when you click on the Pig view. Here's a screenshot of the Pig View: Below is as much of the stack trace as I could fit. Service 'storage' check failed: org.apache.ambari.view.PersistenceException: Caught exception trying to store view entity org.apache.ambari.view.pig.persistence.SmokeTestEntity@65794478 org.apache.ambari.view.PersistenceException: Caught exception trying to store view entity org.apache.ambari.view.pig.persistence.SmokeTestEntity@65794478 at org.apache.ambari.server.view.persistence.DataStoreImpl.throwPersistenceException(DataStoreImpl.java:648) at org.apache.ambari.server.view.persistence.DataStoreImpl.store(DataStoreImpl.java:148) at org.apache.ambari.view.pig.persistence.DataStoreStorage.store(DataStoreStorage.java:55) at org.apache.ambari.view.pig.persistence.DataStoreStorage.storageSmokeTest(DataStoreStorage.java:135) at org.apache.ambari.view.pig.services.HelpService.storageStatus(HelpService.java:115) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at com.sun.jersey.spi.container.JavaMethodInvokerFactory$1.invoke(JavaMethodInvokerFactory.java:60) at com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$ResponseOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:205) at com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:75) at com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:302) at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147) at com.sun.jersey.server.impl.uri.rules.SubLocatorRule.accept(SubLocatorRule.java:137) at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147) at com.sun.jersey.server.impl.uri.rules.SubLocatorRule.accept(SubLocatorRule.java:137) at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147) at com.sun.jersey.server.impl.uri.rules.SubLocatorRule.accept(SubLocatorRule.java:137) at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147) at com.sun.jersey.server.impl.uri.rules.SubLocatorRule.accept(SubLocatorRule.java:137) at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147) at com.sun.jersey.server.impl.uri.rules.SubLocatorRule.accept(SubLocatorRule.java:137) at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147) at com.sun.jersey.server.impl.uri.rules.ResourceClassRule.accept(ResourceClassRule.java:108) at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147) at com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:84) at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1542) at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1473) at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1419) at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1409) at com.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.java:409) at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:540) at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:715) at javax.servlet.http.HttpServlet.service(HttpServlet.java:770) at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:684) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1496) at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:330) at org.springframework.security.web.access.intercept.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:118) at org.springframework.security.web.access.intercept.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:84) at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) at org.springframework.security.web.access.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:113) at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) at org.springframework.security.web.session.SessionManagementFilter.doFilter(SessionManagementFilter.java:103) at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) at org.springframework.security.web.authentication.AnonymousAuthenticationFilter.doFilter(AnonymousAuthenticationFilter.java:113) at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) ... Caused by: org.apache.ambari.view.PersistenceException: The class org.apache.ambari.view.pig.persistence.SmokeTestEntityis not registered as an entity. at org.apache.ambari.server.view.persistence.DataStoreImpl.getIdFieldName(DataStoreImpl.java:593) at org.apache.ambari.server.view.persistence.DataStoreImpl.persistEntity(DataStoreImpl.java:394) at org.apache.ambari.server.view.persistence.DataStoreImpl.store(DataStoreImpl.java:144) ... 96 more ... View more