'NoneType' object has no attribute 'get_absolute_url'

[f2ed]

I'm currently experiencing this issue and wonder if anyone has any insight in how to figure out the issue. The issue started after upgrading to 3.3.6, and has persisted through each subsequent upgrade from 3.3.7,8, and 9. I've tried a new install on a new server by doing a fresh install and importing the database with the same results. I haven't started with a clean database, as that seems like it would work, and I'm also not sure that I'd be able recreate the steps to reproduce the issue.

[markkuleinio]

Now, this is just a wild guess, but if I understood the error location correctly, my guess is that you somehow have IP address object(s) that have inconsistent assigned_object_id and/or assigned_object_type values. I see the error location (

netbox/netbox/ipam/tables/ip.py

Line 378 in db7590d

linkify=lambda record: record.assigned_object.get_absolute_url(),

) was added in 3.3.6 (53c9c3c) so the problem presented itself at that point.

I, for one, had that kind of data problems for some IP objects a long time ago, I detected and fixed them using the API.

[arnaud-asp]

Indeed @candlerb : the sql query got me the 3 culprit ip's, thank you very much everyone for the support!

[candlerb]

If that script doesn't find anything, then possibly you have an assigned_object_type_id and assigned_object_type which are both not null, but the combination is pointing to a non-existent object. Those are a bit trickier to find: there is a query at the bottom of #11726 (comment) which might help.

Also two more references:

• Custom script to fix addresses where one is null: https://github.com/netbox-community/customizations/pull/85/files
• Try the workaround here: 'NoneType' object has no attribute 'get_absolute_url' #11112 (reply in thread)

Using a variation of that workaround which (for example) raises an exception containing the IP address's primary key might identify the problematic IP address(es).

[markkuleinio]

I updated the API example code above to catch the other faulty condition as well.

[candlerb]

elif ip.assigned_object and not ip.assigned_object_type:

I don't think what you've written will work:

elif ip.assigned_object and not ip.assigned_object_type:

ip.assigned_object is an object; it will be None if either assigned_object_type_id or assigned_object_id is None. That's essentially what the actual problem is: record.assigned_object.get_absolute_url() fails because record.assigned_object is None. That means the condition above is never going to be true.

I think the whole thing just needs to be:

if ip.assigned_object is None and (ip.assigned_object_type_id or ip.assigned_object_id):

I might be wrong though: I'm thinking in terms of the Django ORM models, not in terms of REST API responses.

[markkuleinio]

Fair enough, edited the code again.

[PieterL75]

Just experienced the same thing here..
3 IP addresses that did not have an 'assigned_object', even though there was an 'assing_object_id' and 'assigned_object_type'
Looks like the IP was not assigned to an interface, but it was still 'primary ip' for that device

[bluikko]

Have this error also right now, after upgrading from 3.5.8 to 3.7.8 and then to 4.0.6.
This is an instance that has been upgraded from early v2 onwards.

SQL query in #11112 (reply in thread) gets 0 rows.
Running the script in #11112 (reply in thread) shows that all the thousands of IP addresses are invalid:

assigned_object_type is set to dcim.interface and assigned_object_id is set to 8733 (but assigned_object is null) in IP address 192.0.2.1/26

So I assume this could be fixed with a script since we do have at least assigned_object_id?

Somehow the upgrade database migration has messed up each and every IP address in the database.
I am very surprised that only a small amount of users have been hit with this problem.

[bluikko]

Aha! I didn't know it is just an accessor.

That lead me to disable the custom validator and everything works.
I guess something has changed in custom validators between 3.5 and 4.0, don't recall seeing anything in READMEs (but then again, the API version authentication requirement is not in READMEs either........)

Thank you for your time, and I apologize for kinda wasting it!

[candlerb]

Not at all. And if you can provide an example of how not to write a validator - i.e. a validator which messes things up in this way - that would be very useful to help others avoid the same problem. It might even be a bug in Netbox's interface for validators.

[bluikko]

I will definitely update after I get to the bottom of this.

Everything worked fine in 3.5.8. And going back to when validators released.

[bluikko]

Unfortunately it is not something simple with my custom validator.

I first turned back on all custom validators from configuration.py and commented out everything in the "suspected problem" validator function.
I enabled the validator function in small pieces and everything continued to work. The validator and configuration file are now exactly like they were before and everything continues to work. Validator works as expected and all IP addresses work.

I wonder if the validator could somehow interfere with upgrades?
After upgrade I did test that the validator worked: I edited one IP address through Prefixes to invalid data and checked that validator rejected the change, canceled out from the changes.
Only after this I checked any IP addresses, either assigned in Device Interfaces or IP Addresses table and nothing related to them worked.

Looking at all of this, I noticed that I did not restart the netbox/rq services after restoring the database from another 4.0.6 instance.
First restart was after disabling the validator. Which was dumb.
Perhaps this is the real reason. don't think I will have anything else to add to this issue, I have gone through everything.

[candlerb]

If it's just a question of forgetting to restart after modifying the database, then that's pretty clear. It would have been nice to see the nbshell and sql queries while the problem was still manifesting itself though. They probably would have shown everything was fine (since nbshell is its own process) and thus pointed the finger at something wrong with the webservice, like not being restarted.

[lono0778]

Hello,

actually i have a similar problem after upgrade to netbox 4.0.6 from 3.7.0.

When i modify a permission whit a JSON value i get the following error after clicking save:

Server Error

There was a problem with your request. Please contact an administrator.

The complete exception is provided below:

<class 'AttributeError'>

'NoneType' object has no attribute 'objects'

Python version: 3.10.12
NetBox version: 4.0.6
Plugins:
netbox_dns: 1.0.4
netbox_documents: 0.7.0
netbox_floorplan: 0.4.0
netbox_qrcode: 0.0.13

Any suggestions here?

Thank you