Awx: Can't go to Settings page. Nothing happens

[blindrood]

ISSUE TYPE

• Bug Report

SUMMARY

Can't go to Settings page, or any subpage of Settings

ENVIRONMENT

• AWX version: 9.0.1
• AWX install method: docker
• Ansible version: X.Y.Z
• Operating System: Win
• Web Browser: FF, Edge

STEPS TO REPRODUCE

Log in as account with full privileges. Click on settings or subpage of settings

EXPECTED RESULTS

I should reach settings page

ACTUAL RESULTS

A gear shows up for a moment and nothing more happens

ADDITIONAL INFORMATION

Settings data reading and updates still works through API so looks like UI issue

[ryanpetrello]

@blindrood do you see any errors in your browser console?

[blindrood]

This appears upon login. No errors in console, when clicking 'Settings'

[shanemcd]

Are there any hints in the logs for the web container? Can you also confirmed that you are logged in as an admin? I just installed a fresh 9.0.1 and I cannot reproduce.

[blindrood]

I can go to api/v2/settings/system/ and update values so yeah, I confirm I'm admin.
My installation is an upgrade from 9.0.0. I'm not sure if this worked in 8.0.0 or 9.0.0 as there was no need to look at that page.
but yeah.. looking at logs in container...

2019/11/13 15:15:45 [crit] 134#0: *16487 open() "/var/lib/nginx/tmp/uwsgi/6/03/0000000036" failed (13: Permission denied) while reading upstream, client: 192.168.195.26, server: _, request: "OPTIONS /api/v2/settings/all/ HTTP/1.1", upstream: "uwsgi://127.0.0.1:8050", host: "myhost", referrer: "http://myhost/"

I can see data in api/v2/settings/all/ and can't edit
But I think that's only display of all, right? I still can edit via API subelements e.g. /settings/system or settings/ui

[jon-rei]

Regarding the permission denied error I have faced a similar issue in #5230
Setting the permission to nginx:nginx for /var/lib/nginx or rebuilding the container fixed the issue.

[blindrood]

I can confirm that executing below in awx_web container

chown nginx:nginx -R /var/lib/nginx

resolved issue

PS. Next I did rebuild containers from scratch and issue did not come back
I suspect some upgrade step might caused this

[mattch3wie]

+1 for the tracker. Saved myself a heap of time trying to figure out why I couldn't get to settings!

[balonik]

Same issue when upgrading from 8.0.0 to 9.1.0. Running the chown command above fixed the issue.
It happened only on 1 of our 2 instances.

Error from awx_web container below:

2020/01/17 08:07:23 [crit] 137#0: *168 open() "/var/lib/nginx/tmp/uwsgi/0/01/0000000010" failed (13: Permission denied) while reading upstream, client: 192.168.0.100, server: _, request: "OPTIONS /api/v2/settings/all/ HTTP/1.1", upstream: "uwsgi://127.0.0.1:8050", host: "example.com", referrer: "https://example.com/"

[blindrood]

The same issue appears upgrading 9.0.0 to 9.3.0, although issue was with browsing jobs. Applying permissions on awx_web container solved it

[arymkus]

Same in 11.2.0
docker exec -it awx_web bash -c "chown -R nginx:nginx /var/lib/nginx" fixed the issue.

[sumkincpp]

Same in 12.0.0, changing permissions solved problem.

Problem most likely was with upgrade from 11.2.0 to 12.0.0.

[alexsuppanz]

Confirm the issue is also in 12.0.0. Happened after the upgrade vom 11.0.0. We have configured Satellite as dymanic inventory source and we were also unable to open the "Hosts" Section in the inventory.

Resetting the permissions as described above solved the issue.

[ryanpetrello]

@shanemcd you have any ideas on this or #7406?

I've never been able to reproduce this, and am a little stumped.

[tomsnijkers]

I think this issue can be closed. This happened to me couple of times, every time after "upgrade" ( from 11 to 14): I basically just rerun the playbook on a new branch (label). I think instructions could be changed to start with : remove all previous containers :) and not just rerun playbook of the installer

[Nascentes]

Just noting that we hit this issue on an upgrade from 9.x to 15.0.1. Setting ownership to /var/lib/nginx to nginx:nginx in the awx_web container also fixed the issue for us.

[ephracis]

I am seeing this in both 15.0.1 and 11.2.0 when deploying on a completely new machine (no upgrade).

Running chmod after the container is started fixes it but it this is a WO and not a proper fix. What if my container restarts?