IPython Permission Denied

Question

I'm encountering a problem starting an ipython notebook or an ipython console in spyder that results in the error message "Assertion failed: Permission denied (......\src\err.cpp:247) and (in ipython notebook) the kernel endlessly restarts.

I'm using Anaconda installation of python on Windows 7, and have the same problems with both ipython 1.1 and ipython 1.0. I did not have this problem when I ran ipython versions before 1.0, before I switched to Anaconda.

A google search finds another instance of this problem, which suggests that its due to interactions with PyZMQ and a firewall. I've tried adding specific exceptions for python and ipython to my firewall, and turning the firewall off completely, with no change. I can run ipython in command line, but neither the notebook or the console in spyder work (giving the error above.)

Any information about this would be helpful. I couldn't find any file err.cpp in any folder \src\ in my python installation, so I can't confirm what triggers the error has any relation to PyZMQ or firewalls. No change is made when turning off the firewall or elevating the command prompt. What else can I try?

Answer 1

I realise this is two years old, but I've just been able to sort out a similar problem, so it would have been good to see more answers to this.

In my case it wasn't the Windows Firewall or virus scanner, but that my employer's IT services group runs VNC over the same port that is hardcoded into 0MQ, as used by iPython in Anaconda.

Enough people complained that IT provided a script to move the VNC port for affected people, while also logging the change in their own records, so everybody is happy.

Try doing a "netstat -ab" from the command line, and check if anything is listening on port 5905, which iPython needs (at least as it is in early 2016, with Anaconda). You'll need to use "Run As Administrator" with cmd. If you can't do that just use "netstat -a". The difference is the b option will also list the process that has taken the port, and in our case we see vncserve.exe there. But -a is enough to see listening ports.