http://www-01.ibm.com/support/docview.wss?uid=swg21097534

I cant get services smtp, pop3, http, working, cause they use lower ports, and suid bit doesn't help.

It looks that latest kernel or linux install doesn't work like it should. I tried also with file capabilities, but it also dont work.

Any suggestions? 

selinux is off?  i dont like new kernel on my servers......

Recheck status default mail service, like postfix

I seems that it disables setuid functionality

I have the exact same problem.  The one server on is on kernel 3.2.0-57 and it works fine.

Any solution?

We have the same problem on Ubuntu 12.04. When upgrading kernel from version 3.5.0-43-generic to 3.5.0-44-generic, the domino HTTP task refuse to start with the same bindsock error message.

Right now we just boot to 3.5.0-43 but we don't see this as a permanent solution. And yes we know that Ubuntu is not a supported platform for domino :-)

...just using older Kernels for now. Anything newer than 3.5.0-43 don't like it, and as Gregor Ibic says, might be setuid. Can't seem to find anything apart from monitoring in the change log.

Tried looking into Capabilties but nothing I do seems to help. I even adding cap_setuid to bindsock :-(

I am using Ubuntu 13.10 and experiencing the same from a security update.

Before kernel 3.11.0-13 Domino was working fine. After the kernel 3.11.0-14, bindsock error occurs.

Had this problem too when upgrading from kernel 3.2.0-56 to 3.2.0-58 with Domino 9.0.1

I raised a Bug Report and Ubuntu have a fix already. Don't know just yet when it'll be available in release.

Ubuntu support was quick and deadly accurate !!!

HUUUGE thanks to the Ubuntu Kernel team for such a quick turn around, think the bug report was just 5 hours old, and the patched Kernel resolved the issue on my 12.04 3.5.0-45 AMD64 VM. Pretty impressive !!!

So we just need to keep booting into the old Kernel till the new Kernels are released. I found this the solution from "Bealer Jul 4 '13 at 16:45"  a better solution, by using the text entry rather than the numerical entry:

 http://askubuntu.com/questions/216398/set-older-kernel-as-default-grub-entry

What they said...

Ok this patch has hit all of our upstream stable trees and will hit the
various kernels in the next SRU cycle.  Note that this is not the next
kernel which will hit the archive for all releases, for precise it is
included in that very next kernel, other releases it will be the
following kernel.

I am using Ubuntu 13.10. I updated the kernel to 3.11.0-17 through aptitude and the problem seems to be gone.

Please subscribe to this bug report:

https://bugs.launchpad.net/ubuntu/+source/linux-lts-quantal/+bug/1269053

This problem occurs again at kernel 3.13.0.27.

I am using Ubuntu 14.04 LTS.

Kernal 3.13.0.24 of the initial version of 14.04 LTS is OK.

Still a problem in 3.13.0-39 and 3.13.0-40.47 BUT... I've found a workaround. First of all, this is a bug in the KERNEL. It's messing up setuid. This has been FIXED in various other lines of the kernel which is where my workaround comes from.

First- don't settle for a workaround. Log into Ubuntu's launchpad and add your voice. If the developers don't know it's not affecting lots of people it won't get much attention. The bugs to comment on are here:

1. https://bugs.launchpad.net/ubuntu/+source/linux-lts-quantal/+bug/1269053 (this is the one that was fixed)
2. https://bugs.launchpad.net/ubuntu/+source/linux-lts-trusty/+bug/1335478 (this is the open bug)

Next, this is the workaround I figured out for Ubuntu 14.04.1 LTS (Trusty Tahr). Until Trusty's kernels get fixed, use the working Ubuntu 12.04 Precise Pangolin kernels, which include the 3.2.0 and the 3.5.0 varieties.

1. sudo echo 'APT::Default-Release "trusty";' >> /etc/apt/apt.conf.d/01ubuntu

(This will make sure if the Trusty repositories have a package or update, you will get it from there.)

2. sudo echo 'deb http://security.ubuntu.com/ubuntu precise-security main' >> /etc/apt/sources.list

(This adds the Precise repositories as an option for apt.)

3. Search for the latest kernel security release for the 3.2 or 3.5 line:
    #apt-get update
    #apt-cache search linux-image-3.5  -or- #apt-cache search linux-image-3.2

4. Install the desired kernel and headers:
    #apt-get install linux-image-3.5.0-54-generic linux-headers-3.5.0-54-generic

(these are just examples- use the actual version number of the kernel and header packages you want from your apt-cache search.)

5. Make sure there is not any newer kernel by apt-get remove, or specify the kernel you want to boot to in /etc/default/grub (see this article for details).

6. Reboot. Test.

7. If you're still getting the same error, it's probably not for the same reason and you didn't need to do any of this stuff. You may be dealing with another service like postfix, apache, or samba stealing your ports.  See this article about that.

http://people.canonical.com/~apw/lp1335478-2-trusty/

Of course none of that excuses the userspace programmer from not initialising this structure sensibly regardless of the documentation. It is plain sloppy practice.

And also has provided a way to confirm the bug:
The attached test.c should tickle this bug, sendmsg should return ret=4 errno=0 when the fix is applied, ret=-1 errno=22 when it is not.
https://bugs.launchpad.net/ubuntu/+source/linux-lts-trusty/+bug/1335478/+attachment/4284352/+files/test.c

I just opened up PMR 41425 227 000 to try to get this fixed for good.

SLES 12 + Domino 9.0.1:

bindsock does not work only port number<1024!

1, change default ports (for example http 80->8080  443->8443 ..) 

2, Susefirewall rule: FW_REDIRECT="0/0,server ip address,tcp,80,8080"

It works for me.....