Deleting a user gives a IntegrityError for table secrets_userkey #6250

Closed
opened 2025-12-29 19:38:31 +01:00 by adam · 8 comments
Owner

Originally created by @falz on GitHub (Mar 23, 2022).

NetBox version

v3.1.9

Python version

3.8

Steps to Reproduce

  1. Go to /admin/auth/user/
  2. Check box next to user
  3. Action -> Delete
  4. On next screen, confirm 'Yes I am sure'

Expected Behavior

User would be deleted. Note this user was an admin in netbox (no longer employed) and likely played around with some features, like secrets (hence the error). All features tested would've been done via the proper web UI however.

See screenshot for what else it's deleting related to this user:

Screenshot from 2022-03-23 11-50-50

Observed Behavior

Error message:

<class 'django.db.utils.IntegrityError'>

update or delete on table "auth_user" violates foreign key constraint "secrets_userkey_user_id_13ada46b_fk_auth_user_id" on table "secrets_userkey"
DETAIL:  Key (id)=(4) is still referenced from table "secrets_userkey".


Python version: 3.8.11
NetBox version: 3.1.9
```
Originally created by @falz on GitHub (Mar 23, 2022). ### NetBox version v3.1.9 ### Python version 3.8 ### Steps to Reproduce 1. Go to `/admin/auth/user/` 2. Check box next to user 3. Action -> Delete 4. On next screen, confirm 'Yes I am sure' ### Expected Behavior User would be deleted. Note this user was an admin in netbox (no longer employed) and likely played around with some features, like secrets (hence the error). All features tested would've been done via the proper web UI however. See screenshot for what else it's deleting related to this user: ![Screenshot from 2022-03-23 11-50-50](https://user-images.githubusercontent.com/707319/159754355-08341c30-0097-4c47-8acb-649514fcdc67.png) ### Observed Behavior Error message: ```` <class 'django.db.utils.IntegrityError'> update or delete on table "auth_user" violates foreign key constraint "secrets_userkey_user_id_13ada46b_fk_auth_user_id" on table "secrets_userkey" DETAIL: Key (id)=(4) is still referenced from table "secrets_userkey". Python version: 3.8.11 NetBox version: 3.1.9 ```
adam added the type: bug label 2025-12-29 19:38:31 +01:00
adam closed this issue 2025-12-29 19:38:31 +01:00
Author
Owner

@jeremystretch commented on GitHub (Mar 23, 2022):

This error is occurring because your NetBox deployment was upgraded from v2.11 or earlier, and the tables from the old secrets app are still in the database. Upgrading to NetBox v3.0 or later does not automatically remove these tables, because users might still need the data (e.g. if installing the netbox-secretstore plugin).

Normally, when deleting a user, any assigned user key would be automatically deleted (via on_delete=CASCADE). That's not happening here because the model no longer exists.

I'm not immediately sure what the ideal solution is to be honest. As an immediate workaround, you can simply delete the offending row using the SQL shell (manage.py dbshell):

DELETE FROM secrets_userkey WHERE user_id=4;

Or, if you definitely don't need secrets anymore, just drop the whole table:

DROP TABLE secrets_userkey;

This will allow you to delete the user normally. I'll need to put some thought into a longer-term solution.

