[Samba] idmap GID range became full without reason

[Andrew Hotlab]

> Is the Mac as PDC, or a member server? What is the PDC?
>
> Idmap is not as well documented as it could be. I am using idmap with
> ldap backend for interdomain trusts, with both samba 3.0.x and samba 3.4.x
> with mixed success. But the behavior you are describing is definitely not
> OK.
>
> In addition to having an idmap section for the trusted domain, I also have
> an idmap section for "alloc" - I would check the smb.conf man page. I
> think the "idmap mydomain" section is supposed to help samba check existing
> idmap uid/gid entries and the "idmap alloc" section is supposed to keep
> track of the next entry to be allocated. It sounds like samba is unable to
> determine the existing idmap uid so creates another one.
>
> Maybe you can use the wbinfo command to manually set uid/gid's and then try
> to comment out the idmap entries in smb.conf to prevent future entries being
> added.
>

The Mac is the PDC, running Samba 3.0.25b-apple. The member server is
Samba 3.0.8 running on FreeBSD.  I'll never have a second member server.

Sorry, but as I said, I'm a newbie with Samba: I read the man pages and
I did not understand much about your suggestion. I'm guessing you
suggested to write something like the following in my smb.conf?

[global]
idmap backend = tdb
idmap id = 15000-20000
idmap gid = 15000-20000

idmap config MYDOMAIN : backend = nss
idmap config MYDOMAIN: range = 15000-20000


Thank very much for your help and patience! :)

Sincerely

Andrew


>
> -----Original Message-----
> From: samba-bounces at lists.samba.org [mailto:samba-bounces at lists.samba.org]
> On Behalf Of Andrew Hotlab
> Sent: Friday, June 11, 2010 5:35 PM
> To: samba at lists.samba.org
> Subject: Re: [Samba] idmap GID range became full without reason
>
>
>
>> On 06/11/10 09:12, Andrew Hotlab wrote:
>>>
>>> On 06/10/10 04:52, Andrew Hotlab wrote:
>>>> Every two-three months, all users are unable to access shared folders
> because the idmap GID range became full!!
>>>>
>>>> What I noticed is that each time a user mounts a shared folder, his/her
>>>> GID is incremented, and when it reaches the upper limit, the file
>>>> log.winbindd-idmap became full of these errors:
>>>> "nsswitch/idmap_tdb.c:idmap_tdb_allocate_id(470) Fatal Error: GID range
>>>> full!! (max: 20000)"
>>>>
>>>> Can anyone kindly suggest me what is causing this behavior, or at least
>>>> put me in the right direction? Can I activate some debug to obtain more info
>>>> about this?
>>>>
>>>> Any help will be greatly appreciated: I convinced the customer to use
>>>> Mac/BSD/Samba instead of going to Windows because I was confident it would
>>>> have been a valid alternative, and it's hard to justify these errors
>>>> thank
>>>> you all in advance!!
>>>>
>>>> Andrew
>>>
>>>
>>>> idmap uid = 15000-20000
>>>> idmap gid = 15000-20000
>>>
>>> Can you just increase the range? The setting I am using is:
>>>
>>> idmap uid = 500-100000000
>>> idmap gid = 500-100000000
>>>
>>>
>>>
>>> Thank you Brian.
>>>
>
>>> Yes, I can do it, but this will only shift the problem. I'd like to
> understand the the cause of this behavior and, if applicable, find the
> solution! :)
>>>
>
>> I think the cause of the problem is your range is to small. Maybe it is
> different with the security type you are using,
>> I am using ADS.
>
> Perhaps this can be helpful to understand the problem... I've just tried the
> same version of Samba as a member server of a Windows 2003 AD (exactly the
> same smb.conf): the output of the id command is "uid=15001(andrew)
> gid=15005(domain users) groups=15005(domain users)", and the gid number
> never changes, even if I mount the shared folders on Mac.
> I can't believe this behavior is normal: each time a user mounts a share the
> gid idmap increase! That would be extremely insane too, because it would
> make impossible to control access through group permissions!
>
 		 	   		  
_________________________________________________________________
Hotmail: Free, trusted and rich email service.
https://signup.live.com/signup.aspx?id=60969