samba - Feb 2010 - rlimit_max errors

Running Samba 3.4.5 on Solaris 10 Sparc platform.  I can't seem to get 
rid of the following errors:

log.b104d1:rlimit_max: rlimit_max (10020) below minimum Windows limit 
(16384)

I've tried adding "ulimit -n 16384" to the samba start scripts,
but
still getting these errors.  Anyone know what I should do about this. 
Could these errors cause slowness to the samba share for clients?



-- 
C. J. Keist                     Email: cj.keist at colostate.edu
UNIX/Network Manager            Phone: 970-491-0630
Engineering Network Services    Fax:   970-491-5569
College of Engineering, CSU
Ft. Collins, CO 80523-1301

All I want is a chance to prove 'Money can't buy happiness'

On Wed, Feb 17, 2010 at 9:57 AM, cjay <cjay at engr.colostate.edu> wrote:
> Running Samba 3.4.5 on Solaris 10 Sparc platform.  I can't seem to get
rid
> of the following errors:
>
> log.b104d1:rlimit_max: rlimit_max (10020) below minimum Windows limit
> (16384)
>
> I've tried adding "ulimit -n 16384" to the samba start
scripts, but still
> getting these errors.  Anyone know what I should do about this. Could these
> errors cause slowness to the samba share for clients?
>
>
>
> --
> C. J. Keist                     Email: cj.keist at colostate.edu
> UNIX/Network Manager            Phone: 970-491-0630
> Engineering Network Services    Fax:   970-491-5569
> College of Engineering, CSU
> Ft. Collins, CO 80523-1301
>
>
> Don't know if it will help but that is mentioned here:
http://lists.samba.org/archive/samba/2010-January/153320.html

On Wed, Feb 17, 2010 at 10:57:02AM -0700, cjay wrote:
> Running Samba 3.4.5 on Solaris 10 Sparc platform.  I can't seem to
> get rid of the following errors:
> 
> log.b104d1:rlimit_max: rlimit_max (10020) below minimum Windows
> limit (16384)
> 
> I've tried adding "ulimit -n 16384" to the samba start
scripts, but
> still getting these errors.  Anyone know what I should do about
> this. Could these errors cause slowness to the samba share for
> clients?
No. It's informational only.

Jeremy.