Re: Getting notification upon loss of connection (libsmbclient)
On Wed, 12 Mar 2003 16:07:43 -0500 [EMAIL PROTECTED] wrote: I have not been able to find the block of code that will be called if an open connection receives an indication that the peer has gone away (i.e. shutdown, crashed, cable cut, etc.). More specifically, if I have an open, established connection by having previously done: cli_connect() cli_session_request() cli_session_setup() cli_send_tconX() and now the remote server goes away (let's say it crashed suddenly), how can I find this out? I'm not familiar with libsmbclient but I believe you will just have to try to perform some operation and catch the error code. If the error codes are consistent (e.g. EIO) you can trap and reinitialize the request in a way that would be transparent to the user. Otherwise the library would need to send NBT keepalives or use an out of band heartbeat of some kind. Smbclient sort of does this by repeatedly sending an SMB_COM_CHECK_DIRECTORY every 3 seconds. That probably serves a similar purpose. But this is a TCP thing, not a libsmbclient thing. Mike -- A program should be written to model the concepts of the task it performs rather than the physical world or a process because this maximizes the potential for it to be applied to tasks that are conceptually similar and, more important, to tasks that have not yet been conceived.
could not find domain entry for domain @xxxxx
Have anybody seen that problem ? We have that in an NT40Serverfarm with samba 2.2.7a as BDC. during the start of winbind we saw also following message: could not get sid of domain ... The users get access to there shares but the policies dont work corectly We have an IP-Segmented network, the server are in there own net, wins is running on the NT40 PDC. Thanks for every idea Holger Diese Mail wurde im Hause SCHMIEDER it-solutions GmbH auf Viren überprüft !
Re: New approach for winbind to match Windows to UNIX users and back
Hi Michael, Michael Fair wrote: The admin would have to rechown all the files from the old ids to the new ones, but a simple find command could probably manage that. How does that work? Any major wrinkles? I'm not feeling really comfortable with winbind assigning all UIDs and GIDs on a system, as it does need to coexist with other means and tools for Unix user management. Reassigning their IDs is a major pain, and often impossible. If winbind could only be used when taking over ID management entirely, we would be in trouble. So this behaviour needs to be at least optional... Cheers! Michael
Re: [PATCH] smbcquotas (client site quota support)
At 00:22 13.03.2003 +0100, Stefan (metze) Metzmacher wrote: If someone want to apply this patch please ask for an actuall patch against the latest HEAD. I merged in jra's unsigned fixes and some little formatting fixes to my local tree. metze - Stefan metze Metzmacher [EMAIL PROTECTED]
Re: New approach for winbind to match Windows to UNIX users and back
Michael Steffens [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hi Michael, Michael Fair wrote: The admin would have to rechown all the files from the old ids to the new ones, but a simple find command could probably manage that. How does that work? Any major wrinkles? I'm not feeling really comfortable with winbind assigning all UIDs and GIDs on a system, as it does need to coexist with other means and tools for Unix user management. Reassigning their IDs is a major pain, and often impossible. If winbind could only be used when taking over ID management entirely, we would be in trouble. So this behaviour needs to be at least optional... Oh yes, entirely! Nothing I mentioned was an attempt to put winbind in control of all the UID/GIDs on a system. I personally have never used, nor even heard of a system that used UID/GIDs 100,000,000 and above. That's the address space that winbind would be using. Everything below that 0 through 99,999,999 would be reserved for the normal system (as I mentioned earlier in the post). But just because I haven't encountered doesn't mean it doesn't exist which was my primary concern (if the address space is in use, then it is not a solution and we'll need to come up with something else). The snippet you grabbed was part of an optional step 7 that an administrator could, if they were so inclined, use to get an existing UNIX user to be directly mapped to the new Windows User created by winbind (mostly because the admin doesn't want to specify the ACL for the unix user separate from the ACL for the Windows User). This not something winbind would do. This is only something an administrator would do manually (perhaps with the aid of some scripts, and only if it was found to actually be a valuable operation). If the existing UNIX UID is heavily ACLed then this of course would probably not be used. The two IDs would remain separated. If the UNIX admin was following the best practices recommendation and only assigning ACLs on the GIDs that Winbind created, then the same effect could be gotten by placing the UNIX user in the private group that Winbind created for the Windows User. The only purpose having winbind create a UNIX user serves is exactly that, to let the system have an honest to goodness UNIX user to use for operations in the system. The concept is: 1) Winbind only uses IDs 100,000,000 and above ( the bit friendly version is IDs 134,217,728 and above) 2) Each domain encountered gets its own 100,000,000 offset. So 100,000,000 for D1, 200,000,000 for D2, etc. 3) Winbind only creates GIDs, except in the case it has detected a Windows User, then it also creates a UID with the same number as the GID for that object (and for that object only) 4) Suggest that a best practice be adopted where only the GID gets ACLs on the local system (this might be unnecessary with the addition of the Give users a UID as well approach. The only thing this proposal really does is break up the UID/GID space into 100,000,000 offest segments, the first of which is for the UNIX system (Local_Machine if you will) and the rest for each Domain it encounters, up to 42 domains (or 31 domains if using the bit friendly version). (I personally thing that even 67,108,864 offsets is reasonable with up to 63 domains, but I've never deployed a large scale enterprise before so I don't know how big those numbers get) -- Michael --
Re: New approach for winbind to match Windows to UNIX users andback
On Thu, 2003-03-13 at 01:32, Andrew Bartlett wrote: On Thu, 2003-03-13 at 10:38, Michael Fair wrote: I haven't done much work in this are yet so please feel free to correct me as you see fit, but as I understand it, part of the problem we face is that the equivalents of the UID and a GID in UNIX, are mapped to the same address space in Windows. I was working on some unrelated ACL stuff and thought about the potential of practically eliminating the use of an ACL on a UID and only using ACLs on groups. I think this is a very good idea. We would effectivly create a 'user private group' for every winbindd user. And if they turned out to be a group, then we just populate them with members! This is an approach I have proposed back last summer to Jeremy and Tridge at Jeremy's, and that would have also cured the problem that all distribution that automatically create a private group for a user have, but seem they was not convinced so I didn't pushed the idea anymore :-) This helps us particularly with the problem that we don't know the type of a SID without a lookup - a lookup that may well fail. Exactly! This would also solve a nasty problem we have that we don't know the 'real' primary group of every user for NT4 domains, when doing a getgrent(). Instead we assume 'domain users'. This would allow us to always know that value. No, that's not right, we must have a Primary Group in local passdb and use Domain Users as a fallback. Simo. -- Simo Sorce - [EMAIL PROTECTED] Xsec s.r.l. via Durando 10 Ed. G - 20158 - Milano tel. +39 02 2399 7130 - fax: +39 02 700 442 399 signature.asc Description: This is a digitally signed message part
Re: New approach for winbind to match Windows to UNIX users and back
On Thu, 2003-03-13 at 20:29, Michael Fair wrote: Michael Steffens [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hi Michael, Michael Fair wrote: The admin would have to rechown all the files from the old ids to the new ones, but a simple find command could probably manage that. How does that work? Any major wrinkles? I'm not feeling really comfortable with winbind assigning all UIDs and GIDs on a system, as it does need to coexist with other means and tools for Unix user management. Reassigning their IDs is a major pain, and often impossible. If winbind could only be used when taking over ID management entirely, we would be in trouble. So this behaviour needs to be at least optional... Oh yes, entirely! Nothing I mentioned was an attempt to put winbind in control of all the UID/GIDs on a system. I personally have never used, nor even heard of a system that used UID/GIDs 100,000,000 and above. You would be supprised.. For example, my uni uses unix ids that match the student ids - and they are 7 digits long. Not quite 100,000,000, but don't make assumptions. That's the address space that winbind would be using. Everything below that 0 through 99,999,999 would be reserved for the normal system (as I mentioned earlier in the post). But just because I haven't encountered doesn't mean it doesn't exist which was my primary concern (if the address space is in use, then it is not a solution and we'll need to come up with something else). The next problem is the number of domains. Many of the orginisations that deploy samba live on *massive* internal networks with 100's of domains! Worse still, each and every workstation is it's own domain, and the SIDs from that workstation can end up on the NAS! We need to be able to correctly map these SIDs, even if we have never heard of the domain before. The concept is: 1) Winbind only uses IDs 100,000,000 and above ( the bit friendly version is IDs 134,217,728 and above) 2) Each domain encountered gets its own 100,000,000 offset. So 100,000,000 for D1, 200,000,000 for D2, etc. I don't like the offset idea. 3) Winbind only creates GIDs, except in the case it has detected a Windows User, then it also creates a UID with the same number as the GID for that object (and for that object only) We should only create a passwd nss record for Users, and possibly only map to a uid for users - but this means we have to look them up first - and that has problems. 4) Suggest that a best practice be adopted where only the GID gets ACLs on the local system (this might be unnecessary with the addition of the Give users a UID as well approach. 'best practice' isn't a particularly good idea when things break if people don't follow it. We need solutions that don't rely on *users* following 'best practice' but instead 'this works'. The only thing this proposal really does is break up the UID/GID space into 100,000,000 offest segments, the first of which is for the UNIX system (Local_Machine if you will) and the rest for each Domain it encounters, up to 42 domains (or 31 domains if using the bit friendly version). (I personally thing that even 67,108,864 offsets is reasonable with up to 63 domains, but I've never deployed a large scale enterprise before so I don't know how big those numbers get) With SIDs they get very big. I sit in two camps on this one - for local UIDs/GIDs, I actually like the 'algorithmic', but it's confined to a single uid/gid space. For winbindd, I'm convinced that the tdb mapping is the best way forward, but that some extensions to cope with all SIDs as GIDs. Andrew Bartlett -- Andrew Bartlett [EMAIL PROTECTED] Manager, Authentication Subsystems, Samba Team [EMAIL PROTECTED] Student Network Administrator, Hawker College [EMAIL PROTECTED] http://samba.org http://build.samba.org http://hawkerc.net signature.asc Description: This is a digitally signed message part
Re: New approach for winbind to match Windows to UNIX users and back
On Thu, 2003-03-13 at 20:46, Simo Sorce wrote: On Thu, 2003-03-13 at 01:32, Andrew Bartlett wrote: On Thu, 2003-03-13 at 10:38, Michael Fair wrote: I haven't done much work in this are yet so please feel free to correct me as you see fit, but as I understand it, part of the problem we face is that the equivalents of the UID and a GID in UNIX, are mapped to the same address space in Windows. I was working on some unrelated ACL stuff and thought about the potential of practically eliminating the use of an ACL on a UID and only using ACLs on groups. I think this is a very good idea. We would effectivly create a 'user private group' for every winbindd user. And if they turned out to be a group, then we just populate them with members! This is an approach I have proposed back last summer to Jeremy and Tridge at Jeremy's, and that would have also cured the problem that all distribution that automatically create a private group for a user have, but seem they was not convinced so I didn't pushed the idea anymore :-) This helps us particularly with the problem that we don't know the type of a SID without a lookup - a lookup that may well fail. Exactly! I'm glad we agree! This would also solve a nasty problem we have that we don't know the 'real' primary group of every user for NT4 domains, when doing a getgrent(). Instead we assume 'domain users'. This would allow us to always know that value. No, that's not right, we must have a Primary Group in local passdb and use Domain Users as a fallback. This is where I've lost what you mean... I'm talking about winbind as a domain member, but I'm open to suggestions. Andrew Bartlett -- Andrew Bartlett [EMAIL PROTECTED] Manager, Authentication Subsystems, Samba Team [EMAIL PROTECTED] Student Network Administrator, Hawker College [EMAIL PROTECTED] http://samba.org http://build.samba.org http://hawkerc.net signature.asc Description: This is a digitally signed message part
Re: New approach for winbind to match Windows to UNIX users and back
Hi Michael, Michael Fair wrote: Oh yes, entirely! Nothing I mentioned was an attempt to put winbind in control of all the UID/GIDs on a system. I personally have never used, nor even heard of a system that used UID/GIDs 100,000,000 and above. That's the address space that winbind would be using. Everything below that 0 through 99,999,999 would be reserved for the normal system (as I mentioned earlier in the post). But just because I haven't encountered doesn't mean it doesn't exist which was my primary concern (if the address space is in use, then it is not a solution and we'll need to come up with something else). Hmmpf, sorry, sometimes I need to be told things twice to understand :) Got it! Michael
Re: [Samba] PATCH: downloading drivers from Solaris [was Re: SoSAMBA no longer ...]
Hi, like I have tested, Printer driver download from W2000 works fine know (Solaris , samba-2.2.8-pre2) But I have another Solaris specific problem with W95 drivers (works fine under Linux) The W95 Client opens the addprinterwizzard, when downloading the driver. Samba reports (see below): [2003/03/13 10:48:05, 3] smbd/lanman.c:get_printerdrivernumber(836) Can't determine number of printer driver files [2003/03/13 10:48:05, 3] smbd/lanman.c:api_DosPrintQGetInfo(918) api_DosPrintQGetInfo: Driver files count: 0 Could that be another Solaris specific issue. I attached the command, how I added the driver below. I am using a version of cupsaddsmb , which places the : correctly. Thank you very much Hansjrg [2003/03/13 10:48:05, 3] smbd/lanman.c:api_DosPrintQGetInfo(884) api_DosPrintQGetInfo: uLevel=51 name=INSHP4050 [2003/03/13 10:48:05, 3] smbd/process.c:process_smb(876) Transaction 13 of length 115 [2003/03/13 10:48:05, 3] smbd/process.c:switch_message(685) switch message SMBtrans (pid 4703) [2003/03/13 10:48:05, 3] smbd/ipc.c:reply_trans(480) trans \PIPE\LANMAN data=0 params=35 setup=0 [2003/03/13 10:48:05, 3] smbd/ipc.c:named_pipe(334) named pipe command on LANMAN name [2003/03/13 10:48:05, 3] smbd/lanman.c:api_reply(3345) Got API command 70 of form zWrLh WN (tdscnt=0,tpscnt=35,mdrcnt=1024,mprcnt=6) [2003/03/13 10:48:05, 3] smbd/lanman.c:api_reply(3349) Doing DosPrintQGetInfo [2003/03/13 10:48:05, 3] smbd/lanman.c:api_DosPrintQGetInfo(884) api_DosPrintQGetInfo: uLevel=52 name=INSHP4050 [2003/03/13 10:48:05, 3] smbd/lanman.c:get_printerdrivernumber(836) Can't determine number of printer driver files [2003/03/13 10:48:05, 3] smbd/lanman.c:api_DosPrintQGetInfo(918) api_DosPrintQGetInfo: Driver files count: 0 [2003/03/13 10:48:05, 3] smbd/lanman.c:fill_printq_info_52(656) printerdriver:inshp4050: [2003/03/13 10:48:05, 3] smbd/lanman.c:fill_printq_info_52(657) Driver:ADOBEPS4.DRV: [2003/03/13 10:48:05, 3] smbd/lanman.c:fill_printq_info_52(658) Data File:inshp4050.PPD: [2003/03/13 10:48:05, 3] smbd/lanman.c:fill_printq_info_52(659) Language Monitor:PSMON.DLL: [2003/03/13 10:48:05, 3] smbd/lanman.c:fill_printq_info_52(661) lp_driverlocation:\\PRINTSERVER2\print$\WIN40\0: [2003/03/13 10:48:05, 3] smbd/lanman.c:fill_printq_info_52(664) Data Type:RAW: [2003/03/13 10:48:05, 3] smbd/lanman.c:fill_printq_info_52(665) Help File:ADOBEPS4.HLP: [2003/03/13 10:48:05, 3] smbd/lanman.c:fill_printq_info_52(679) fill_printq_info on inshp4050 gave 0 entries [2003/03/13 10:48:05, 3] smbd/process.c:process_smb(876) Transaction 14 of length 115 [2003/03/13 10:48:05, 3] smbd/process.c:switch_message(685) switch message SMBtrans (pid 4703) [2003/03/13 10:48:05, 3] smbd/ipc.c:reply_trans(480) trans \PIPE\LANMAN data=0 params=35 setup=0 [2003/03/13 10:48:05, 3] smbd/ipc.c:named_pipe(334) named pipe command on LANMAN name [2003/03/13 10:48:05, 3] smbd/lanman.c:api_reply(3345) Got API command 70 of form zWrLh WN (tdscnt=0,tpscnt=35,mdrcnt=1024,mprcnt=6) [2003/03/13 10:48:05, 3] smbd/lanman.c:api_reply(3349) Doing DosPrintQGetInfo [2003/03/13 10:48:05, 3] smbd/lanman.c:api_DosPrintQGetInfo(884) api_DosPrintQGetInfo: uLevel=52 name=INSHP4050 [2003/03/13 10:48:05, 3] smbd/lanman.c:get_printerdrivernumber(836) Can't determine number of printer driver files [2003/03/13 10:48:05, 3] smbd/lanman.c:api_DosPrintQGetInfo(918) api_DosPrintQGetInfo: Driver files count: 0 [2003/03/13 10:48:05, 3] smbd/lanman.c:fill_printq_info_52(656) printerdriver:inshp4050: [2003/03/13 10:48:05, 3] smbd/lanman.c:fill_printq_info_52(657) Driver:ADOBEPS4.DRV: [2003/03/13 10:48:05, 3] smbd/lanman.c:fill_printq_info_52(658) Data File:inshp4050.PPD: [2003/03/13 10:48:05, 3] smbd/lanman.c:fill_printq_info_52(659) Language Monitor:PSMON.DLL: [2003/03/13 10:48:05, 3] smbd/lanman.c:fill_printq_info_52(661) lp_driverlocation:\\PRINTSERVER2\print$\WIN40\0: [2003/03/13 10:48:05, 3] smbd/lanman.c:fill_printq_info_52(664) Data Type:RAW: [2003/03/13 10:48:05, 3] smbd/lanman.c:fill_printq_info_52(665) Help File:ADOBEPS4.HLP: [2003/03/13 10:48:05, 3] smbd/lanman.c:fill_printq_info_52(679) fill_printq_info on inshp4050 gave 0 entries [2003/03/13 10:48:05, 3] smbd/process.c:process_smb(876) Transaction 15 of length 115 [2003/03/13 10:48:05, 3] smbd/process.c:switch_message(685) switch message SMBtrans (pid 4703) [2003/03/13 10:48:05, 3] smbd/ipc.c:reply_trans(480) trans \PIPE\LANMAN data=0 params=35 setup=0 [2003/03/13 10:48:05, 3] smbd/ipc.c:named_pipe(334) named pipe command on LANMAN name [2003/03/13 10:48:05, 3] smbd/lanman.c:api_reply(3345) Got API command 70 of form zWrLh WN (tdscnt=0,tpscnt=35,mdrcnt=1024,mprcnt=6) [2003/03/13 10:48:05, 3] smbd/lanman.c:api_reply(3349) Doing DosPrintQGetInfo [2003/03/13 10:48:05, 3] smbd/lanman.c:api_DosPrintQGetInfo(884) api_DosPrintQGetInfo: uLevel=52 name=INSHP4050 [2003/03/13 10:48:05, 3] smbd/lanman.c:get_printerdrivernumber(836) Can't determine number of
failure to print (samba HEAD, cups, raw printers)
hi folks, again with the peculiar setup :) I've set up raw printers in cups to match the windows network, and added the correct windows drivers to feed them. One of the printers, a HP Colour LaserJet 8500 in PCL mode, fails at the testpage stage with this message: the data area passed to a system call is too small I've done a trace of the attempt, which I can forward if required. I thought this might be the large RPC bug that tpot was looking at, but I'm not sure. Cheers, Waider. -- [EMAIL PROTECTED] / Yes, it /is/ very personal of me. Anyway, yes. Known bug. Try entering only numbers as your phone number, no brackets, dashes, widgets, knobs, fish or sliding trammel bars.
Re: failure to print (samba HEAD, cups, raw printers)
On March 13, [EMAIL PROTECTED] said: hi folks, again with the peculiar setup :) I've set up raw printers in cups to match the windows network, and added the correct windows drivers to feed them. One of the printers, a HP Colour LaserJet 8500 in PCL mode, fails at the testpage stage with this message: Uh, sorry. forgot to mention. The client is NT4SP6. By correct windows drivers to feed them I mean the NT box downloads the same PCL drivers from the Samba server as it would from the normal (NT) server. Cheers, Waider. -- [EMAIL PROTECTED] / Yes, it /is/ very personal of me. Andrea.B.Previtera says, I can't remember...we found a good cheap beer in an undocumented irish pub...and we had pints and pints and pints to celebrate something...
sock8 timeout
--- Environment HP ALPHA XP100 (fomerly Compaq) TRU64 5.1A PK 3 Samba 2.2.5 In directory /tmp I found some files which I dont know who created them: drwxr-xr-x 2 root system 8192 Mar 11 09:26 .winbindd -rw-r--r-- 1 root system 0 Mar 8 00:16 log8015_03.03.08 -rw-r--r-- 1 root system 692 Mar 9 14:38 log8015_03.03.09 -rw-r--r-- 1 root system 2070 Mar 10 16:50 log8015_03.03.10 -rw-r--r-- 1 root system 346 Mar 11 09:31 log8015_03.03.11 -rw-r--r-- 1 root system 2696 Mar 11 09:31 log8015_counter -rw-r--r-- 1 root system 3612 Mar 11 00:16 log8015_counter.old -rw-r--r-- 1 root system 351 Mar 10 14:19 log8015_error Content of log8015_error: [10/Feb/2003:16:08:09] sock8 timeout [10/Feb/2003:16:20:19] sock8 timeout [17/Feb/2003:09:22:39] sock8 timeout [26/Feb/2003:15:24:35] sock8 timeout [10/Mar/2003:09:25:05] sock8 timeout [10/Mar/2003:10:13:04] sock8 timeout [10/Mar/2003:12:47:25] sock8 timeout [10/Mar/2003:12:53:04] sock8 timeout [10/Mar/2003:14:19:24] sock8 timeout Any ideas which application created these files? What is the problem with sock8 timeout? Google does not know anything about sock8. What I did during the times logged in the file log8015_error: I tried to run squid (a proxy server) in combination with ntlm / winbind. Samba and wb_auth works fine $ wbinfo -t Secret is good squid without winbind works fine too. But the combination of squid and wwinbind seems to time out. Thanks in advance for any helpful hints. Mit freundlichen Grüßen / regards Werner Rost - ZF Boge GmbH Werner Rost IT Friesdorfer Str. 175 D-53175 Bonn phone:+49/228/3825 420 fax: +49/228/3825 398 [EMAIL PROTECTED] www.boge-vibrationcontrol.com/ -
(fwd) amigasamba?
Does anyone know about this? - Forwarded message from Larry Urquhart [EMAIL PROTECTED] - From: Larry Urquhart [EMAIL PROTECTED] Subject: amigasamba Date: Wed, 12 Mar 2003 21:28:49 -0800 To: [EMAIL PROTECTED] User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Bogosity: No, tests=bogofilter, spamicity=0.024176, version=0.10.2 Hi. I don't know if this is the right place to ask this but I have been trying to visit the web site of www.amigasamba.org for over a week and it is off line. What's up ? I have questions to ask the administrator. Cheers Larry - End forwarded message - -- Martin
Re: Applications that want 8.3 names
Richard Sharpe [EMAIL PROTECTED] writes: Is anyone aware of Windows applications that will only deal with 8.3 names and cannot deal with long file names? Modern apps, no. Lots of Windows 3.1 apps (e.g. Quicken versions from back in the day) couldn't deal with long file names when moved onto later Windows versions which would have otherwise supported it. Derrell
RE: (fwd) amigasamba?
I look into this in a few days. Use www.birrabrothers.com/tiger/data/samba as mirror I'm on vacation and don't have the info here. -- Ulf -Original Message- From: Martin Pool [mailto:[EMAIL PROTECTED] Sent: Thursday, March 13, 2003 10:43 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: (fwd) amigasamba? Does anyone know about this? - Forwarded message from Larry Urquhart [EMAIL PROTECTED] - From: Larry Urquhart [EMAIL PROTECTED] Subject: amigasamba Date: Wed, 12 Mar 2003 21:28:49 -0800 To: [EMAIL PROTECTED] User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Bogosity: No, tests=bogofilter, spamicity=0.024176, version=0.10.2 Hi. I don't know if this is the right place to ask this but I have been trying to visit the web site of www.amigasamba.org for over a week and it is off line. What's up ? I have questions to ask the administrator. Cheers Larry - End forwarded message - -- Martin
RE: Applications that want 8.3 names
Most setup.exe programs are stubs that are 16-bit executables, and want 8.3 filenames. ERX -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] g]On Behalf Of Richard Sharpe Sent: Thursday, March 13, 2003 1:56 PM To: [EMAIL PROTECTED] Subject: Applications that want 8.3 names Hi, Is anyone aware of Windows applications that will only deal with 8.3 names and cannot deal with long file names? Regards - Richard Sharpe, rsharpe[at]ns.aus.com, rsharpe[at]samba.org, sharpe[at]ethereal.com, http://www.richardsharpe.com
Re: could not find domain entry for domain @xxxxx
schmieder, holger wrote: Have anybody seen that problem ? We have that in an NT40Serverfarm with samba 2.2.7a as BDC. during the start of winbind we saw also following message: could not get sid of domain ... The users get access to there shares but the policies dont work corectly We have an IP-Segmented network, the server are in there own net, wins is running on the NT40 PDC. Thanks for every idea Holger We would need a lot more information. First thing to try is this: $ nmblookup -R -U wins server IP domain#1C That checks to see that all of the 1C IP addresses for your WINS database. Chris -)- -- Samba Team -- http://www.samba.org/ -)- Christopher R. Hertel jCIFS Team -- http://jcifs.samba.org/ -)- ubiqx development, uninq. ubiqx Team -- http://www.ubiqx.org/ -)- [EMAIL PROTECTED] OnLineBook -- http://ubiqx.org/cifs/-)- [EMAIL PROTECTED]
Re: New approach for winbind to match Windows to UNIX users and back
Andrew Bartlett [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I sit in two camps on this one - for local UIDs/GIDs, I actually like the 'algorithmic', but it's confined to a single uid/gid space. For winbindd, I'm convinced that the tdb mapping is the best way forward, but that some extensions to cope with all SIDs as GIDs. The irony is that this is actaully proving my original proposal to use solely GIDs ineffective since it seems that ultimately we'll need entries in both the UID space and the GID space to get the behavior we need. Indeed it seems that what's actually required is a UID and a GID per SID (I forgot about Group Owners of normal files, and looking up permissions in a normal POSIX fashion uses the UID to access a list of GIDs (including the default GID)). So it seems like the solution to define two identically sized ranges from the local UID and GID space and to have winbind just burn through them incrementally while maintaining a mapping table really ends up being the best approach. I hadn't realized that an SID is actually 256 bits and we at best only have 32 bits to work with I I was only thinking about the RIDs). -- Michael --
Re: New approach for winbind to match Windows to UNIX users and back
I hadn't realized that an SID is actually 256 bits and we at best only have 32 bits to work with I I was only thinking about the RIDs). A SID is variable length, really. -- Luke -- Luke Howard | PADL Software Pty Ltd | www.padl.com
Re: Applications that want 8.3 names
Richard Sharpe wrote: Is anyone aware of Windows applications that will only deal with 8.3 namesand cannot deal with long file names? erx wrote: Most setup.exe programs are stubs that are 16-bit executables, and want 8.3 filenames. And some of the ones that can handle storing long filenames expect that when they extract the files, they will get the same 8.3 alias that they had originally, which does not happen because Microsoft has several different algorithms for generating the alias. One of the installers in the Windows NT 4.0 Resource kit has this problem. -John [EMAIL PROTECTED] Personal Opinion Only
Error messages generated by passdb/pdb_smbpasswd.c are (almost)useless
Hi,
Someone asked me what some messages like getsmbfilepwent: malformed
password entry (uid not number) meant when using the smbpasswd command.
Not knowing, I went searching the source code to find:
if (!isdigit(*p)) {
DEBUG(0, (getsmbfilepwent: malformed password entry (uid not
number)\n));
continue;
This is very little help in pinpointing the problems, as it does not tell
us what the routine was looking at that caused the problem. Perhaps
including the string it was processing would have been more useful!
Regards
-
Richard Sharpe, rsharpe[at]ns.aus.com, rsharpe[at]samba.org,
sharpe[at]ethereal.com, http://www.richardsharpe.com
