The transition to NetApp MS Azure AD B2C is complete. If you missed the pre-registration, you will be invited to reigister at next log in.
Please note that access to your NetApp data may take up to 1 hour.
To learn more, read the FAQ and watch the video.
Need assistance? Complete this form and select “Registration Issue” as the Feedback Category.

Active IQ Unified Manager Discussions

Too Many HTML Connections Message


When trying to access a controller through System Manager, I am getting the message "Too many HTML connections".  Has anybody else seen this?  Is there a way to determine who or what connections are connected to the filer through http or https?



We just had this problem last week on one controller within a FAS-3240 running 8.1.3/7-Mode.

The fix for us, in this instance was to put the controller into maintenance mode within Microsoft System Center Operations Manager (SCOM), after which the connections dropped to nothing. We use the Quest QMX product in conjunction with SCOM to monitor the filers.


Had this issue this morning.  Setting the httpd timeout to 30 and min connections to 1, then back to their default values fixed the issue for me.  I am monitoring to see if we actually have hit this bug or not, but so far the counters are not increasing again.  Thanks to all who contributed to this post for suggestions.


hi, this solutions doen't work in my case ... FAS3170 NetApp Release 8.1.1P1 7-Mode


Hi All,

Just to confirm that Thomas's fix has also worked for me.


Hi All

We run yesterday in the same Problem with 8.0.2P3 and OnCommand 5.0.. Our Solution (short Version) was to set following Option in DFM:

dfm options set snapDeltaMonitorEnabled=no

Hope this help others to fix the Issue




Hi Thomas

It seems like the mentioned workaround has solved the problem for us. Thank you!

kind regards,



Hi adrian

Good news from you.. Its a good thing that we have the possibillity to help each other in the community :-)..



hi, this solutions doen't work in my case ... FAS3170 NetApp Release 8.1.1P1 7-Mode


-sh-3.2$ dfm options set snapDeltaMonitorEnabled=no

Changed enable snapshot-delta-info API use to 0.


Applied the change to our DFM server and will see if this fixes our problems.

Thanks for the tip!


Many thanks for updating us with your findings..
I dont want to tempt fate, but since setting;

dfm options set snapDeltaMonitorEnabled=no

We haven't had an SMVI failure and httpstat -s is at 0 every time I have checked it.

I'll let you know if anything changes.



Not even 1 week after implementing this workaround, SMVI has started misbehaving again. Sporadic snapshots being taken at odd times and jobs being stuck in the VC task list for 12 hours+

It's definitely better than it was, but is still not reliable enough to call it a fix.

Hoping 8.1.2 will bring better results....



I would suggest two things.  First, open a technical case for SMVI.  Let's ensure SMVI isn't having a unique problem outside of this issue.  Second, take a look at the auditlog file in the /etc/log directory.  It takes a little massaging, but you can pull the different HTTP connections that occurred in the log.  Are they all expected connections from all expected source IP addresses?


Can everyone who has posted here ensure that 1) you have a support case with NetApp that reflects this problem and 2) that the support engineer has associated the case with this bug (552607)?  The cases associated with a bug are visible and weighted in the details the engineering team sees and helps in the decision making process on release.  Thank you.


@ Chris..  Over a year?  That's absurd.  Your sales rep should be buying you the cake (as well as a steak dinner!)

I'll try dropping mine down to 512 (currntly I believe I've got it set to 1023)..  but I don't think it's going to matter.  I watched this on/off for a day a couple of weeks back and it kept bouncing up and down.


Yeah, first reported on 16/09/2011 to netapp after we upgraded from 7.3.2 to 8.x ... Their advice then was to raise the httpd.admin.max_connections to 1023.

Been ongoing ever since.

Dropped it back down to 512 now and will see if makes any difference...


I dropped mine down and it made no difference.  Initially I could get into the GUI, but then it would go unresponsive and that was the end of the show...


Hey folks,

I am working with one of the customers that hit BURT 552607. I just got an update from NetApp Support that the fix will be in ONTAP 8.1.2, and they are also pushing for an 8.1.1 P-release to include the fix.




Hi Ben,

Are you able to confirm that this issue has been resolved  in DOT 8.1.2 RC2 ?





Appreciate the update.  Are you a NetApp employee?

While the fix will be welcome, I want a specific technical reason for this issue.  I've got approx 2.6 Pb behind V-series and another couple 100 Tbs of NAS filers.  An upgrade to Ontap version X isn't something I can just decide to push out in a day or two...  These are client facing filers and maintenance windows are few and far between.





I am a NetApp partner, and have been working with my NetApp counterparts to get this issue escalated on my customer's behalf. The reason it is so critical in my customer's case is that when this problem happens, SMVI (AKA VSC) snapshot jobs fail, because it too makes calls to the NetApp via httpd.

The basic explanation I got from Support is that a legacy API call is being made to httpd, which does not properly handle/clear connections. The fix will allow the connections to timeout/clear out properly without hitting the max connection threshold.



NetApp on Discord Image

We're on Discord, are you?

Live Chat, Watch Parties, and More!

Explore Banner

Meet Explore, NetApp’s digital sales platform

Engage digitally throughout the sales process, from product discovery to configuration, and handle all your post-purchase needs.

NetApp Insights to Action
I2A Banner