For those who used the idmap range and removed it last May when trying to move to 3.6 and found their DB hosed beyond fixing, it has been noted, that last week I tried adding those params back in to my smb.conf (running 3.5.11). All of a sudden all of my groups resolve and I'm no longer getting coredumps on various utils trying to list my groups. You may think the param is useless, but if you have it in use, there's no easy way to move forward. If a product moves to a new, incompatible format, it would be useful to provide some conversion tool. Meanwhile, why is it that one can't have or setup separate ranges, by default for auto-allocated id's? Looking at an ID one could more easily tell if it was in the GID range or the UID range... What seemed to happen -- without those 'anchor points' -- the USER id's were the most screwed,as groups had mostly been mapped via group map. But without an equivalent for users, one had to rely on the allocation mechanism. Thus when the ranges changed, it tried to allocate all new RID's. This caused a bit of a mess. So how can sites who used those params upgrade w/o resulting chaos? If that can't be easily answered, perhaps those params should be re-added until the upgrade process can be made more robust...?
Re-assigning to Michael.
Is this a bug report? Or rather a general complaint about various complaints? Or a poem? ;) Please describe precisely what bug you discovered (or close the bug).. Cheers - Michael
(In reply to comment #2) > Is this a bug report? > Or rather a general complaint about various complaints? > Or a poem? ;) > > Please describe precisely what bug you discovered > (or close the bug).. > > Cheers - Michael ---- Bug part 1) removal of idmap range forces users to move uid and gid's into the same range. If this isn't how they had their configuration set before this change was forced upon them, then they find that either their groups or id's get remapped to the new range (mine did). This caused problems with resource ownership on my Windows machines that were dependent on Samba not to be randomly mucking with the id's. At the time, I had a finely *hand* tuned system for a small number of user and groups that worked very well, very reliably. Now I have constant errors and haven't yet figured out how to rejoin either of my win7 machines to the domain. While there is a tool to map gid's to RID's and the names (net groupmap), there seems to be no corresponding tool for uid's that works reliably. for whatever reason, I tried to move UID mapping back from the place where it got mapped to when this change corrupted my DB, from rid 80026, back to lower numbers -- actually going to a 1:1 mapping for that UID, as UID 5013 doesn't conflict wtih any NT UID's ... I don't have a separate base of Unix and Windows users. In fact, in my usage, the linux machine is used specifically to support Windows and do all the things that Windows is bad at (file serving, backup, DNS, web proxy, imap server, among several othrs). So I really don't need much in the way of remapping at all. While since this bug has happened, I've tried to move my user and groups around so that there is a group for every user an vice-versa, so they numbers won't overlap/collide. But most people probably can't do some of the work-arounds I've implemented, because they have more users -- and manually/hand mapping UID->RID's starts out to be alot of work, though would suspect it gets to be less as one writes more support scripts. Meanwhile, anyone moving from a setup where the ranges were separate to the uni-range will find the offset for one or the other (gid/uid), to suddenly become incompat. I can't imagine why you would have done this.. it can't be by design, it's too thoughtless. So likely there some interaction with something else in my config that caused this... I think part of it was brought on by getting errors or warnings on startup that I had not entered a range for the new parameter, thus it didn't know how to map users and groups. When I set it, I think that's when I noticed the shift (don't remember which it was -- UID or GID's -- as this was reported a few months ago when I still was able to join a domain. ---- As for your comment... what a peculiar comment. It seemed that moving a feature from one version to the next should be obvious as having the potential (and likelihood) of causing problems ... I see the introduction of incompatible behaviors with no automatic conversion from old parms to new - to be a bug by itself. Multiple times I have gotten software updates on the PC, and all the cases I can think of, the tools handle upgrading old database-formats upon installation. Not doing so causes an unexpected hit to take corrective action and blocks logins until it is fixed. Doing that in a production release is also something that would qualify as a bug. The specifics of eliminating a feature, caused multiple follow on problems, -- not all of which I remember 4 months later, when someone finally looks at it.