Re: SMB_ROUNDUP
On Mon, Apr 08, 2002 at 07:12:57PM -0700, Shirish Kalele wrote: Hi, Is there a specific need to roundup the reported allocation size of a file using SMB_ROUNDUP or SMB_ROUNDUP_ALLOCATION? Samba seems to report the allocation size inconsistently: it uses a roundup in some places and doesn't use it in other. This is confusing offline-caching clients. Can we do away with the roundups? No, don't do that. I'm afraid they're essential to the correct functioning of some of the trans2 calls (in that some copying ops fail is we get it wrong). Can you tell me where the inconsistencies are and I can fix them ? Jeremy.
Re: SMB_ROUNDUP
On Tue, Apr 09, 2002 at 08:00:26AM -0700, Shirish Kalele wrote: But the values we send don't even match up with NTFS allocation values. So what does getting it right mean? Doing what NT does :-). Also, it changes the behaviour of how NT will write into new space. This can be *very* efficient. One of the reasons we give a large allocation space is that NT then does *large* efficient writes in units of the allocation space to fill up a new file. I was able to tune the NT client behaviour by doing this. Here's a patch to reply_ntcreate_and_X that returns the allocation in one of the fields instead of the file length. Ok - I'll look at that. I also found that Windows 2000 returns a weird ntcreate_and_X reply: 42 parameter words PLUS 18 bytes that are not accounted for in the word or bytes counts. It seems to me that 8 of these extra 18 bytes contain two access masks (seem to be User and Guest/Everyone-else). I'm guessing these are something to do with Simple File Sharing. The access masks here determine how the file is accessed on the client offline (i.e. what permissions the user has and what permissions anyone else who accesses the file on the same client offline has). Win2K/XP tcon_and_X replies also have these two access masks in the parameter words (the reason why they return 7 words instead of 3). We need to analyse this rather than doing it for 2.2.4 Finally, I think it would be a good idea to get the client-side-caching policy patch into 2.2.4. Do you want to take a look at it or should I just go ahead and check it in? I want to look at it - it definately looks good though. Can you give me a day or so before checking it in ? Thanks, Jeremy.
Re: FCNTL on Solaris
On Mon, Apr 22, 2002 at 01:24:36PM -0400, David Collier-Brown wrote: David Collier-Brown wrote: I haven't looked at the code, but if it uses F_SETLKW you might want to do a trylock first, implemented via F_GETLK or F_SETLK, as this would allow subsequent processes to continue, knowing that someone's fixing the tdb, and that they can access it later using the normal locking regime. A disclaimer: that isn't the way to do case 3, it's the way to NOT do case three and be able to execute in bounded time, instead. I reccomend it over case 3 **rather strongly**, as 3 goes nonlinear, and can be proved to fail (I just drew the dfa and it was evil!!!) The stock approach is also nonlinear, with a higher overhead, so I guess it's doubly evil. That other OSs don't bottleneck on it says good things about their kernel programmers. E. I don't understand this email. What case 3 are you talking about here ? Jeremy.
Re: Access and Corrupt DB
On Mon, Apr 22, 2002 at 11:47:42AM -0400, William Jojo wrote: I'm posting this again. Jeremy, this seems very bad. We are running AIX 4.3.3 with 2.2.4-pre AND 5.1.0 with 2.2.4-pre. The problem is when you reopen a table you just created, MS-Access hurls and indicates the Visual Basic application database is corrupt. * This happens when you have the database on a Samba share. * This does NOT happen when saved to the C: drive. * MS-Office (2000 and XP) is served from a Samba share. * Office-2000 *and* Office XP do it when the database is on a Samba share. * The same error occurs on 2.2.3 and 2.2.3a. * Samba 2.2.2 and earlier does *NOT* have the problem. * There is a log at http://www.hvcc.edu:/~jojowil If there is anything more I can provide, please let me know...I'd like to see this fixed for 2.2.4 release. What I need is a debug level 10 log of the same operations performed to a 2.2.2 server where it works, and a debug level 10 log of *exactly* the same operation to a current (ie. CVS update from today) of SAMBA_2_2 server where it fails. There was a day around friday or so where the CVS tree had a bug w.r.t. error code returns that I fixed so a current checkout is essential. Can you get these to me asap ? Thanks, Jeremy.
Re: Cannot rename dir from win2k with last cvs version
On Tue, Apr 23, 2002 at 02:27:36PM +0200, Andreas Moroder wrote: Hello, I installed the cvs version from last friday. If a user on a win2k workstation tries to rename a directory in a samba share, he gets a error message. He can delete this directory or even create new ones. On a win98 machine there are no problems. The directory has rwxrwxrwx rights and the parent dir too. With a older cvs of samba it works well !! Does anyone know the reason ? Already fixed - it was a temporary problem in the CVS sources, sorry. Jeremy.
Re: Problem with current 2.2.4-pre
On Tue, Apr 23, 2002 at 07:11:41PM +0200, Beschorner Daniel wrote: Hi, if 2.2.4 is really at horizon, this bug in current CVS should be fixed. [2002/04/23 17:01:13, 0] smbd/open.c:open_file(179) Error doing fstat on open file kuhnert/NTUSER.DAT.tmp (No such file or directory) [2002/04/23 17:01:13, 0] smbd/open.c:open_file(179) Error doing fstat on open file kuhnert/ntuser.dat.LOG.tmp (No such file or directory) I just fixed this in SAMBA_2_2 and HEAD cvs. It's actually a spurious error message, not a fatal flaw. Jeremy.
Re: Access and Corrupt DB
On Mon, Apr 22, 2002 at 02:02:05PM -0400, William Jojo wrote: It would be from [homes] h:\db#.mdb where # is the attempt number that we did at that time...are you checking the 222 and 223a versions of the logs? Yes, I'm looking at both these logs. The only difference I can see is that in the 2.2.2 log the open for My Documents\db7.mdb succeeds because the file is there, and in the 2.2.3a log it fails as the file is not. Can you completely wipe the profile for this user and just try it (Access) against a Samba 2.2.4pre server that isn't serving profiles as well on a mapped drive that is only serving the shared access db files. That should simplify this log considerably and enable me to find out what the problem is. Can you give me a telephone number and timezone so I can call you about this - it's my last showstopper before 2.2.4 Thanks, Jeremy.
Re: [Samba] WinNT offline file attribute
On Wed, Apr 24, 2002 at 07:47:29PM -0700, Shirish Kalele wrote: Jerry, csc policy is for client-side offline caching. I think Damir is looking for Samba to support files offlined by storage managers like HSM. Both are called offline files. One of the reasons the csc policy parameter was so named. Samba could set the 'offline' flag in the files attributes to indicate the file is offlined. This makes applications like Explorer not open and read files just to display the icons (which would force the manager to bring the files online again). A special offlined icon is displayed instead. As I understood it (and I could be wrong), indicating offline wasn't a problem, the problem was finding out if a file was offline. I'm sure Damir could code up a custom fix to make Samba do it (using ioctl's or whatever) and distribute the fix as his patch. But I don't see how there could be a generic fix. I remember there was talk of such a thing. Yes, the problem is there is no standard POSIX call to tell if a file is offline or not. Jeremy.
Re: Too Many Open Files on 2.2.4???
On Tue, May 14, 2002 at 09:54:21AM +0930, Tristan Ball wrote: Guys, I'm getting the following in some of my logs: [2002/05/14 08:36:21, 0] lib/debug.c:reopen_logs(349) Unable to open new log file /var/log/samba/log.dancer: Too many open files [2002/05/14 08:36:21, 0] lib/username.c:map_username(130) can't open username map /etc/samba/smb.user.map. Error Too many open files However I can't see how I'd be anyware near the limit of file discriptors. I've used plimit, ulimit, and MAX_OPEN_FILES in local.h to up every limit I can find, and it's still happening! Host is solaris 2.8, samba 2.2.4 from cvs. Clients are Win nt/2k, running clearcase 4.2. If I pick one of the samba processes thats given log errors, and run pfiles on it, It shows 1303 open files, but an rlimit of 2. This is probably the somewhat braindead Solaris STDIO library biting you. It cannot cope with FILE * pointers if the underlying fd number opened is over 256 (it uses an unsigned char for the fd member of the FILE struct). This is why tridge wrote the XFILE library for HEAD (3.0). I believe there are replacement stdio libraries for Solaris that don't have this problem but - try forcing Samba to link with something like sfio for example. Does anyone know when Solaris will fix this problem ? Jeremy.
Re: Buglist to fix before 2.2.5
On Fri, May 17, 2002 at 01:25:52PM -0300, Ariel Mella wrote: i know that is part of the samba distribution but is away of the samba team but, could you include the recycle bin vfs module? Yes, we should add that to the rpms I think. Jeremy.
Re: Solaris and Samba Record Locking
On Mon, May 20, 2002 at 01:19:31AM -0700, Anjaneya Sastry wrote: Hello Everybody, Can you help ? Our application is in RMCOBOL. We use Rmcobol Index files. These are located in Solaris 2.8. Using Samba 2.2 we created a share and accessing the directory from windows. From windows we are running RMCOBOL runtime ver 7.0 and manipulating the shared files. At the same time other programs may be accessing these files by RUNCOBOL of solaris runtime which is in Solaris system. Our problem is the locks set by Windows cleints are not reflected in solaris runtime. This same problem we faced in Pcnetlink 1.2 (even after setting the parameter refelct client created locks in solaris ). Can this type of locking is possible ? Please let me know. Yes, you need to remove the oplocks that Samba is granting to clients in order for the Windows locks to be seen by the UNIX clients. Try adding the following two lines to your smb.conf, oplocks = no strict locking = yes This will slow Samba down some but will cause the Windows locks to be correctly seen under UNIX. Jeremy.
Re: Proposed code cleanup
On Thu, May 23, 2002 at 01:01:05AM +1000, Andrew Bartlett wrote: (I was going to commit this, but decided that I should get some comment first) More code cleanup - this lot a bit more dodgy than the last: The aim is to trim pwd_cache down to size. Its overly complex, and a pain to deal with. With a header comment like this: 'obfusticaion is planned' I think it deserved to die (at least partly). It deserves to die completely (IMHO). I remember Luke adding that code and I was never happy with it. This patch looks ok (IMHO). Jeremy.
Sun finally ships Samba as standard on Solaris 9
Well you won't find them shouting about it, but if you dig down in their web pages on Solaris 9 you'll find this : Common Linux applications, such as Samba, Apache, Linux (GNU) commands, etc., are included in the Solaris 9 Operating Environment. The Solaris Software Companion CD has an even more comprehensive set of free software. So I guess that means we made it onto the OS CD (finally :-) :-). Dave CB - want to comment ? Jeremy.
Re: Thanks for fixing oplock.c for Linux 2.0 in 2_2 CVS
On Thu, May 23, 2002 at 02:56:05PM -0400, Richard Bollinger wrote: Much thanks and praises to whomever diagnosed and fixed the timing problems with linux 2.0 and oplocks. On one busy 2.0.38 server, I had seen consistent oplock timeouts... especially when running an executable DOS program from the share... only the problem would not reproduce on other machines. This problem had been around as far back as 2.0.7. That was me :-). So have you CVS checked out and tested the code ? I have been testing it to destruction on a HP 2.0.x machine (the Print Service Appliance is based on 2.0.x linux) but would appreciate some independent confirmation of my fixes. Cheers, Jeremy.
Re: Thanks for fixing oplock.c for Linux 2.0 in 2_2 CVS
On Thu, May 23, 2002 at 03:18:04PM -0400, Richard Bollinger wrote: I only ran a quick functionality test ... a very old version of Netbench (2.10). It always hung for 30 seconds when starting netbench.exe... until the oplock timed out. Seems fine now. Great ! Thanks - good news. This will be in 2.2.5 and 3.0. Cheers, Jeremy.
Re: zero size of mapped drives on samba2.2.4 with quotas
On Thu, May 23, 2002 at 10:39:45PM +0400, Michail Vidiassov wrote:
Dear Guru,
I am running samba 2.2.4 on FreeBSD 4.5
The size of mapped drives with quota enabled is always shown as 0 by W2k.
There was no such problem with samba 2.2.3a.
As far as I undestand, th esource of the problem is the following change
of source/smbd/trans2.c (it was intended to
fixe the display of the 'size on disk' property of files from w2k):
===
RCS file: /cvsroot/samba/source/smbd/trans2.c,v
retrieving revision 1.149.4.75
retrieving revision 1.149.4.76
diff -u -r1.149.4.75 -r1.149.4.76
--- samba/source/smbd/trans2.c2002/04/12 01:33:08 1.149.4.75
+++ samba/source/smbd/trans2.c2002/04/12 15:34:01 1.149.4.76
-1421,12 +1421,13
case SMB_QUERY_FS_SIZE_INFO:
case SMB_FS_SIZE_INFORMATION:
{
- SMB_BIG_UINT dfree,dsize,bsize;
+ SMB_BIG_UINT dfree,dsize,bsize,secs_per_unit;;
data_len = 24;
conn-vfs_ops.disk_free(conn,.,False,bsize,dfree,dsize);
- SBIG_UINT(pdata,0,dsize);
- SBIG_UINT(pdata,8,dfree);
- SIVAL(pdata,16,bsize/512);
+ secs_per_unit = 2;
+ SBIG_UINT(pdata,0,dsize*(bsize/(512*secs_per_unit)));
+ SBIG_UINT(pdata,8,dfree*(bsize/(512*secs_per_unit)));
+ SIVAL(pdata,16,secs_per_unit);
SIVAL(pdata,20,512);
break;
}
This code seems to have problems in case bsize=512.
It is the case with FreeBSD and disk quotas enabled.
Reversing the patch solves my disk size problem.
I seek confirmations / comments.
Can you try applying the following patch - this may not be the
correct fix - I'm checking with tridge (who wrote the original
code) to be sure.
Thanks,
Jeremy.
Index: smbd/trans2.c
===
RCS file: /data/cvs/samba/source/smbd/trans2.c,v
retrieving revision 1.149.4.80
diff -u -r1.149.4.80 trans2.c
--- smbd/trans2.c 2002/05/20 16:41:45 1.149.4.80
+++ smbd/trans2.c 2002/05/23 22:14:45
-1439,6 +1439,12
SMB_BIG_UINT dfree,dsize,bsize,secs_per_unit;;
data_len = 24;
conn-vfs_ops.disk_free(conn,.,False,bsize,dfree,dsize);
+ if (bsize 1024) {
+ SMB_BIG_UINT factor = 1024/bsize;
+ bsize = 1024;
+ dsize /= factor;
+ dfree /= factor;
+ }
secs_per_unit = 2;
SBIG_UINT(pdata,0,dsize*(bsize/(512*secs_per_unit)));
SBIG_UINT(pdata,8,dfree*(bsize/(512*secs_per_unit)));
Re: Thanks for fixing oplock.c for Linux 2.0 in 2_2 CVS
On Fri, May 24, 2002 at 10:00:43AM -0400, Richard Bollinger wrote: How embarassing... still apparently broken / inconsistent :-( Client is win98 4.10.1998. [2002/05/24 08:36:40, 0] smbd/server.c:main(707) smbd version 2.2.5-pre started. Copyright Andrew Tridgell and the Samba Team 1992-2002 (rab@LS01) (gcc version 2.7.2.3) #1 Fri May 24 07:21:54 EDT 2002 i586-pc-linux-gnulibc1 [2002/05/24 08:36:41, 1] lib/debug.c:debug_message(258) INFO: Debug class all level = 1 (pid 14812 from pid 14812) [2002/05/24 08:36:42.394090, 1, pid=14812] smbd/files.c:file_init(166) file_init: Information only: requested 1 open files, 246 are available. [2002/05/24 09:02:09.743130, 1, pid=21159] smbd/service.c:make_connection(653) p139 (x.x.x.x) connect to service tmp as user rab (uid=5255, gid=6641) (pid 21159) [2002/05/24 09:02:49.071320, 0, pid=21159] smbd/oplock.c:oplock_break(786) oplock_break: receive_smb timed out after 30 seconds. oplock_break failed for file netbench/netbench.exe (dev = 900, inode = 181, file_id = 1). [2002/05/24 09:02:49.098472, 0, pid=21159] smbd/oplock.c:oplock_break(858) oplock_break: client failure in oplock break in file netbench/netbench.exe Well, this is a client failure to respond. The does happen sometimes, especially with Winx9 clients - their TCP stack is ... well not wonderful, let's just say :-). Dropped packets for whatever reason can also cause this. It doesn't mean the fix is bad, occasionally this will just happen (it does on NT servers also, they just don't log the message like we do :-). Jeremy.
Re: Thanks for fixing oplock.c for Linux 2.0 in 2_2 CVS
On Fri, May 24, 2002 at 02:05:12PM -0400, Richard Bollinger wrote: OK... time for a brain flush and refill... I went back and verified my test conditions and determined that the same failure can be demonstrated with every server platform we own running Samba 2.X with oplocks enabled and with a Win98 client. Here's the setup: On Win98 client: net use i: \\server\share1 On Server: smbd instance goes away by dead time exceeded or with kill command On Win98 client: net use j: \\server\share2 j: cd netbench netbench.exe--- here's where we get the oplock freeze for 30 seconds I can send you a copy of the netbench directory off list if you need it. I suspect the same failure will happen for any DOS executable. What is the Linux kernel version you are running ? Can you confirm it happens with any DOS executable and I'll then try and reproduce the problem. Thanks, Jeremy.
Re: Thanks for fixing oplock.c for Linux 2.0 in 2_2 CVS
On Fri, May 24, 2002 at 07:16:07PM -0400, Richard Bollinger wrote: Same exact failure with Linux 2.0.38 Linux 2.2.20 Linux 2.4.18 SunOS 5.6 I'll have to let you know Tuesday if it fails with just any old executable... but I'd expect it would. Well can you send me the netbench.exe binary we know fails then please so I can work on this and get it fixed over the weekend. Jeremy.
Re: Thanks for fixing oplock.c for Linux 2.0 in 2_2 CVS
On Fri, May 24, 2002 at 02:05:12PM -0400, Richard Bollinger wrote: OK... time for a brain flush and refill... I went back and verified my test conditions and determined that the same failure can be demonstrated with every server platform we own running Samba 2.X with oplocks enabled and with a Win98 client. Here's the setup: On Win98 client: net use i: \\server\share1 On Server: smbd instance goes away by dead time exceeded or with kill command On Win98 client: net use j: \\server\share2 j: cd netbench netbench.exe--- here's where we get the oplock freeze for 30 seconds I can send you a copy of the netbench directory off list if you need it. I suspect the same failure will happen for any DOS executable. Ok - I've been looking at this - it only happens if the smbd has been killed in between the first and second net use commands. The client repeatably fails to respond to a valid oplock break request I'm looking into this more. Jeremy.
Re: Thanks for fixing oplock.c for Linux 2.0 in 2_2 CVS
On Fri, May 24, 2002 at 10:26:00PM -0400, Richard Bollinger wrote: Right... or if it times out because of the dead time setting... so it's shouldn't be that rare in the wild. I have a feeling that a lot of folks just disable oplocks to avoid the troubles. My test at work showed that the problem did not occur with a W2K server when I forced the disconnect from the server end. Yes, I just tried that - same result. We're definately triggering a Win9x client bug, it behaves differently when talking to Samba than to Win2k, when talking to Win2k it closes the file before asking for the re-open, thus not getting the oplock break request. With us, it requests a second open without doing the close first. I'm still looking at why we cause it to do that Jeremy.
Re: Thanks for fixing oplock.c for Linux 2.0 in 2_2 CVS
On Fri, May 24, 2002 at 10:26:00PM -0400, Richard Bollinger wrote: Right... or if it times out because of the dead time setting... so it's shouldn't be that rare in the wild. I have a feeling that a lot of folks just disable oplocks to avoid the troubles. My test at work showed that the problem did not occur with a W2K server when I forced the disconnect from the server end. Well, I've managed to get this to happen to a W2K server too, took me a while though. It's definately a client bug with the Win9x client, but we seem to trigger it all the time whereas Win2k seems to trigger it sometimes. I've also finally got a trace where a W2K server resends an oplock break twice, after 300ms - this must be their magic timeout to wake up the client. This is *extremely* interesting. I'm cc:ing this to tridge directly, in case he doesn't believe me :-) :-). There are definately some subtle heuristics in play here - on my vmware W2k server it doesn't seem to grant oplocks to the Win9x client after the restart - on my real win2k server it does. I need to play with this more and understand it (lucky it's a long weekend :-) :-). Jeremy.
Re: Microsoft's Dfs
On Thu, May 30, 2002 at 06:06:52AM +0930, Richard Sharpe wrote: Has it been checked on FreeBSD? If not, if you give me the source, I will check it for you. It is GPL code. I don't think it can be used in the FreeBSD kernel (correct me if I'm wrong Steve). Jeremy.
Re: Thanks for fixing oplock.c for Linux 2.0 in 2_2 CVS
On Sat, May 25, 2002 at 02:05:19PM -0700, Jeremy Allison wrote: Well, I've managed to get this to happen to a W2K server too, took me a while though. It's definately a client bug with the Win9x client, but we seem to trigger it all the time whereas Win2k seems to trigger it sometimes. I've also finally got a trace where a W2K server resends an oplock break twice, after 300ms - this must be their magic timeout to wake up the client. This is *extremely* interesting. I'm cc:ing this to tridge directly, in case he doesn't believe me :-) :-). Actually this was a TCP retransmit (shame :-). Ok - I've played with this a lot and it seems to be completely reproducible against a W2K SP2 server as well. If you stop and then restart the Server service on W2k, with a Win98 client connected, then the Win98 client stops responding to oplock break requests. Now this is unfortunate in that it happens more to Samba than to W2K as the idling of connections can cause the serving smbd to kill itself. It causes a 30 second wait the first time you try and run an executable, but after that we stop granting oplocks to that client and so everything should keep going. Jeremy.
Re: Thanks for fixing oplock.c for Linux 2.0 in 2_2 CVS
On Wed, May 29, 2002 at 05:09:00PM -0400, Richard Bollinger wrote: Stoping the server service is a very unusual step. Disconnecting an individual connection, possibly via idle timeout, is not so unusual and I don't see the same behaviour with W2K server vs Samba. Something else must be going on. Ah, but to the client disconnecting an individual connection via idle timeout on Samba and stopping the server service on W2K are *identical* at the network layer - ie. they both tear down the TCP connection. Under W2K TCP connections are never idled, so they remain active to the box and thus to re-create what Samba is actually doing stopping the server service is required, and indeed when this is done the same client bug is revealed. It looks like idling a client connection is dangerous to a Win98 box, we can only do a work-around for this as the bug is in the Win9x client, I'll think some more about this. Jeremy.
Re: Thanks for fixing oplock.c for Linux 2.0 in 2_2 CVS
On Thu, May 30, 2002 at 08:10:22AM +1000, Andrew Bartlett wrote: Isn't there a way we can 'idle' the connection by tearing down the protocol? Actually issuing a 'you are idle, shutting down' to the client? Nope - would require a client change I'm afraid. There's nothing in the protocol to allow this. Jeremy.
Re: Thanks for fixing oplock.c for Linux 2.0 in 2_2 CVS
On Wed, May 29, 2002 at 04:48:27PM -0700, [EMAIL PROTECTED] wrote: And are you saying that Win2k will never 'idle' a client connection? I'm sure I've seen smbfs being 'idled' by NT before... I don't think it ever drops the TCP connection on purpose. Jeremy.
Re: Thanks for fixing oplock.c for Linux 2.0 in 2_2 CVS
On Thu, May 30, 2002 at 09:35:38AM +0200, Volker Lendecke wrote: On Wed, May 29, 2002 at 04:55:20PM -0700, Jeremy Allison wrote: On Wed, May 29, 2002 at 04:48:27PM -0700, [EMAIL PROTECTED] wrote: And are you saying that Win2k will never 'idle' a client connection? I'm sure I've seen smbfs being 'idled' by NT before... I don't think it ever drops the TCP connection on purpose. I'm quite positive it does. I have seen sites with 'security = server' fail miserably after having changed to W2k on the DC due to disconnects from the DC. No, I mean that the Win2k server service won't drop a client connection on purpose if there's no traffic on it (it doesn't idle connections). Jeremy.
Re: [PATCH] Clean up samba-3.0 for POSIX-96
On Fri, May 31, 2002 at 06:47:00PM -0400, [EMAIL PROTECTED] wrote: The attached set of patches cleans up samba-3.0-alpha17 for systems such as Stratus VOS that implement POSIX-1996 but do not provide full Unix compatibility. I would be most grateful if this patch could be applied against samba-3.0. I can supply a version of this patch for samba-2.2 if/when anyone cares. Please send a SAMBA_2_2 version as well, I'll ensure it gets into 2.2.5. Thanks, Jeremy.
Re: Thanks for fixing oplock.c for Linux 2.0 in 2_2 CVS
On Fri, May 31, 2002 at 05:50:58PM -0700, Matt Seitz wrote: From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] The only thing would be to completely disallow connection timeouts for Win9x clients - I'm not sure this is what we want. Perhaps timeouts could be prevented for a 9x client when an oplock is present? Or have two timeouts: a shorter (soft) timeout when an oplock is not present and a longer (hard) timeout even when an oplock is present? No, you can't time out at all. Remeber, as soon as you time out and drop the connection (TCP RST or FIN) you're dead - the client will exhibit this bug. There is no way around this with different timeouts, it's very simple - drop a connection to a Win9x client, suffer an oplock break bug in the client. No other way around this client bug. Jeremy.
Re: [PATCH] Clean up samba-2.2 for POSIX-96
On Sat, Jun 01, 2002 at 02:52:00PM -0400, [EMAIL PROTECTED] wrote: At Jeremy's request, here is a version of the POSIX-96 cleanup patches for the Samba 2.2 branch. Applied, thanks ! Jeremy.
Re: Access control to SAM / _samr_query_sec_obj
On Wed, Jun 05, 2002 at 07:51:53PM +0200, Kai Krueger wrote:
This is the first version of the patch to implement access control to SAM.
It implements checks of the desired access in all open functions (those that create
handles)
against the appropriate default SDs of the previous patch and associates the granted
access bits
with the handle. These granted access bits are then used in the other functions to
check if the
current handle (user) is allowed to run the function.
However, I'm not sure if the nt_user_token works correctly, especially if root by
default
belongs to the administrators alias. So to stop the patch braking write access to
the sam,
I've commented out all return nt_status_access_denied. I haven't had the possibility
to test
the nt_user_token, as the attempts to join my win2k workstation to the samba PDC
always fails :(
In effect the patch therefore currently doesn't do much except logging but can be
used for
testing. If it works, the changes are then minimal.
But the patch should at least be enough to see if it is conceptionally acceptable,
so any
comments or improvements are welcome.
Kai
--- ./samba-orig/source/rpc_server/srv_samr_nt.c Fri May 31 19:51:43 2002
+++ ./samba/source/rpc_server/srv_samr_nt.c Wed Jun 5 10:12:39 2002
-52,9 +52,47
/* for use by the \PIPE\samr policy */
DOM_SID sid;
uint32 status; /* some sort of flag. best to record it. comes from opnum 0x39 */
+ uint32 acc_granted;
DISP_INFO disp_info;
};
+struct generic_mapping sam_generic_mapping = {
+ 0x20010,
+ 0x2000e,
+ 0x20021,
+ 0xf003f
+};
Nice patch. I do have one request though. I've (for years)
been removing magic numerical constants from Samba (like
the 0xf003f in the patch above). We know what these numbers
are in SEC_ACL terms - can you please change the numbers to
a list of #defined constants :
ie. The 0x20010 above should map to :
READ_CONTROL_ACCESS plus a new constant that specifies READ
access to a SAMR, probably something like SAMR_READ_ACCESS
(as it's a specific right).
Thanks,
Jeremy.
Re: known BUG multi-byte character set in usernames
On Sun, Jun 02, 2002 at 07:44:02PM +0200, Juergen Hasch wrote:
Hi Jerry,
Am Sonntag, 2. Juni 2002 03:15 schrieb Gerald Carter:
On Fri, 31 May 2002, Juergen Hasch wrote:
Now I never would have brought this up because I don't care to much for
2.2 and I was just curious when I made the patches. But since someone
asked :-) The names/groups are transferred by rpc and converted from
unicode like this: unistr2_to_ascii(t, info1.str[j].uni_acct_name,
sizeof(pstring)); Adding the line
dos_to_unix(t);
makes the umlaute appear.
Now the charset conversion may be totally wrong there, I believed it to
be *easiest* patch.
please send me thispatch for 2.2 if you ave it. Thanks.
I believe the most simple patch would be:
--- lib/util_unistr.c.orig Tue Apr 2 18:27:59 2002
+++ lib/util_unistr.c Sun Jun 2 14:01:57 2002
-311,7 +311,7
/***
Convert a (little-endian) UNISTR2 structure to an ASCII string
- Warning: this version does DOS codepage.
+ Warning: this version does UNIX codepage.
/
void unistr2_to_ascii(char *dest, const UNISTR2 *str, size_t maxlen)
-335,7 +335,7
for (p = dest; (p-dest maxlen-3) (src - str-buffer
str-uni_str_len) *src; src++) {
uint16 ucs2_val = SVAL(src,0);
- uint16 cp_val = ucs2_to_doscp[ucs2_val];
+ uint16 cp_val = ucs2_to_unixcp[ucs2_val];
if (cp_val 256)
*p++ = (char)cp_val;
However, unistr2_to_ascii is used in the printing stuff, too and I don't want
to mess with this mess :-)
A less radical patch is attached therefore, adding a new function
unistr2_to_unix which returns the unix charset instead of the dos codepage.
Also unistr2_tdup is changed to call unistr2_to_unix. It is only used in
nsswitch/winbind_rpc.c.
I've just committed a modified version of this patch to SAMBA_2_2,
if you could test it out I'd appreciate it.
Thanks a *lot* for this patch !
Jeremy.
Re: known BUG multi-byte character set in usernames
On Thu, Jun 06, 2002 at 12:12:45AM +0200, Juergen Hasch wrote: the patch works fine for except for one thing. In the acl security selection list (showing a list of all available users and groups) the german umlaut characters are wrong. This is because the unix charset is sent to the windows client, as no conversion back takes place. The acl dialogue itself is ok. I haven't found out yet, where the conversion back to dos code page should take place. Do you have an idea ? Can you CVS update SAMBA_2_2 - I've just applied a patch I think should fix this. Cheers, Jeremy.
Re: known BUG multi-byte character set in usernames
On Thu, Jun 06, 2002 at 09:03:05PM +0200, Juergen Hasch wrote: The conversion in srv_samr_nt.c is needed to show the correct group list in the ACL-add dialogue. The conversion in lsa_srv_nt.c is needed to set a new ACL entry in unix codepage after selecting it from the list. The change in winbind_rpc.c is needed to get wbinfo -n working. I accepted all of these except the winbindd ones - I fixed those instead by making cli_lsa_loopupnames() take UNIX charset, not DOS codepage. Please CVS checkout and test. Thanks a *lot* ! Jeremy.
Re: Samba 2_2 CVS w/ Linux 2.4.18 Oplock Hangup... Help!
On Thu, Jun 06, 2002 at 03:39:59PM -0400, Richard Bollinger wrote: Test scenerio: Server: Samba 2_2 CVS as of morning of 6/4/2002. Linux 2.4.18 ext2 file system. AMD Athlon processor. On PC... net use f: \\server\share type hi.txt On Server... smbstatusshows the file oplocked cat hi.txthangs until control C hit On PC... net use f: /d On Server... smbstatusshows the connection still in effect and file still oplocked! cat hi.txtstill hangs until control C hit smbstatus output: Samba version 2.2.5-pre #1 Tue Jun 4 14:03:39 EDT 2002 Service uid gid pid machine -- u_tmprab tcs 30240 p139 (128.1.3.139) Thu Jun 6 15:22:51 2002 Locked files: PidDenyMode Access R/WOplock Name -- 30240 DENY_NONE 0x1 RDONLY EXCLUSIVE+BATCH /u/tmp/hi.txt Thu Jun 6 15:23:28 2002 I think I have just fixed this. Could you please try CVS updating on the SAMBA_2_2 branch and testing again ? Thanks, Jeremy.
Re: Problem copying files from Win2k Novell client to Samba (repost)
On Thu, Jun 06, 2002 at 12:40:46PM -0400, Dan Barrett wrote:
The problem I reported would occur with Samba 2.2.4, but not 2.2.2. set_sd() in
2.2.4 returns False if the sd_len passed by the client is 0. This would be okay,
except Novell clients apparently set sd_len=0.
To fix the novell problem, I changed set_sd() to return True, not False if
sd_len==0. I never got a response on why this code was added to 2.2.4.
-Dan Barrett
static BOOL set_sd(files_struct *fsp, char *data, uint32 sd_len, uint32
security_info_sent, int *pdef_class,uint32 *pdef_code)
{
prs_struct pd;
SEC_DESC *psd = NULL;
TALLOC_CTX *mem_ctx;
BOOL ret;
/* Stock Samba fails if sd_len==0, but some Novell client copies pass SMB
requests with valid EA info, but no SD. We want to allow these types of opens.*/
if (sd_len == 0) {
DEBUG(5,(set_sd: sd_len==0. Allowing anyway.\n));
*pdef_class = 0;
*pdef_code = 0;
return True;
}
In what SMB calls do the Novell clients set sd_len == 0 ?
I can see allowing this in the NT_TRANSACT_CREATE call
(which is the same as NTcreateAndX but supposedly with SD
info as well), but not in the nt_transact_set_security_desc
call, whose whole purpose is to set SD's.
Can you give me some more info (ASAP if I'm going to get
this fixed for 2.2.5 please).
Jeremy.
Re: Problem copying files from Win2k Novell client to Samba (repost)
On Fri, Jun 07, 2002 at 09:36:12AM -0400, Dan Barrett wrote: Jeremy, I only observed sd_len==0 from our Novell clietn for NT_TRANSACT_CREATE. My first attempt at a fix was in call_nt_transact_create(), and it worked for my problem. So NT_TRANSACT_CREATE was the sd_len==0 for our particular problem. Ok, this is the fix I just added. Can you CVS update the SAMBA_2_2 branch and check it work ok please ? Thanks, Jeremy.
Re: 2.2.5pre1: unlink design flaw
On Thu, Jun 13, 2002 at 08:28:08PM +0200, Simo Sorce wrote: I can't remember just now, but can you rename it while open? Under POSIX, yes. If you can, then you may rename the file on unlink to a very rare name and then delete oin close(). This is what NFS does. I have no idea what posix says about open and unlink, but I'm guessing if it's been unlinked it shouldn't prevent creating a new file (or dir). Maybe jeremy (our posix man :-P) can tell us this one. Yes, you can unlink whilst open and then create a new dir or file with the same name, it will occupy different disk space. Jeremy.
Re: passdb TODO list
On Fri, Jun 14, 2002 at 05:02:58PM +0300, Toomas Soome wrote: I cave an question regarding to pdb_ interface. in 2.2 pdb_nisplus code I translated some strings from dos to unix and vice-versa. this translation helped to manage information correctly from windows side and from unix side. now unix_to_dos and dos_to_unix calls are gone in 3.0, what should I do? is this translation needed at all in 3.0? What we're going to need for 3.0 is to wrap all incoming system strings in a function that converts to internal format, and wrap all outgoing system strings in a function that converts back. Then we need to determine what we will store our strings in (probably utf8), then we need to write upgrade code that will convert from our current mix of DOS and UNIX codepages in databases into utf8. This is one of the reasons why 3.0 is further away than we think - this has to be done before we can get ready to ship. Jeremy.
Re: passdb TODO list
On Sat, Jun 15, 2002 at 12:25:42AM +1000, Andrew Bartlett wrote: Otherwise, all strings are 'unix strings'. But what character set is a unix string ? What if we get an incoming UCS2 string that doesn't map ? We need to use utf8 in all the backends. This is a good chance to fix this mess once and for all and I think we should take it. Jeremy.
SMB signing.
Hi all, Is anyone using Windows SMB signing in a production environment ? This is the signing proceedure created by setting the Registry keys EnableSecuritySignature:1, RequireSecuritySignature: 1 in the lanmanserver and lanmanworkstation parameters. I'm playing with implementing this in Samba for 3.0, but am finding that it doesn't seem to work when mixing Windows NT or Windows 2000 clients with Windows XP servers. The clients get ACCESS_DENIED messages from the servers and the signing verification seems to fail. Of course it doesn't match the published spec, but that's just to be expected I guess :-) :-). I'd appreciate any data points from people actually running with this turned on. Thanks, Jeremy Allison, Samba Team.
Re: Winbind problem or my problem:)
On Thu, Jun 20, 2002 at 12:28:18PM -0500, Esh, Andrew wrote: Suggest the following fix: Index: winbindd_rpc.c === RCS file: /cvsroot/samba/source/nsswitch/winbindd_rpc.c,v retrieving revision 1.22.2.7 diff -u -c -r1.22.2.7 winbindd_rpc.c cvs server: conflicting specifications of output style *** winbindd_rpc.c 6 Jun 2002 21:12:47 - 1.22.2.7 --- winbindd_rpc.c 20 Jun 2002 17:31:25 - *** *** 315,320 --- 315,323 result = cli_samr_query_userinfo(hnd-cli, mem_ctx, user_pol, 0x15, ctr); + if (!NT_STATUS_IS_OK(result)) + goto done; + cli_samr_close(hnd-cli, mem_ctx, user_pol); got_user_pol = False; Applied - thanks ! Jeremy.
Re: Some additional questions about benchmarking CIFS servers
On Sat, Jun 22, 2002 at 02:25:41AM +0930, Richard Sharpe wrote: To what extent do people feel that these are relevant to a CIFS benchmark, and what other areas have I missed. Well in defense of NetBench (I can't believe I'm saying this :-) it doesn't attempt to give full coverage of SMB, that would be the job of a conformance tester. It only tries to shovel data to the server as fast as possible, trying to create realistic capacity situations. Just having a simple, Open Source/Free Software benchmark that would do the same would be a good start, we can argue about how to extend it once we have buy in that the new benchmark makes a good NetBench replacement (ie. can we get the magazines to run it instead of NetBench). Jeremy.
Re: advice for quick hack on _old_ code?
On Fri, Jun 21, 2002 at 01:47:04PM -0700, Ben Johnson wrote: As far as I know we do publish the open source code we use. I don't know where or how it is published, but there is so much open source code in it that I can't imagine we'd make that kind of mistake. It's build around a Linux kernel and I believe most new features added start with GPL'd code. I am sure someone would be happy to talk to you about this though. Ok, cool - fair enough :-). It didn't appear obvious that it was a Linux based box so I was immediately somewhat wary :-). Thanks for letting us know :-). Jeremy.
Re: VFS on 2.2.5 and FreeBSD -stable
On Wed, Jun 26, 2002 at 11:53:59AM -0500, David W. Chapman Jr. wrote: Some users are reported as getting these errors in the logs when using samba 2.2.5 and the recycle bin on FreeBSD, any ideas? http://www.freebsd.org/cgi/query-pr.cgi?pr=39850 smbd must be compiled so that it is exporting symbols that a dlopen'ed VFS module can link back to the loading smbd. It looks like these people have compiled smbd without the ld option that means it will export its symbols. Hope this helps, Jeremy.
Re: FW: samba woes
On Wed, Jun 26, 2002 at 01:43:54PM -0400, Johnston, Christopher (DCSA) wrote: Quote from Redhat: Hi, I have an update on your issue! A direct quote from engineering on your issue: As I understand it, smbsh can not work on the recent glibc versions as they no longer support the LD_PRELOAD features (hacks? :) smbsh employs. On non linux unix variants smbsh will still work in general (they dont after all use glibc). The LD_PRELOAD user space fs simply wont work on recent glibc versions alas, LD_PRELOAD itself certainly still works. It\'s the \back door\ symbols _open, _read, _write which allows smbsh to wrap around the normal file calls, possibly redirect them to smb, and then call the actual C library function using the underscore functions. The GNU C library maintainers have decided to remove support for these symbols in glibc 2.1and forward. So, overall maybe this is the good reason of why we do not have smbwrapper/smbsh shipped :-) I would use autofs, to do the same functionality. You\'d need a program that uses libsmb (or just calls smbclient) to retrieve the browse list, and reformats it into an autofs map. Jp Robinson I am just trying to gather some thoughts here to see if anybody has has experiene with an issue like this.. this may not be a samba thing but a GLIBC issue.. any ides? suggestions on what to work on next? Yes, I'm pretty sure this is a glibc issue. I'm not sure why (for what technical reason) the GLIBC maintainers decided to do this, as it breaks all user level filesystems that depend on the same trick that smbsh uses. It seems like we can only support smbsh on libc systems which support this, that does not include Linux at this time. Jeremy.
Re: [Samba] RE: FW: samba woes
On Wed, Jun 26, 2002 at 02:06:39PM -0400, Johnston, Christopher (DCSA) wrote: Jeremy, Thanks.. is there a fix for this sometime in the future? or is this something that has to do with GLIBC not allowing these symbols or functions to be used anymore? It is a GLIBC issue as far as I'm aware. They just removed the ability to redefine these symbols, something smbsh depends on. Nothing we can do about it I'm afraid, it was a decision by the GLIBC maintainers (and I'm not aware of the technical reasons for it, or if they provided a work-around in any way). Jeremy.
Re: [Samba] RE: FW: samba woes
On Wed, Jun 26, 2002 at 02:25:56PM -0400, Johnston, Christopher (DCSA) wrote: That stinks.. so smbsh is pretty much usueless at this point unless those symbols get put back into glibc.. On Linux, yes. It still works on Solaris I think. Jeremy.
Re: [Samba] RE: FW: samba woes
On Wed, Jun 26, 2002 at 01:30:03PM -0500, Steve Langasek wrote: Dave C-B has previously posted here details of an smbsh redesign that would allow preloading of libsmbwrapper.so to work under Linux in spite of the glibc changes. In fact, it would work better, as his design doesn't require *any* of the current autoconf checks for systems that support dlsym(RTLD_NEXT). That includes Linux, the BSDs, and Solaris, AIUI, and possibly other systems where smbsh is currently used. It's simply a matter of digging in and recoding libsmbwrapper. Oh, thanks Steve, I missed that. Can you point me to the mailing list archives for this ? Maybe we can get it done for 3.0.x ? Jeremy.
Re: [Samba] RE: FW: samba woes
On Wed, Jun 26, 2002 at 02:30:44PM -0400, Johnston, Christopher (DCSA) wrote: Yea we have it working on Solaris 2.8 with no problems at all.. just need it on Linux.. since that is the big push from management.. Since I got you hot on this email.. winbindd.. has there been any plans in to have some sort of a centralized database for SID-UID mappings? or some sort of a PAM plugin to authenticate against a winbindd server? Yes it's planned. Not sure on timeframe though. We'll be spending lots more time on getting 3.0.x out in the next few months. Jeremy.
Re: VFS on 2.2.5 and FreeBSD -stable
On Wed, Jun 26, 2002 at 05:57:24PM -0500, Christopher R. Hertel wrote: Jeremy Allison wrote: : Oh don't tell me we've run into the *BSD of the month club :-). Thank goodness Slackware and Debian and Mandrake and SuSE and RedHat and Caldera and Redmond and Trinux and Yellowdog are all so uniform. ...and Armed and Arch and BasLinux and BeeHive and Blackcat and cLIeNUX and Coyote and Dragon and elx and Dualix and Engarde and Finnix and Frazierwall and Gentoo and Gibraltar and Giotto and Yes, they're all Linux, and yes, we don't have to add specific configure tests for them. Besides which, everyone knows that RedHat and the (soon to be United)Linux are the only ones that matter (Now I need to duck :-) :-). Jeremy.
Re: [Security Problem] --with-tdbsam
On Mon, Jul 01, 2002 at 09:39:46PM +0900, Yasuma Takeda wrote: In Samba-JP, buffer overflow problem was reported. If samba is configured with --with-tdbsam, init_sam_from_buffer function contains a buffer overflow vulnerability. In a certain case, user can use this vulnerability by changing his password. Please examine this security problem and take measures to be necessary. Can you send more details please to [EMAIL PROTECTED], and CC: [EMAIL PROTECTED] I don't immediately see the problem this patch is fixing and need to understand it before I can apply it. Thanks for pointing this out, Jeremy.
Re: [Security Problem] --with-tdbsam
On Mon, Jul 01, 2002 at 02:08:03PM -0700, Jeremy Allison wrote: Can you send more details please to [EMAIL PROTECTED], and CC: [EMAIL PROTECTED] I don't immediately see the problem this patch is fixing and need to understand it before I can apply it. Never mind - I see the problem now. Thanks ! Jeremy.
Re: patch for lpq output parsing for LPRng
On Mon, Jul 08, 2002 at 04:26:26PM +0800, James Henstridge wrote: [please keep me in the CC line for replies, as I am not subscribed to this list] Since upgrading one of our servers that handles a number of print queues to Red Hat 7.3, I started getting complaints about jobs not getting removed from the print queues -- they would get printed, then their status would change to paused in the print queue dialog on the Windows machines. This also meant that the printer icon in the system tray didn't disapear, which a number of users used to check when their job had finished printing. This problem occurs because the version of LPRng (3.8.9) that ships with RH7.3 lists the last few finished jobs in the output of lpq with their rank listed as done. The output looks something like this: Printer: hp5100@blinky (dest auto@hp5100) Queue: no printable jobs in queue Server: no server active Status: job 'james@blinky+708' saved at 16:06:16.677 Rank Owner/ID Class Job Files Size Time done carole@blinky+580A 580 smbprn.007629.i16aS5 99120 10:34:44 done james@blinky+708 A 708 smbprn.24.rW1nDr 72089 16:06:16 JetDirect lpd: no jobs queued on the port Auto I wrote a simple patch to solve this problem. If it encounters a print job with its rank set to done, it sets the status field to LPQ_PRINTED (which seems like the most appropriate status). This seems to solve the problem for us -- the completed jobs don't show up paused, and the printer icon in the system tray disapears when the job completes. It would be useful to get this patch included in future 2.2 releases. Applied - thanks ! Jeremy.
Re: Auditing with VFS
On Tue, Jul 09, 2002 at 05:07:30PM +0100, Daniel Niasoff wrote: When auditing with VFS the pathname recorded is only the relative path for the share not the the full path all the way from root. Are there any plans to change this as I want to use auditing as a method of backing up (i:e: record all files that have been written to and back them up automatically) and as the path is only relative to the share and I have no way of knowing which share is currently being accessed this would be rather difficult. Yes you do know the share path - it's stored in the connection struct passed into the VFS calls or pointed to from the files_struct passed into the VFS calls. Hope this helps, Jeremy.
Re: [Draft #2] Samba 3.0 roadmap...idmap storage central idmap repository
On Tue, Jul 09, 2002 at 03:32:50PM -0400, Michael Sweet wrote: In addition, no matter what Unicode representation is used, you still have to deal with different representations of the same character (is it a single character a with an umlat, or a plus a combining umlat character?, etc.) Only Apple does this to my knowledge. Microsoft does not use compose characters in their UCS2 on the wire. I'm voting with MS on this one :-). But Simo, I disagree about the internal rep. I think it needs to be utf8 for Samba internal strings. We already have to deal with mbcs issues - this doesn't make it any worse. Jeremy.
Re: Draft of branch maintainence and release plans....
On Wed, Jul 10, 2002 at 03:41:36PM -0400, ZINKEVICIUS,MATT (HP-Loveland,ex1) wrote: Yep, that's my code. I had been working with Jeremy to get this integrated but we hit a legal issue. It was recently overcome though he probably doesn't know it yet :-) No I didn't ! Tell me more please ! :-). Jeremy.
Re: How does Samba Solve this problem?
On Mon, Jul 22, 2002 at 02:48:48PM +0800, [EMAIL PROTECTED] wrote: As we know, in linux, there's no the concept of DENY MODE. In M$ windows, when open a file, you use the API CreateFile (LPCTSTR lpFileName, DWORD dwDesiredAccess, DWORD dwShareMode, LPSECURITY_ATTRIBUTES lpSecurityAttributes, DWORD dwCreationDistribution, DWORD dwFlagsAndAttributes, HANDLE hTemplateFile) the parameter dwShareMode define the deny mode, fo example, if open a file with DENY_WRITE, aother applications can't write this file. When M$ WORD open a file, then other applications can't write the same file. But in Linux , when open a file you use open(char *fname, int mode), there's no DENY MODE. So my question is that, What does Samba do to propose an open request with DENY MODE from a window client. Samba takes care of this internally in the share mode database, it's not visible to the Linux kernel. Jeremy.
