RH 8.0 (psyche)+samba 2.2.7a opposite to RH 7.2+samba 2.2.7a andFOXPRO DOS application
Hi everybody. I have one trouble with foxpro dos aplication. i use RH 8.0 + samba 2.2.7a as server file for foxpro dos application. This apllication is multi user. But, on RH 8.0 + samba 2.2.7a only one user can work with this foxpro apllication, because when anotehr try to loggin, he can see this foxpro system info: Record is used by another. I use another RH: 7.2 + samba 2.2.7. In this installation this problem not occur. All goes fine, user can login to this foxpro dos application without any problems. Any ideas ? Regards, Irek. --r-e-k-l-a-m-a- Szukasz banku bez prowizji ? mBank - zaloz konto http://epieniadze.onet.pl/mbank
Mapping windows drives onto Unix
Hi, I am trying to map windows 2000/NT drives onto Unix Box ( SunOS 5.6 sun4u sparc SUNW,Ultra-Enterprise-1 ) . The purpose to to pool data from VoIP servers to Unix. My questions are : 1. Is it possible to do it using Samba ? 2. If yes, then what are the softwares I need to install on Unix and Windows ? 3. Where can I get the software ? 4. What are the configuration steps ? Thanks Regards, Aditya Padhi - Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, and more
bug (or maybe not) in printing subsystem
Hi folks, tracked down a problem I mentioned last week with printing. When you use the rpcclient adddriver command as follows: adddriver Windows NT x86 name:NULL:NULL:NULL:NULL:NULL:NULL:NULL you get a NT_STATUS_UNSUCCESSFUL error, which further investigation reveals to be caused by an Access Denied error upstream. Further investigation of /that/ reveals that get_correct_cversion in printing/nt_printing.c is attempting to open the W32X86 directory as a file. This is, as far as I can tell, because the second field in the second parameter above is the driver file; setting it to NULL is somehow causing this problem. Setting the driver file to a valid printer driver file cures the problem. I don't know if this is a bug or just misuse on my part of the rpcclient command :) Cheers, Waider. -- [EMAIL PROTECTED] / Yes, it /is/ very personal of me. Some people just don't know which side of the good/evil thing to side with, despite the obvious fun now, pay later advantages of the evil side for those of us who need instant gratification.
Re: client: browse doesn't work with only win98 in workgroup
Christopher R. Hertel [EMAIL PROTECTED] writes: The problem is that W/9x boxes do not recognize the generic *SMBSERVER name in the NBT Session Setup Request. Also, W/9x boxes will send back an error if the called name is not correct in the NBT Session Setup Request. You should get a NEGATIVE SESSION RESPONSE (0x83) message with an error code of: 0x82: Called Name Not Present Since W/9x systems do not support the generic *SMBSERVER name, this error message is correct. Basically, it's the NBT equivalent of That port isn't listening for a connection. The solution is to find the Server Service name on the remote machine. This is typically done by sending a Node Status query and looking for a name with a suffix byte value of 0x20. Great! The information you provided here and interspersed in my message seems to be exactly what I needed. I should be able to implement this correctly now. I know that this is pedantic, but it's important to understand that there is a difference between the set of hosts in a workgroup and the servers offering SMB services in the workgroup. A host may be a client and it may not be offering SMB services, in which case it will not show up when you try listing the servers in the workgroup. I know enough right now to ask intelligible questions, although not yet with correct terminology. I appreciate you setting me straight. Your explanation of not only the correct terminology, but why the terminology I was using actually had a different meaning, was enlightening. Thanks for your help! Derrell
Re: client: browse doesn't work with only win98 in workgroup
On Mon, Mar 03, 2003 at 09:41:51AM -0500, [EMAIL PROTECTED] wrote: : I know enough right now to ask intelligible questions, although not yet with correct terminology. I appreciate you setting me straight. Your explanation of not only the correct terminology, but why the terminology I was using actually had a different meaning, was enlightening. Most welcome. As it happens, I am currently working on writing the Browsing section of my online book, so the stuff is fairly fresh in my mind. :) 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]
Compiler waring with heimdal-0.5.1
Hi, I installed heimdal-0.5.1 on my Linux box. When compiling Samba HEAD with gcc 3.2 I get lots of warning messages like these : In file included from include/includes.h:421, from smbd/notify.c:22: /usr/include/heimdal/gssapi.h:625: warning: declaration of `open' shadows a global declaration /usr/include/fcntl.h:70: warning: shadowed declaration is here Anybody else seen this ? ...Juergen
Re: [PATCH] file change notification
Hi,
attached is a modified version of Hal's file change notification patch.
It's against Samba HEAD and works for me.
Changes:
- use push_ucs2() to send unicode file names
- make some functions static (make proto works now)
- limit maximum number of directory entries stored in the TDB to 2000, so
large directories won't create monster TDBs.
- the maximum reply packet size is limited to 64K. I guess this should never
be a problem :-)
What ist the maximum allowed size of a NT_TRANS packet anyway ?
...Juergen
--- smbd/notify.orig 2002-12-12 03:01:53.0 +0100
+++ smbd/notify.c 2003-03-03 21:56:56.0 +0100
@@ -21,9 +21,21 @@
#include includes.h
+#define MAX_DIRENTRIES 1000
+
static struct cnotify_fns *cnotify;
/
+This structure holds a list of files and associated notification actions.
+*/
+struct file_action {
+ struct file_action *next, *prev;
+ int action;
+ char *filename;
+ int filename_length;
+};
+
+/
This is the structure to queue to implement NT change
notify. It consists of smb_size bytes stored from the
transact command (to keep the mid, tid etc around).
@@ -35,16 +47,145 @@
files_struct *fsp;
connection_struct *conn;
uint32 flags;
+ uint32 max_parameter_count;
char request_buf[smb_size];
void *change_data;
+ TDB_CONTEXT *file_data;
+ struct file_action *file_actions;
};
static struct change_notify *change_notify_list;
-/
- Setup the common parts of the return packet and send it.
-*/
-static void change_notify_reply_packet(char *inbuf, NTSTATUS error_code)
+/**
+ * Return a file action struct with the given filename and fileaction
+ *
+ **/
+static struct file_action *change_notify_get_file_action(char *filename, int fileaction)
+{
+ struct file_action *fa;
+
+ if (!(fa = (struct file_action *)malloc(sizeof(struct file_action {
+ DEBUG(0, (malloc failed!));
+ }
+ fa-action = fileaction;
+ fa-filename = strdup(filename);
+ fa-filename_length = strlen(filename);
+
+ return fa;
+}
+
+/**
+ * Check to make sure that the file in the given cnbp.file_data record
+ * still exists.
+ *
+ **/
+static int change_notify_file_data_exists(TDB_CONTEXT *tdb, TDB_DATA key, TDB_DATA data, void *status)
+{
+
+ struct file_action *fa;
+ struct change_notify *cnbp = (struct change_notify *)status;
+ char *filename;
+ char *path = ((struct change_notify *)cnbp)-fsp-fsp_name;
+ int filename_len = strlen((char *)key.dptr) + strlen((char *)path) + 2;
+ int fd;
+
+ if (!(filename = (char *)malloc(filename_len))) {
+ DEBUG(0, (malloc failed));
+ }
+
+ filename[0] = '\0';
+ safe_strcat(filename, (char *)path, filename_len);
+ safe_strcat(filename, /, filename_len);
+ safe_strcat(filename, (char *)key.dptr, filename_len);
+
+ if ((fd = open(filename, O_RDONLY)) == -1) {
+ fa = change_notify_get_file_action
+ ((char *)key.dptr, FILE_ACTION_REMOVED);
+ DLIST_ADD(cnbp-file_actions, fa);
+ } else {
+ close(fd);
+ }
+
+ return 0;
+}
+
+/**
+ * Get a list of all the file notification actions
+ *
+ **/
+static int change_notify_find_file_actions(struct change_notify *cnbp)
+{
+ void *dp;
+ char *fname;
+ TDB_DATA tdb_key, tdb_data;
+ SMB_STRUCT_STAT old_st, new_st;
+ pstring full_name;
+ size_t fullname_len, remaining_len;
+ char *p;
+ int count;
+ struct file_action *fa;
+
+ cnbp-file_actions = NULL;
+
+ if (!(dp = OpenDir(cnbp-conn, cnbp-fsp-fsp_name, True))) {
+ DEBUG(0, (Failed to open directory '%s',
+ cnbp-fsp-fsp_name));
+ }
+
+ pstrcpy(full_name, cnbp-fsp-fsp_name);
+ pstrcat(full_name, /);
+
+ fullname_len = strlen(full_name);
+ remaining_len = sizeof(full_name) - fullname_len - 1;
+ p = full_name[fullname_len];
+ count = 0;
+
+ while ((fname = ReadDirName(dp)) count MAX_DIRENTRIES) {
+ count ++;
+ if (strequal(fname, .) || strequal(fname, ..)) {
+ continue;
+ }
+
+ DEBUG(10, (check file: %s\n, fname));
+ safe_strcpy(p, fname, remaining_len);
+ vfs_stat(cnbp-conn, full_name, old_st);
+ tdb_key.dptr = (void *)fname;
+ tdb_key.dsize = strlen(fname) + 1;
+ tdb_data = tdb_fetch(cnbp-file_data, tdb_key);
+ if (!tdb_data.dptr) {
+ fa = change_notify_get_file_action
+(fname, FILE_ACTION_ADDED);
+ DLIST_ADD(cnbp-file_actions, fa);
+ continue;
+ }
+ new_st = *((SMB_STRUCT_STAT *)tdb_data.dptr);
+ free(tdb_data.dptr);
+ if ((old_st.st_atime != new_st.st_atime) ||
+ (old_st.st_mtime != new_st.st_mtime) ||
+ (old_st.st_ctime != new_st.st_ctime)) {
+ fa = change_notify_get_file_action
+(fname, FILE_ACTION_MODIFIED);
+ DLIST_ADD(cnbp-file_actions, fa);
+ }
+ }
+
+ /* check for deleted files */
+ if (tdb_traverse(cnbp-file_data,
Re: Compiler waring with heimdal-0.5.1
On Mon, Mar 03, 2003 at 10:13:03PM +0100, Juergen Hasch wrote: Hi, I installed heimdal-0.5.1 on my Linux box. When compiling Samba HEAD with gcc 3.2 I get lots of warning messages like these : In file included from include/includes.h:421, from smbd/notify.c:22: /usr/include/heimdal/gssapi.h:625: warning: declaration of `open' shadows a global declaration /usr/include/fcntl.h:70: warning: shadowed declaration is here Anybody else seen this ? This is brokenness in the Heimdal header files, not in Samba. The Heimdal developers need to compile with more warnings set in gcc. Jeremy.
Re: Compiler waring with heimdal-0.5.1
[EMAIL PROTECTED] writes: Anybody else seen this ? This is brokenness in the Heimdal header files, not in Samba. The Heimdal developers need to compile with more warnings set in gcc. What more then -Wall -Wmissing-prototypes -Wpointer-arith -Wbad-function-cast -Wmissing-declarations -Wnested-externs ? It a mistake to make it `open', it originates from RFC2744 and was copied verbose from the spec. I'll make sure it get fixed to next release of heimdal. Love
Re: Compiler waring with heimdal-0.5.1
On Mon, Mar 03, 2003 at 10:21:06PM +0100, Love wrote: [EMAIL PROTECTED] writes: Anybody else seen this ? This is brokenness in the Heimdal header files, not in Samba. The Heimdal developers need to compile with more warnings set in gcc. What more then -Wall -Wmissing-prototypes -Wpointer-arith -Wbad-function-cast -Wmissing-declarations -Wnested-externs Yep :-). Please add : -Wshadow -Wstrict-prototypes -Wcast-qual -Wcast-align -Wwrite-strings Jeremy.
Re: Compiler waring with heimdal-0.5.1
Am Montag, 3. März 2003 23:48 schrieb [EMAIL PROTECTED]: On Mon, Mar 03, 2003 at 10:21:06PM +0100, Love wrote: [EMAIL PROTECTED] writes: Anybody else seen this ? This is brokenness in the Heimdal header files, not in Samba. The Heimdal developers need to compile with more warnings set in gcc. What more then -Wall -Wmissing-prototypes -Wpointer-arith -Wbad-function-cast -Wmissing-declarations -Wnested-externs Yep :-). Please add : -Wshadow -Wstrict-prototypes -Wcast-qual -Wcast-align -Wwrite-strings Jeremy. I changed the function prototype in gssapi.h for now. Thanks. ...Juergen
unsuscribe
unsuscribe Juergen Hasch wrote: Hi, I installed heimdal-0.5.1 on my Linux box. When compiling Samba HEAD with gcc 3.2 I get lots of warning messages like these : In file included from include/includes.h:421, from smbd/notify.c:22: /usr/include/heimdal/gssapi.h:625: warning: declaration of `open' shadows a global declaration /usr/include/fcntl.h:70: warning: shadowed declaration is here Anybody else seen this ? ...Juergen
large readwrite flag
I was reading through the smb man page -- and this may be outdated, but there was a caution on this option: Note that due to Windows 2000 client redirector bugs this requires Samba to be running on a 64-bit capa ble operating system such as IRIX, Solaris or a Linux 2.4 kernel. Can improve performance by 10% with Windows 2000 clients. Defaults to off. 1) Are these bugs still present in XP? 2) If I'm not using the redirector service but the more standard mounted drive and //sys/mnt, syntax, does the caution still apply? 3) Should I assume that 2.4.20 linux on ia32 would have problems dealing with large file IO? tnx, linda
Fundemental bug in winbindd 2.2.7a?
I'm using winbindd to dump NT users and groups out to Unix, and I think I've found a rather major bug. We have a mixture of Active Directory and WinNT Domains spread world-wide over low to high (1-2Mbs) speed WAN links. If I dump a remote domains groups, the accounts within show up with the WRONG MEMBERS! e.g. if winbindd is running under the local NZ domain, and I use it via export WINBINDD_DOMAIN=US to dump group membership in a (Active Directory) domain on another site (via getent group), then I end up with corrupt entries: e.g. US+Just Me may be a Universal Group that is meant to contain NZ+jhaar, instead it contains US+other_user! In fact, all of the Universal Groups in US come through *exclusively* with corrupt US+username entries, instead of the mixture of domain accounts that are really there. Perhaps there some misinterpretation of SIDs going on in winbindd? Redhat 7.3, Samba 2.2.7a. -- Cheers Jason Haar Information Security Manager, Trimble Navigation Ltd. Phone: +64 3 9635 377 Fax: +64 3 9635 417 PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1
Re: Recovery from Domain/WINS Outage - Didn't work well
On Mon, Feb 24, 2003 at 11:04:15AM -0500, Hall, Ken (ECSS) wrote: We're still new with this, and so far Samba isn't looking too reliable to our management. This is the second time a WINS-related problem has knocked us down while the Windows servers remained available. I'm assuming we're Listen to what you just said: This is the second time a WINS-related problem... You have a Microsoft problem, and management is blaming Samba!?!?!?!? Drop WINS on M$ - start WINS on Samba. Then you only have one thing to worry about. -- Cheers Jason Haar Information Security Manager, Trimble Navigation Ltd. Phone: +64 3 9635 377 Fax: +64 3 9635 417 PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1
Re: file descriptors consumed by printing
On Sun, Mar 02, 2003 at 10:25:27PM -0800, Richard Sharpe wrote: This seems like a good way to do it. Does anyone have any objections if I do so? Why do we need it? Just call lp_default_server_announce() and check if the SV_TYPE_PRINTQ_SERVER bit is set. If no print shares are exported then don't call nt_printing_backend_init(). Hmmm, Samba 2.2.x sets SV_TYPE_PRINTQ_SERVER unconditionaly. It's fixed in HEAD. Yeah, well someone forgot their janitorial duties :-) There's an interesting story about that. (-: At the time I fixed this problem we were in don't touch the 2.2 branch unless it is a critical bug fix, and also in this will be the last version of 2.2 for sure mode. I guess we are still in both those conditions again at the moment! Here's the original problem report: http://lists.samba.org/pipermail/samba-technical/2002-May/036866.html Tim.
Re: file descriptors consumed by printing
On Tue, Mar 04, 2003 at 12:46:28PM +1100, Tim Potter wrote: There's an interesting story about that. (-: At the time I fixed this problem we were in don't touch the 2.2 branch unless it is a critical bug fix, and also in this will be the last version of 2.2 for sure mode. I guess we are still in both those conditions again at the moment! Woo hoo ! Just wait until you see my no-writable strings for 2.2 patch :-). Jeremy.
Re: [PATCH] fix: id_sid cache
At 18:03 02.03.2003 +, [EMAIL PROTECTED] wrote: On Wed, Feb 26, 2003 at 03:55:49PM +0100, Stefan (metze) Metzmacher wrote: Hi Jeremy, I have a little fix for the id_sid cache, to correct return the sidtype. Hi Stefan, Actually there isn't any point in returning the sidtype here that I can see. We're only after the uid_t or gid_t in these calls. I considered this when I re-wrote the code, but already decided it wasn't needed. Ok, but we didn't need to cache the sidtype at all in this case! And we also didn't need a sidtype parameter in this funtions at all. But if we decide to have the sidtype stuff, it have to work correct and the current code, without my little fix, is incorrect! It didn't set the *sidtype at all in the sid_to_*id() fn's! metze - Stefan metze Metzmacher [EMAIL PROTECTED]
RE: 2.0.7-XP compability ?
On Thu, 30 Jan 2003, Ulf Bertilsson wrote: Can we have a trace? Problem solved. It was an alien assign pointing to another smb.conf file.. Argh.. Still useful to debug it down. -- Ulf
