@Michael_Arthur Welcome to the Rockstor community and well done on finding/sharing your fix.
Yes sorry this is me dropping the ball. Had discovered this, whenever we add database tables, and thus need a migration, a reboot is required (we do the migration in the rockstor-pre service). I’ll get to starting a new release notes forum thread soon where we can document such caveats.
Essentially 3.9.2-39 introduced:
[ ] 0005_auto_20180913_0923
and 3.9.2-40 introduced:
[ ] 0006_dcontainerargs
which was what showed up in yours.
For others to see which migrations they have in effect (should be all of the last section) execute the following:
/opt/rockstor/bin/django showmigrations
if the storageadmin section has any uncrossed entries then a reboot will sort it as we have an ordering bug where an rpm update fails to apply pending migrations. Only happens when we add / change the database such that a migration is necessary and that’s quite rarely these days but our last 2 updates each had one.
So pre 3.9.2-40 (in this case 3.9.2-39 as we see: “0005_auto_20180913_0923”)
/opt/rockstor/bin/django showmigrations
admin
[ ] 0001_initial
auth
[X] 0001_initial
[X] 0002_alter_permission_name_max_length
[X] 0003_alter_user_email_max_length
[X] 0004_alter_user_username_opts
[X] 0005_alter_user_last_login_null
[X] 0006_require_contenttypes_0002
contenttypes
[X] 0001_initial
[X] 0002_remove_content_type_name
django_ztask
(no migrations)
oauth2_provider
[X] 0001_initial
[ ] 0002_08_updates
sessions
[ ] 0001_initial
sites
[ ] 0001_initial
smart_manager
[ ] 0001_initial
[ ] 0002_auto_20170216_1212
storageadmin
[X] 0001_initial
[X] 0002_auto_20161125_0051
[X] 0003_auto_20170114_1332
[X] 0004_auto_20170523_1140
[X] 0005_auto_20180913_0923
and post:
/opt/rockstor/bin/django showmigrations
admin
[ ] 0001_initial
auth
[X] 0001_initial
[X] 0002_alter_permission_name_max_length
[X] 0003_alter_user_email_max_length
[X] 0004_alter_user_username_opts
[X] 0005_alter_user_last_login_null
[X] 0006_require_contenttypes_0002
contenttypes
[X] 0001_initial
[X] 0002_remove_content_type_name
django_ztask
(no migrations)
oauth2_provider
[X] 0001_initial
[ ] 0002_08_updates
sessions
[ ] 0001_initial
sites
[ ] 0001_initial
smart_manager
[ ] 0001_initial
[ ] 0002_auto_20170216_1212
storageadmin
[X] 0001_initial
[X] 0002_auto_20161125_0051
[X] 0003_auto_20170114_1332
[X] 0004_auto_20170523_1140
[X] 0005_auto_20180913_0923
[ ] 0006_dcontainerargs
Where there is an uncrossed “0006_dcontainerargs”. And as this is in the Rock-on code area, when navigating to the Rock-on page and attempting something one would in this case get as you indicated:
But post reboot (or ‘systemctl restart rockstor-pre’) we have:
/opt/rockstor/bin/django showmigrations
...
storageadmin
[X] 0001_initial
[X] 0002_auto_20161125_0051
[X] 0003_auto_20170114_1332
[X] 0004_auto_20170523_1140
[X] 0005_auto_20180913_0923
[X] 0006_dcontainerargs
and our prior attempted actions within the Rock-on page now succeed.
I’m unsure if this fully accounts for your experience but it look pretty close and I appreciate that you rebooted but it may have been an update was applied there after.
Anyway hope that helps and apologies for the inconvenience. Rockstor has quite a few moving parts and at least in this case (and a few others 
) we have rough edges.
As to your web console output, you may find that a browser page refresh fetches the new code, sometimes older code is left and used in the browser cache. That’s my guess so far.
Thanks again for sharing your findings and for helping to support Rockstor development, and do check your output of the above ‘showmigrations’ command just in case.
