Listener not starting with TNS-00525: Insufficient privilege for operation

I recently got a listener that refused to start on AIX. The message it returned was:

Error listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC0)))
TNS-12555: TNS: Permission denied
TNS-12560: TNS: Protocol adapter error
TNS-00525: Insufficient privilege for operation
IBM/AIX RISC System/6000 Error: 1: Not owner

Checking the binaries and config files revealed nothing suspect – all were owned by Oracle. So I decided to try a truss:

truss -aefo result.txt lsnrctl start

Somewhere in the file I got my answer:

1785960: 1511613: access(“/tmp/.oracle/sEXTPROC0”, 0)   = 0
1785960: 1511613: connext(3, 0x0FFFFFFFFFFF77A0, 106)   Err#79 ECONNREFUSED
1785960: 1511613: access(“/tmp/.oracle/sEXTPROC0”, 0)   = 0
1785960: 1511613: _poll(0x0000000000000000, 0, 100)     = 0
1785960: 1511613: close(3)                              = 0
1785960: 1511613: socket(1, 1, 0)                       = 3
1785960: 1511613: connext(3, 0x0FFFFFFFFFFF77A0, 106)   Err#79 ECONNREFUSED
1785960: 1511613: access(“/tmp/.oracle/sEXTPROC0”, 0)   = 0

I checked in /tmp/.oracle/ and some files were owned by root (apparently someone tried to start the listener as root):

srwxrwxrwx  1 oracle dba    0 2011-05-27 16:46 s#200950.1
srwxrwxrwx  1 root   system 0 2011-06-29 10:25 sEXTPROC0
srwxrwxrwx  1 root   system 0 2011-06-29 10:25 s#1642742.1

I removed  the two files and was able to start the listener.

This entry was posted in listener and tagged , , , . Bookmark the permalink.

24 Responses to Listener not starting with TNS-00525: Insufficient privilege for operation

  1. Steve Edwards says:

    Thank-you for this! I’ve just spent a frustrating hour trying to work out why my listener wouldn’t start and came across your post – bingo!

  2. wmorrison365 says:

    Thanks, just pointed me in the right direction and spared me a few hours. In my case, it was upgrade patch files. I just chmoded them to allow group write. Thanks.

  3. Thankyou says:

    Thanks for this post (before searchig this wasted 20 mins)

  4. Arun says:

    thanks again saved a lot of time !!!!!!!!!!!!!!!

  5. vara says:

    u made my day! :)..thank u for the post…

  6. Jong says:

    You are awesome! Many thanks!

  7. krisakino says:

    hi

    this helped me …

    thanks your a lifesaver ..an overnight googling….

    thanks again

  8. Gowri says:

    very good help. thank you very mcuh.

  9. dautkhanov says:

    Had the same issue – but files were owned by oracle user,
    and after upgrading to clusterware with job roles separation all listeners
    had to be running under grid. removing oracle-owned files in /tmp/.oracle solved the issue.
    Thank you.

  10. AB says:

    This was so helpful.
    Resolving a challenge I have been battling for a few hours.
    Thanks

  11. Fekensa D. says:

    Warm thanks after spending couple of hours come across ur comment and solved my problem very helpful!!!

  12. Vishwa says:

    Cool post..

  13. That was the trick! Thanks. `find /var/tmp/.oracle -type f -not -user oracle -delete`

Leave a reply to blauecorsa Cancel reply