@jeremystretch commented on GitHub (Mar 23, 2022): This error is occurring because your NetBox deployment was upgraded from v2.11 or earlier, and the tables from the old `secrets` app are still in the database. Upgrading to NetBox v3.0 or later does _not_ automatically remove these tables, because users might still need the data (e.g. if installing the [`netbox-secretstore` plugin](https://github.com/DanSheps/netbox-secretstore)). Normally, when deleting a user, any assigned user key would be automatically deleted (via `on_delete=CASCADE`). That's not happening here because the model no longer exists. I'm not immediately sure what the ideal solution is to be honest. As an immediate workaround, you can simply delete the offending row using the SQL shell (`manage.py dbshell`): ```sql DELETE FROM secrets_userkey WHERE user_id=4; ``` Or, if you definitely don't need secrets anymore, just drop the whole table: ```sql DROP TABLE secrets_userkey; ``` This will allow you to delete the user normally. I'll need to put some thought into a longer-term solution.
Author
Owner

@falz commented on GitHub (Mar 25, 2022):

Thanks for the details. We were never using secrets outside of some playing around, so it's safe to purge. There are however 4 secrets tables, and another one is referenced when i attempt to purge that users' secrets_userkey contents.

netbox=> \dt secrets*
              List of relations
 Schema |        Name        | Type  | Owner  
--------+--------------------+-------+--------
 public | secrets_secret     | table | netbox
 public | secrets_secretrole | table | netbox
 public | secrets_sessionkey | table | netbox
 public | secrets_userkey    | table | netbox
(4 rows)
netbox=> DELETE FROM secrets_userkey WHERE user_id=4;
ERROR:  update or delete on table "secrets_userkey" violates foreign key constraint "secrets_sessionkey_userkey_id_3ca6176b_fk" on table "secrets_sessionkey"
DETAIL:  Key (id)=(1) is still referenced from table "secrets_sessionkey".

Not much in here:

netbox=> select count(*) from secrets_secret;
 count 
-------
     0
(1 row)

netbox=> select count(*) from secrets_secretrole;
 count 
-------
     2
(1 row)

netbox=> select count(*) from secrets_sessionkey;
 count 
-------
     1
(1 row)

netbox=> select count(*) from secrets_userkey;
 count 
-------
     1
(1 row)

Purge all four tables or should I DELETE FROM secrets_sessionkey WHERE id=1; first?

I'm also content to leave this user there if you have any type of non-db fix in mind for the future, I can test said fix out vs direct db manipulation - good either way.

@falz commented on GitHub (Mar 25, 2022): Thanks for the details. We were never using secrets outside of some playing around, so it's safe to purge. There are however 4 secrets tables, and another one is referenced when i attempt to purge that users' secrets_userkey contents. ``` netbox=> \dt secrets* List of relations Schema | Name | Type | Owner --------+--------------------+-------+-------- public | secrets_secret | table | netbox public | secrets_secretrole | table | netbox public | secrets_sessionkey | table | netbox public | secrets_userkey | table | netbox (4 rows) ``` ``` netbox=> DELETE FROM secrets_userkey WHERE user_id=4; ERROR: update or delete on table "secrets_userkey" violates foreign key constraint "secrets_sessionkey_userkey_id_3ca6176b_fk" on table "secrets_sessionkey" DETAIL: Key (id)=(1) is still referenced from table "secrets_sessionkey". ``` Not much in here: ``` netbox=> select count(*) from secrets_secret; count ------- 0 (1 row) netbox=> select count(*) from secrets_secretrole; count ------- 2 (1 row) netbox=> select count(*) from secrets_sessionkey; count ------- 1 (1 row) netbox=> select count(*) from secrets_userkey; count ------- 1 (1 row) ``` Purge all four tables or should I `DELETE FROM secrets_sessionkey WHERE id=1;` first? I'm also content to leave this user there if you have any type of non-db fix in mind for the future, I can test said fix out vs direct db manipulation - good either way.
Author
Owner

@jeremystretch commented on GitHub (Mar 25, 2022):

In that case it's safe to delete all four tables, which should resolve the issue for you. I'll still need to come up with something automated. We could probably introduce a migration that deletes the secrets_* tables if secrets_secret is empty.

@jeremystretch commented on GitHub (Mar 25, 2022): In that case it's safe to delete all four tables, which should resolve the issue for you. I'll still need to come up with something automated. We could probably introduce a migration that deletes the `secrets_*` tables if `secrets_secret` is empty.
Author
Owner

@falz commented on GitHub (Mar 25, 2022):

Seems sane, if that's on your radar to do soon i can wait to purge this and confirm whenever that migration goes live. If its not on current radar (2023+) ill perhaps manually purge tables.

@falz commented on GitHub (Mar 25, 2022): Seems sane, if that's on your radar to do soon i can wait to purge this and confirm whenever that migration goes live. If its not on current radar (2023+) ill perhaps manually purge tables.
Author
Owner

@jeremystretch commented on GitHub (Mar 25, 2022):

I would go ahead and do it manually; NetBox v3.0+ has absolutely no use for them anymore.

@jeremystretch commented on GitHub (Mar 25, 2022): I would go ahead and do it manually; NetBox v3.0+ has absolutely no use for them anymore.
Author
Owner

@falz commented on GitHub (Mar 25, 2022):

Was able to purge all four tables, order mattered as i wasn't able to delete secrets_userkey before one or both of the others. Showing details if it helps for future fixes.

I was able to successfully delete the probbo user after this from /admin/auth/user/

netbox=> DELETE FROM secrets_sessionkey WHERE id=1;
DELETE 1
netbox=> DELETE FROM secrets_userkey WHERE user_id=4;
DELETE 1

netbox=> DROP TABLE secrets_userkey;
ERROR:  cannot drop table secrets_userkey because other objects depend on it
DETAIL:  constraint secrets_sessionkey_userkey_id_3ca6176b_fk on table secrets_sessionkey depends on table secrets_userkey
HINT:  Use DROP ... CASCADE to drop the dependent objects too.

netbox=> DROP TABLE secrets_secret;
DROP TABLE

netbox=> DROP TABLE secrets_sessionkey;
DROP TABLE

netbox=> DROP TABLE secrets_secretrole;
DROP TABLE

netbox=> DROP TABLE secrets_userkey;
DROP TABLE
@falz commented on GitHub (Mar 25, 2022): Was able to purge all four tables, order mattered as i wasn't able to delete `secrets_userkey` before one or both of the others. Showing details if it helps for future fixes. I was able to successfully delete the probbo user after this from `/admin/auth/user/` ``` netbox=> DELETE FROM secrets_sessionkey WHERE id=1; DELETE 1 netbox=> DELETE FROM secrets_userkey WHERE user_id=4; DELETE 1 netbox=> DROP TABLE secrets_userkey; ERROR: cannot drop table secrets_userkey because other objects depend on it DETAIL: constraint secrets_sessionkey_userkey_id_3ca6176b_fk on table secrets_sessionkey depends on table secrets_userkey HINT: Use DROP ... CASCADE to drop the dependent objects too. netbox=> DROP TABLE secrets_secret; DROP TABLE netbox=> DROP TABLE secrets_sessionkey; DROP TABLE netbox=> DROP TABLE secrets_secretrole; DROP TABLE netbox=> DROP TABLE secrets_userkey; DROP TABLE ```
Author
Owner

@DanSheps commented on GitHub (Apr 8, 2022):

You could have used:

DROP TABLE `secrets_userkey` CASCADE

Which would have dropped both sessionkey and userkey

@DanSheps commented on GitHub (Apr 8, 2022): You could have used: ``` DROP TABLE `secrets_userkey` CASCADE ``` Which would have dropped both sessionkey and userkey
Author
Owner

@github-actions[bot] commented on GitHub (Jun 8, 2022):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Do not attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our contributing guide.

@github-actions[bot] commented on GitHub (Jun 8, 2022): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. **Do not** attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#6250