*Groups* Advanced Groups Search Preferences Groups Help *Groups search result 2* for *samba vms faq group:*vms** *CONNX for RMS* • Fast Industry Standard access to RMS data on all VMS platforms • www.connx.com Sponsored Links *VAX Replacement/Migration* • Replace your VAX with a Windows or Alpha system with no code changes! • www.stanq.com/charon-vax.html *OpenVMS Migration* • Migrate to Linux, Unix or Windows Toolkits and end-to-end services • www.Sector7.com Search Result 2 From: John E. Malmberg (wb8tyw@qsl.network ) Subject: *FAQ*: *Samba*-*VMS* Frequently Asked Questions This is the only article in this thread View: Original Format Newsgroups: comp.os.*vms* Date: 2002-01-14 20:58:38 PST The *SAMBA*-*VMS* Frequently Asked Questions List - 14-Jan-2002 Index Introduction General questions about *SAMBA* on OpenVMS Printing Issues Miscellaneous Future directions Building *Samba* Changes since last edition INTRO8. Are you having problems Unzipping *SAMBA*? INTRO9. What *SAMBA* versions are known to be available for OpenVMS? BUGS1. What are known bugs? SAMBA9. What can be done to speed *SAMBA* up? SAMBA10. Running TESTPARM gives: WARNING: lock directory ... SAMBA14. Can I use *SAMBA* to backup my OpenVMS hard drive? SAMBA15. If I disable encrypted passwords, isn't that a security risk? SAMBA16. The SMBD program started running and then quit. Why? SAMBA17. I can not connect to *SAMBA* server from Windows NT. SAMBA18. I have *SAMBA* 2.0.3 and I can not seem to get SMBPASSWD to work. SAMBA19. I upgraded from *SAMBA* 2.0.3 to *SAMBA* 2.0.6 and the SMBD server will not start. SAMBA20. Some filenames will not display. SAMBA21. Physical device name do not work in *SAMBA* 2.0.6? SAMBA22. *SAMBA* will not start and I am running Compaq TCP/IP 5.1. SAMBA23. How many connections can I run for *SAMBA*? SAMBA24. NMBD on *SAMBA* 2.0.3 crashes with an Access Violation. SAMBA25. NMBD on *SAMBA* 2.0.6 hangs when there is a broken lanman ... SAMBA26. I am seeing an error: Failed to set socket option TCP_NODELAY PROGRAMMING1 - 5. Miscelaneous programming information. This is the Frequently Asked Questions (*FAQ*) posting for *SAMBA*-*VMS*. It contains answers to frequently asked questions about *SAMBA* for OpenVMS on the *SAMBA*-*VMS* mailing list, and a few other places. Other internet FAQs are generally available in these locations: comp.answers and news.answers newsgroups ftp://rtfm.mit.edu/pub/usenet/... This *FAQ* is archived in the following locations: Please do NOT send technical questions to the Frequently Asked Questions (*FAQ*) editor - well, please do not email any questions that do not also include the answer(s). Please post these questions to the appropriate *SAMBA*-*VMS* mailing list instead and see INTRO5 before posting. To make suggestions for changes or additions to this *FAQ* list, please send mail to the *FAQ* editor at wb8tyw@qsl.net. Again, Please do not assume *FAQ* editor is in a position to answer general questions. Although the editor of this *FAQ* is an employee of Compaq Computer Corporation, this posting is not an official statement of Compaq. If someone else wants to start maintaining this *FAQ*, feel free to start issuing updates. Some general notes: World-Wide Web Universal Resource Locator (URL) notation is used for FTP addresses. Many people have contributed to this list, directly or indirectly. Many people have contributed to this list, directly or indirectly. In some cases, an answer has been adapted from one or more postings on the *SAMBA*-*VMS* mailing list or comp.os.*vms*. Our thanks to all of those who post answers. The name (or names) at the end of an entry indicate that the information was taken from postings by those individuals; the text may have been edited for this *FAQ*. These citations are only given to acknowledge the contribution. This contents of this *FAQ* are not to be considered an official position of any companies whose employees have contributed. These answers are provided in the hope that they will be of use, but there are no guarantees of accuracy. Please also note that the current compiler of this *FAQ* has only really used *SAMBA* 2.0.6 for OpenVMS. All trademarks mentioned belong to their holders. DECUS, Pathworks, *VMS* and OpenVMS are trademarks of Compaq. Microsoft Windows, and Microsoft Windows NT are trademarks of Microsoft. UNIX is a trademark of "The Open Group". INTRO1. What is *SAMBA*? *SAMBA* is an open source suite of programs for communicating over the Microsoft NETBIOS protocols on TCP/IP. It was developed originally by Andrew Tridgell who is still active in guiding *SAMBA's* evolution. For more information about *SAMBA*, see HTTP://WWW.*SAMBA*.ORG Licensing for *SAMBA* is covered under the GNU Public License. The *SAMBA*-*VMS* home page is currently at: http://www.ifn.ing.tu-bs.de/ifn/sonst/*samba*-*vms*.html It is maintained by Eckart Meyer, who is responsible for the majority of the *SAMBA*-*VMS* port. With out the hard work of Eckart Meyer, there probably would not be a *SAMBA*-*VMS* port. A port of *SAMBA* 2.0.6 is available on the OpenVMS Freeware CD-ROM. It's location is: http://www.openvms.compaq.com/freeware/FREEWARE50/*SAMBA*/ It requires a helper library: http://www.openvms.compaq.com/freeware/FREEWARE50/FRONTPORT/ INTRO2. What is *VMS* or OpenVMS? OpenVMS is an Computer Operating System sold by Compaq that is considered by many to be a superior operating environment. The OpenVMS operating system has a reputation for reliability and security. System uptimes can be measured in years. It is also well known as an cracker resistant system. A no-charge Hobby license for OpenVMS is available for non-commercial home use. For more information on OpenVMS, see http://www.openvms.compaq.com For more information on the Free Hobby license for OpenVMS see http://www.montagar.com/Hobbyist/ INTRO3. What is the scope of the *SAMBA*-*VMS* mailing list? The *samba*-*vms* mailing list is the primary news group for OpenVMS specific issues for *SAMBA*. INTRO4. What other resources have *SAMBA*-*VMS* related information? *SAMBA* for OpenVMS questions may show up in any of the OpenVMS forums, Usually the comp.os.*vms* newsgroup. ENCOMPASSERVE is a useful moderated forum that covers a variety of computer related systems including *SAMBA* for *VMS*. It is run by volunteers from the ENCOMPASS U.S. organization. For information about ENCOMPASS see http://www.encompassus.org. For information about ENCOMPASSERVE see http://www.encompasserve.org *SAMBA* can be used as a client on a system with a Pathworks server. Information on Pathworks, now known as Advanced Server for OpenVMS can be found at http://www.openvms.compaq.com/pathworks. There is also a commercially supported SMB Client package from Vector Networks called LanUtil32. Information on it can be found by following the "related links" from the pathworks URL above. INTRO5. How do I subscribe to the *SAMBA*-*VMS* mailing list? Before answering that, you should be aware of guidelines on posting. 1. Please choose a subject title that accurately describes your posting. 2. Please list the version of OpenVMS, *SAMBA*, and the name and version of the TCP/IP product that you are using. Also mention any ECO or patches applied. The exact name of the ZIP files used for the install may also be helpful. 3. Mailing lists are generally plain text only. No HTML or Rich Text formats please. Also please turn off VCF cards. Does it have to be mentioned that graphics as signature files are also bad? 4. Please try to avoid attachments. If you must place an attachment, if it can be read using a text editor, make sure that the name of the extension is .TXT to prevent problems with some virus scanners. 5. When replying to a post, verify the subject header, and edit away any part of the message that is not needed to supply context for the reply. Also before posting, it is generally a good practice to check the archives of the mailing list and the *FAQ* to see if the question has been answered already. See INTRO6 for information about accessing the archives of the *SAMBA*-*VMS* mailing list. To subscribe to a list e-mail listproc@*samba*.org with "subscribe listname Your Full Name" in the message body. For additional information see http://lists.*samba*.org/ . INTRO6. How do I access the archives of the *SAMBA*-*VMS* mailing list? Go to http://www.*samba*.org then selecting a mirror site. After which selecting the link to "archives" would give you a page where you could access the mailing list archives. For now, some of the mailing list archives can be found at http://*samba*.cadcamlabs.org/lists/ INTRO7. What versions of OpenVMS and TCPIP programs will *SAMBA*-*VMS* work with? OpenVMS versions from 5.5-2 and later are known to work. For *VMS* versions before 5.5-2 some versions of *SAMBA* require the AACRTL060 kit, which is a component of the DEC C compiler. *SAMBA* 2.0.6 and FRONTPORT currently require at least OpenVMS 7.0. FRONTPORT is missing the file fake_fcntl.obj_axp, which prevents it from installing on an OpenVMS ALPHA 7.1 or earlier system, unless you have a C compiler. *SAMBA*-*VMS* will work with any of the commercial TCP-IP programs that support UCX emulation. The Compaq TCP/IP products are known as either UCX or TCPIP Services for OpenVMS. For non-commercial use they are available under the OpenVMS hobbyist program. The Process Software company has MultiNet and TCPware products available for commercial and are also available under the OpenVMS hobbyist program. There is an experimental port of *SAMBA*-*VMS* using the OpenCMU-IP TCP/IP program that can be found at ftp://ftp.qsl.net/pub/wb8tyw/ . It is not supported and there are no plans to enhance it further. If you intend on using it, read the notes supplied carefully. To recompile FRONTPORT on OpenVMS 7.3, the file grp.h in the [frontport]directory should be renamed. INTRO8. Are you having problems Unzipping *SAMBA*? ZIP archives containing OpenVMS binary file formats (anything other than plain text) must be unzipped on OpenVMS. *SAMBA* 2.0.6 on ALPHA must be UNZIPPED on a current copy of UNZIP. You can find it from the latest OpenVMS freeware CD-ROM. It is strongly recommended that only the UNZIP utility running on OpenVMS is used to decompress the files. INTRO9. What *SAMBA* versions are known to be available for OpenVMS? *SAMBA* 1.9.17p4 I suppose that this would count as the only one that is not in a "beta" test. It requires clients to only use plain-text passwords. No OPLOCKS support for file sharing. *SAMBA* 2.0.3 Beta This is a newer version of the code, and may have some bug fixes and protocl enhancements. The filename conversions for ODS-2 were changed from *SAMBA* 1.9.17p4 and support for encoding case sensitivity in the file names. It may or may not work with ODS-5. The code was reorganized, but the restrictions of *SAMBA* 1.9.17p4 are still maintained. *SAMBA* 2.0.6 Beta This is the latest known to exist. It is running the *SAMBA* UNIX source almost completely unmodified. It has implemented Oplocks and Encrypted Passwords. The SMBD program can be run interactively for debugging, and the log file can be redirected to SYS$OUTPUT:. It is basically feature and bug compatable with the UNIX version. BUGS1. What are known bugs? These may be also covered in later sections. Windows 2000 and later may have problems with *SAMBA* for OpenVMS. These problems may be intermittant and not seen at all sites. A buffer overrun bug was found in NMBD 2.0.6 that may affect earlier versions of *SAMBA*, if their TCPIP program does not report the interfaces back to their program, and you must code the interface address into the smb.conf file. This bug does not affect *SAMBA* 2.0.6. There is a known bug in the OpenVMS C RTL with ftruncate() function that may be should be fixed in an ECO for 7.2-1. This will cause the SMBD process to go CPU bound when copying a file. This bug does not affect 2.0.6. There is a known bug in the OpenVMS C RTL 7.2 and the Compaq TCPIP 5.0, and possibly the third party TCPIP programs that can cause the NMBD program to go comatose and enter a RWAST state when a stop of the process is attempted. This is addressed in an ECO kit for the OpenVMS runtime library. I have only reproduced this problem on a network with a Windows NT workstation that had a malfunctioning browser process. SAMBA1. I get an error telling me I have no chroot. You do not have one :-) This is simply an informational warning and can be ignored. In a future build for OpenVMS chroot() can be aliased to invoke chdir() for OpenVMS, so that this message will not appear. Note that "The Single Unix Standard" published by "The Open Group" lists the chroot() function as depreciated. SAMBA2. I appear to have a trapdoor gid system. OpenVMS does not support setgid(). There is no way to support it. This is simply an informational warning and can be ignored. In a future build for OpenVMS, the setgid() call can be aliased to a local copy that just remembers the group that was attempted to be set, and the getgid() call alias to return that group. This will eliminate that diagnostic. SAMBA3. Why are some files with double underscores not displayed? The issue with the double underscore has to do with how *Samba **VMS* and Pathworks encode filespecs with characters that are not legal OpenVMS characters on an ODS-2 file system. Characters that were not legal were encoded with a "__" followed by the Hexadecimal code for the character. As part of this, under older versions of Pathworks, when you saved a file from a LANMAN client that had two underscores in it's name, the file on OpenVMS would end up with "_5F_" in it's place. [This treatment of double underscores does not seem to be the case with Pathworks 6.0 and later.] The problem with displaying them is that when *SAMBA*-*VMS* looks up the file and converts/decodes it to a UNIX style name, if the double underscore is not followed by a valid pair of hex digits, it is passed through. Now what *SAMBA*-*VMS* does is read in the filename and convert it to UNIX so that the UNIX based code can manipulate the file specification. Later *SAMBA* tests the filename with a stat() command multiple times after that. For *VMS* that requires converting it back. When the conversion routines sees the double underscore it converts it to "_5F_". In the case where the original file is "__" this results in a file not found error. *SAMBA* then ignores the file. With ODS-2 naming limitations, when file names are converted by adding characters, it is not possible that the conversion will always work both ways. Another filename that is invisible to *SAMBA* is the *VMS* specification ".;". It is also invisible to Pathworks. SAMBA4. What is ODS-1, ODS2, and ODS-5? ODS-1 is the name of the file system that is used on the RSX-11 family of operating systems. OpenVMS/VAX can use this filesystem. IIRC: It is limited to one level of directories, and filenames are limited to 8 or 9 characters followed by a period and another 3 characters. ODS-2 is the name that *VMS* gives to the filesystem that is native to it. Under it filenames are limited to 39 characters followed by a period, and then another 39 characters. For versions of *VMS* prior to 7.2 there can be 8 levels of a primary directory. In addition 7 levels of rooted directories can also be specified, or concealed under a logical name. For OpenVMS version 7.2 and later, there can be 255 levels of directories. A complete ODS-2 file specification can not be greater than 255 characters. ODS-3 and ODS-4 are CD-ROM filesystems according to the "Ask The Wizard" link at http://www.openvms.compaq.com . ODS-5 is new filesystem available for OpenVMS ALPHA version 7.2 and later. It allows longer file specifications and a larger character set. [I have not tested any version of *SAMBA* on an ODS-5 filesystem, so I do not know how it will behave.] SAMBA5. Did *SAMBA*-*VMS* crash my system? Probably not. *SAMBA* runs mostly in user mode code, and user mode code can not cause a system crash. There is one portion of *SAMBA* that currently runs in KERNEL mode, and that is when the computer changes the effective username. While an error in that section of code can cause a crash, it has been in use at quite a few sites for quite a while. SAMBA6. *SAMBA* stopped working after an OpenVMS upgrade, why? The component of *SAMBA* that allows the SMBD to change it's username while it is running needs to be linked against the system image. See the instructions for setting up *SAMBA* and re-link. For *SAMBA* 2.0.6, that code is in the FRONTPORT image installation, and should automatically relink after an OpenVMS upgrade if it is needed. SAMBA7. Why can clients not connect to my *SAMBA* server? (Take 1) For *Samba*-*VMS* versions 2.0.3 or earlier the SMBD server requires clients to be able to connect with plain-text passwords. By default this is disabled for most LANMAN clients. Registry scripts to enable plain text passwords are available as part of the main *SAMBA* distribution if they are not present in the *SAMBA*-*VMS* distribution. *SAMBA* 2.0.6 for OpenVMS can use encrypted passwords. The passwords must be set using the SMBPASSWD program. Unfortunately the SMBDPASSWD program for 2.0.6 must be run from the SYSTEM account. SAMBA8. What about Windows 2000 and *SAMBA*-*VMS*? There are some fixes in the *SAMBA* 2.0.7 release that addresses problems with Windows 2000 and *SAMBA*. SAMBA9. What can be done to speed *SAMBA* up? Some general suggestions: For COMPAQ TCP/IP or UCX, set the TCP protocol not to delay acknowledgements. The command is: $ UCX SET PROTOCOL TCP /NODELAY_ACK You can try the DCL command SET RMS_DEFAULT/BUFFER_COUNT=N where N can be from 1 to 255. This can also be set with a SYSGEN parameter in MODPARAMS.DAT. ex: MIN_RMS_DFMBFSDK = 2 ! Sequential Disk file buffers Many tuning problems will show up as CPU bound. Do on all your disks, $SHOW DEVICE/FILES/NOSYS Dnnn: Every time that you find the same executable file more than once, that file should be installed as a shared image with the header resident. This will get you a lot of physical and virtual memory back. You may need to increase global pages and global sections to accommodate this. If you even suspect that an executable may be run in more than one instance, it should be installed. The second activation of most executables that are not installed is costly. This will also speed up the launch of your SMBD processes. Avoid all unneeded paging. For this examine the peak virtual memory used by each process. Adjust the quota for working set extent to match the value seen. Over allocating WSEXTENT will not hurt you unless you are very severely memory limited. The SYSGEN parameter WSMAX may need to be increased for your system. Set it as high as AUTOGEN will allow with out complaining about hurting working set expansion. This may cause more processes to swap out when idle. If this impacts performance negatively, then you likely need more memory for your workload. Of course the step above of liberally installing images will help there. Your NPAGEDYN pool should be set so that there is 300,000 blocks free with out any pool expansion while you are running under your full normal load. This is contrary to what AUTOGEN will calculate, but is part of the documentation for the DECWindows-Motif and TCP/IP products. If you are running OpenVMS 5.5-2 and earlier, make sure that you have 1/3 free of the IRP, LRP, and SRP allocations, with out pool expansions. For *SAMBA* 2.0.6 turnning off OPLOCKs may help. The Windows Explorer shell uses the file extension to determine what type of file it is. If the extension is one that Explorer knows that might contain an icon, when displaying the directory, it will search these files for an icon to display. There is a lot of oplock activity as a result of this. The locking implemented in *SAMBA* for OpenVMS is the LOCKING-SLOW method. It needs to be converted to use SYS$ENQW/SYS$ENQW but that's a future programming task. An untried suggestion from the *SAMBA*-TECHNICAL list: Reduce the number of maximum open files permitted in smb.conf. max open file = 600. SAMBA10. Running TESTPARM gives: WARNING: lock directory /samba_root/var/locks should have permissions 0755 for browsing to work Yes TESTPARM does this. I have not found out exactly why yet, but you can safely ignore the message. SAMBA11. SMBD takes a long time to transfer a file, and high CPU utilization is observed. One cause of this has been traced to a bug in the DEC C ftruncate() function that has been confirmed by the Compaq Customer Support Center. Versions of OpenVMS known to be affected are OpenVMS 7.2 and 7.2-1. The best workaround is to recompile *SAMBA* with out HAVE_FTRUNCATE_EXTEND defined. Since the FRONTPORT library has been coded to avoid the bug, I have not tracked to see if it has been fixed. I have only seen this problem personally on ALPHA so I do not know if it affects the VAX version. SAMBA12. *Samba* is not starting after a reboot? You must make sure that SAMBA_STARTUP.COM is executed after the TCPIP$STARTUP.COM or equivalent. Also for TCPIP or (Substitute UCX if needed) make sure that the last statement in the SAMBA_STARTUP.COM has the line: $TCPIP ENABLE SERVICE SMBD It appears to be needed because some of the logical names used in the service definition are not defined at the time the TCPIP$STARTUP is run. [from a post by Jeff Campbell] It appears that the INSTALL.COM routine supplied by *SAMBA* 1.9.x-VMSn is needed to be run to set up logical names that are needed. It may be needed to be run before the TCPIP program is started. [from a post by Zane H. Healy] SAMBA13. Any issues with *SAMBA* in a *VMS* Cluster? It has been reported that *SAMBA* works fine in a cluster when using common files. Load sharing is a function of using TCPIP aliases and a DNS that supports it. [From a post by Gus Bingham] SAMBA14. Can I use *SAMBA* to backup my OpenVMS hard drive? Not real well. When you transfer a file by any method from an OpenVMS system to a different system, the file attributes will be lost. OpenVMS has many files attributes and internal formats that will not translate to other systems. Only files of an OpenVMS stream or fixed format likely will be usable when transferred back. If you use the ZIP program on OpenVMS to encapsulate the files before transfering them using the OPTIION to save the attributes, and then store the ZIP file, it is possible to restore the files later by using the UNZIP utility on OpenVMS. See the OpenVMS *FAQ* for more details on ZIP and UNZIP. SAMBA15. If I disable encrypted passwords, isn't that a security risk? Yes. But you must consider how much of a risk. It takes someone that has a direct tap on the network to take advantage of it. They also must have either a program to capture the passwords, or a LAN monitoring program. But basically the only additional risk is that the malicious person will gain passwords that can be used to attack other services like TELNET and FTP. But anyone with access to your network, and the skill level to extract passwords from a LAN can already compromise your network in other ways. Encrypted passwords do not greatly improve local network security for most civilian computer networks. If you have that level of concern, than you need more professional help than can be provided here in a free *FAQ*. SAMBA16. The SMBD program started running and then quit. Why? For current known releases of *SAMBA* for OpenVMS, the SMBD processes are started up from the TCP/IP dispatcher (Unix equivalent is INETD). After a period of inactivity with no connection, the SMBD process will terminate. There is one SMBD process for each connection. The NMBD program runs as a detached process. It will always be running. When a browse request comes into the NMBD process, it may cause a SMBD process to start up as they exchange information. In the future, the NMBD program may also be launched from the TCP/IP dispatcher. SAMBA17. I can not connect to *SAMBA* server from Windows NT. Windows NT and Windows 2000 require that the *SAMBA* GUEST *VMS* account exist, and must have permission to write into it's default directory. Of course this means that the default directory must exist. Windows 95, and SMBCLIENT do not have this requirement. SAMBA18. I have *SAMBA* 2.0.3 and I can not seem to get SMBPASSWD to work. It is documented in the notes supplied with *SAMBA* 2.0.3 for OpenVMS that encrypted passwords do not work. And this means that there is no point in using the SMBPASSWD utility. SAMBA19. I upgraded from *SAMBA* 2.0.3 to *SAMBA* 2.0.6, and the SMBD server will not start. The error messages are: "unable ot read file SAMBA_ROOT/VAR/PRIVATE/MACHINE.SID. Error was can't assign requested address" "ERROR: *Samba* cannot create a SAM SID" The old SAMBA_ROOT:[VAR.PRIVATE]MACHINE.SID file is not compatable with the new release. Delete the file. *SAMBA* 2.0.6 will recreate it in the new format. SAMBA20. Some filenames will not display. The name mangling algorithms in the various *SAMBA* releases are not perfect. Some names can not be tranlated bidirectionaly. Some versions of *SAMBA* may have an issue with files created by other versions. Particularly files with multiple dots. Earlier versions split the file from the extension at the first dot, later versions split the file at the second dot. This tracks a change in Pathworks behavior over the same period, but Pathworks still could read properly files in the older format. *SAMBA* 2.0.6 should also be able to handle files in the old format, but will create files in the new format. With *SAMBA* 2.0.6, all filename handling is done in the FRONTPORT library. It has been reported that *SAMBA* 2.0.6 has some problems with some of the characters that are eight bits in size. [That is considered a bug] The name translating part of *SAMBA* on OpenVMS has continued to be a source of pain. To do it right incurs a high CPU or disk access, because *SAMBA* is looking up the UNIX version of the filename several times. I have received a report where *SAMBA* 2.0.6 is not handling filenames with physical device names, but will handle Concealed Rooted logical names. [That is also considered a bug of course] Earlier versions of *SAMBA* for OpenVMS have problems with concealed logical names. SAMBA21. Physical device names do not work in *SAMBA* 2.0.6? They should work. But I have one report that they did not, but concealed logical names did work. I always recommend using logical names instead of physical name, as properly used it reduces system maintenance. SAMBA22. *SAMBA* will not start and I am running Compaq TCP/IP 5.1. This only affects new installations. The error message in the smb.log file will be: FAULT.C "INTERNAL ERROR: Signal 10 in PID 160 Please read the file BUGS.txt in the distribution." UTIL.C "PANIC: internal error." In the operator.log the following message will appear: "INTERnet ACP NOLISTEN Process creation success: Service - SMBD" "INTERnet ACP Activate SMBD Server" The key is the Operator.log message, the SMBD process should be a "LISTEN" service. The SMBD_STARTUP.LOG contains: "Client_fd = -1" This should be a positive number, usually 3. and a stack dump: "%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=xxxxx" SMBD PROCESS receive_message_or_smb SMBD PROCESS smbd_process SMBD SERVER smbd_main" The following fix needs to be added to the SMBD_SETUP_TCPIP.COM and possibly the SMBD_SETUP_TCPIP.COM $ tcpip set service smbd - /protocol=TCP - /port=139 - /flags=listen - ! This is the change <<<<< /user=SYSTEM - /process=SMBD - /file=SAMBA_ROOT:[BIN]SMBD_STARTUP.COM - /log=(FILE:SAMBA_ROOT:[VAR]SMBD_STARTUP.LOG,ALL) - /limit=100 SAMBA23. How many connections can I run for *SAMBA*? The limit of 100 seems to be arbitrarily coded into the command file that sets up the service for Compaq TCP/IP and UCX. Change it if you need more sessions. SAMBA24. NMBD on *SAMBA* 2.0.3 crashes with an Access Violation? A bug was found when *SAMBA* 2.0.6 was being tested where NMBD could do this. I suspect that is the cause of the reported crashes in *SAMBA* 2.0.6. This bug is dependent on what TCP/IP program you are running and is present in the UNIX sources up to 2.2.x. If you use the older NMBD, or upgrade your TCP/IP stack, or upgrade your NMBD to 2.0.6, any of these will fix the problem. SAMBA25. NMBD on *SAMBA* 2.0.6 hangs when there is a broken lanman browser on the network? Get the latest Compaq C runtime library ECO and TCP/IP ECO to fix. In the mean time disable the browser service that is defective. SAMBA26. I am seeing an error: Failed to set socket option TCP_NODELAY (Error protocol not available ) In 2.0.6, I was testing the different socket options, and missed removing that one from the SMB.CONF before I made the template. It can be ignored. PRINTING1. Printing is not working? (take1) Printing does need write access to a spool area. Make sure that the logical name TMP is defined at the process level to be SAMBA_ROOT:[VAR], and not SYS$SCRATCH. Printing takes place in a setuid() section, and the logical names in the GROUP and JOB tables are not visible to the code. So SYS$SCRATCH is not defined. PRINTING2. SMBRUN ERROR: Can't find smbrun. Installation problem? "Running the command '' gave 1" The actual string value for SMBRUN that it is looking for can be specified in a header file, and then superceded in smb.conf. The 2.0.3 version of *SAMBA* uses the string SMBRUN as a default if nothing is specified in smb.conf file. It is also noted that the 2.0.3 version of *SAMBA*-*VMS* may require the following line in smb.conf: smbrun = /samba_root/bin/smbrun.com You do not want to put a path in the smb.conf file, you want specify a single name. That name must exist both as a logical name that points to the command file and as a DCL symbol that defines a foreign command. The default installation of *SAMBA*-*VMS* should configure both of these for you. If the logical name is missing, the error message above will probably be generated. If the symbol is missing, the printing will not work, and other messages may or may not be generated. PRINTING3. Why does the job number displayed from *SAMBA* not match the one displayed by OpenVMS? The job number for a print job in OpenVMS is an UNSIGNED 32 BIT LONGWORD, and can be any valid value for it. It does not necessarily always increment in a predictable order. (Just usually does). The LANMAN protocol only allows 16 bits of this job number to be sent, and the UNIX *SAMBA* code uses the upper 8 bits to contain an SMBD Server instance specific number that maps to the print queue. It is not possible to 100% predict what that number is. This leaves only 8 bits, for the print job number. The number returned from OpenVMS or passed to the command files for being processed is only the lower 8 bits, if your *VMS* print job number is greater than 255. It also means that the job number viewed from a LANMAN client will not match the local *VMS* value. In a version beyond 2.0.7, the main *samba* team is re-writing this code, and I have not seen how this will affect OpenVMS yet. MISC1. Can I run a *VMS* program by double clicking on it from a Microsoft Windows shell? Take a look at http://www.danbbs.dk/~degnbol/software/rse-0.21.zip. It is a Microsoft Windows shell extension, starting X11 programs on *SAMBA* shares when they are double-clicked. It does not use magic scripts, but rsh or rlogin. [Gunnar] [I have no idea if this will work with *SAMBA*-*VMS* - John] MISC2. How can I use *SAMBA* to access files on my home PC over the Internet? If you want to access LANMAN or SMB protocols over the internet, then you must either use a Virtual Private Network tunnelling product or build *SAMBA* with the OpenSSL option. AFAIK, the OpenSSL option for the LANMAN protocols is only available between *SAMBA* systems. Presently I am not aware of any version of *SAMBA* for OpenVMS that is built with the SSL option. LANMAN traffic of any kind should never be sent over the Internet. There are documented security issues on this. Also be aware of the following: Do not ever allow your Cable Modem or DSL line to see any ethernet traffic that you do not want it to send out to outside network. This means put a router or firewall, or other device between your ISP ethernet connection and any internal LAN that you have. Do not ever rely the Internet Service Provider's equipment to do the filtering for you. Be a good network user and keep your internal broadcast type ethernet packets off of the external network. Do not put a dumb hub on a Cable Modem or other ethernet Internet connection. It is bad for you and for everyone else on your cable segment. MISC3. What is the issue with text files being mangled? UNIX text files are delimited by line-feeds, and text files on Microsoft platforms can be delimited in many different ways. There is no practical way for *SAMBA* to tell if a file being accessed or created is a text file that should be converted or a binary file that should not. This is an issue that no platform *SAMBA* runs on gets right 100% of time. If you are running *SAMBA* 2.0.6 release, the information on how to get *SAMBA* to automagically attempt to set your files to STREAM-CRLF is in samba_root:[docs]readme_vms_2_0_6_vms_0.txt [As documented this currently does not work well for large files from Microsoft clients. It does not seem to have a problem with *SAMBA* to *SAMBA* transfers.] You may have some luck with the SET FILE/attr=(rfm:stmcr) DCL command. MISC4. How can I synchronize OpenVMS and *SAMBA* passwords? No directly supported way exists. However Jeff Morgan says he has a OSU webserver script to do so for Pathworks that might be abled to be modified. http://www.geocities.com/vmswiz/*vms*.html FUTURE1. Is there a SWAT implementation for *SAMBA*-*VMS*? Maybe. The 2.0.6 port SWAT routine compiles and links cleanly. However no testing and debugging has been done. FUTURE2. Files get mangled by NOTEPAD and some other programs. This seems to be caused by problems in the ftruncate() or lack there of in OpenVMS. I am looking at various potential fixes for this and other related problems. FUTURE3. Directories with over 10,000 files are not fully displayed. This seems to be a limitation in *SAMBA*-*VMS* where it can not do the required processing in time. It may be a while for this to be addressed. PROGRAMMING1. I am assuming that those who venture here have experience with programming and some UNIX utility experience. Please see the archives of the *Samba* Technical mailing list for the most current information. PROGRAMMING2. If you discover a bugfix or enhancement for the UNIX portion of *SAMBA*, they would like the differences in the GNU DIFF "-u" format. GNU DIFF is on the OpenVMS Freeware 5.0 CD-ROM set. You should obtain the current CVS sources for the UNIX *SAMBA* to apply the diff to. These can be obtained from the *SAMBA* Mirror. Mail this to *SAMBA*-PATCHES@*SAMBA*.ORG with a very good explaination as to why the patch is needed. And make it clear where you got the sources from. The *SAMBA* team is maintaining several development streams. Additional Web Resources: Mike Rylander has set up an archive of the CVS tarballs that he tries to keep current. It can be accessed at: http://home.incanta.net/~miker/ PROGRAMMING4. *Samba* Documentation uses DOCBOOK. Http://docbook2x.sourceforge.net/ DOXYGEN documentation information. http://*samba*.org/~mbp/*samba*-dox/ http://*samba*.org/~mbp/*samba*-dox/group__file.html *Samba* Build Farm. http://build.*samba*.org Common Unix Printing System (CUPS) http://www.cups.org RSYNC - an open source utility that provides fast incremental file transfer. http://rsync.*samba*.org/ PROGRAMMING5. Red Hat Package Module sources: ftp://ftp.rpm.org/dist/rpm-4.0.x/ ------------------------------------------------------------------------ Google Home - Advertise with Us - Business Solutions - Services & Tools - Jobs, Press, & Help ©2003 Google