Sirs: I have a Ubuntu 6.06 samba 3.0.22 file server running on linux. I am attempting to update the file server to ubuntu 8.10, samba 3.2.3. I have been attempting this, intermittently, for some time which is why 8.10. I have 10 MSDOS (mostly 6.22) workstations as a part of the network. The ones that have to run, control production machinery on the plant floor. Updating the operating system on those machines is effectivly impossible. There are some of them that run software that I control, most of them use vendor supplied software to control the older machines. They are using lanman 2.2 as the client software. (I have many xp workstations, they work fine with both systems. I can map drives, read and save and run the same dos exe files that the dos stations are failing on. Print stuff...) On the old server, the dos stations can log in and use network resources. Thus far, I have failed to make them work on the new server. The relevant parts of the smb.conf files for the servers are -- The 3.0.22 server. This one is the production server and the dos stations work. # Samba config file created using SWAT # from 10.23.0.118 (10.23.0.118) # Date: 2010/01/29 09:46:06 [global] workgroup = ATRIUM-DW server string = Samba passwd program = /usr/bin/passwd %u unix password sync = Yes change notify timeout = 30 deadtime = 30 printcap name = CUPS disable spoolss = Yes show add printer wizard = No ldap ssl = no case sensitive = No [bestbilt] comment = Mapped as U: path = /atrium/bestbilt valid users = @users force group = users read only = No create mask = 0664 force create mode = 0664 directory mask = 0775 force directory mode = 0775 oplocks = No level2 oplocks = No strict locking = No *************************************************************** The 3.2.3 server # Samba config file created using SWAT # from UNKNOWN () # Date: 2010/02/02 13:20:51 [global] workgroup = ATRIUM-DW guest account = bbijimhur lanman auth = Yes ldap ssl = no [bestbilt] comment = working production data path = /atrium/bestbilt username = bbijimhur valid users = @users force group = users read only = No guest ok = Yes [dosbbilt] comment = win94 for dos workstations path = /atrium/bestbilt read only = No guest ok = Yes This smb.conf file is the best one I have been able to create for the dos stations. With it, I can log in and map the drive. net use u: \\bbi-sam-2-srv\bestbilt I can do directory listings and change directory to u:\win94 When I attempt to run a dos program (tracking.exe) I get the following u:\win94\> Tracking NET805: NETWORK DEVICE NO LONGER EXISTS READING DRIVE U Abort, Retry, Fail? f Access denied. I have much the same error if I put the executable on the local drive and attempt to use shared .dbf data files from the server. I can connect to the old server with the same box. It takes a few minutes to change all the config files for lanman, but it works. On the old server, I can login, map the drives and run executables and use the dbf data files. It seems to me as if there is some configuration flag where the default has from 3.0 to 3.2 that I can't find. I did a detailed view of both config files from swat and ran a dif on them. I was unable to identify a place that could be changed that would allow the dos machines to utilize the samba file server. I am willing to use either different client software on the dos stations, or update the samba setup to a different version. I like ubuntu, but am not wedded to it. However, the dos stations must stay, even if I must maintain a server with 3.0 on it to keep them running. Any ideas? I am more that willing to RTFM, but have exausted my ideas of which FM and which part of it to read. Hints in this matter would be welcome. Hints on which config option in smb.conf would be even more welcome. Thanks in advance, Jim Hurlburt Atrium Windows and Doors Northwest. Yakima, WA USA
Günter Kukkukk
2010-Feb-03 02:52 UTC
[Samba] (no subject) - DOS apps are failing on recent samba version
Am Dienstag 02 Februar 2010 23:56:06 schrieb James Hurlburt:> Sirs: > > I have a Ubuntu 6.06 samba 3.0.22 file server running on linux. > I am attempting to update the file server to ubuntu 8.10, samba 3.2.3. > I have been attempting this, intermittently, for some time which is why > 8.10. > > > I have 10 MSDOS (mostly 6.22) workstations as a part of the network. > The ones that have to run, control production machinery on the plant floor. > Updating the operating system on those machines is effectivly impossible. > There are some of them that run software that I control, most of them > use vendor supplied software to control the older machines. > > They are using lanman 2.2 as the client software. > (I have many xp workstations, they work fine with both systems. > I can map drives, read and save and run the same dos exe files that the > dos stations are failing on. Print stuff...) > > On the old server, the dos stations can log in and use network resources. > Thus far, I have failed to make them work on the new server. > > The relevant parts of the smb.conf files for the servers are -- > > The 3.0.22 server. This one is the production server and the dos stations > work. > > # Samba config file created using SWAT > # from 10.23.0.118 (10.23.0.118) > # Date: 2010/01/29 09:46:06 > > [global] > workgroup = ATRIUM-DW > server string = Samba > passwd program = /usr/bin/passwd %u > unix password sync = Yes > change notify timeout = 30 > deadtime = 30 > printcap name = CUPS > disable spoolss = Yes > show add printer wizard = No > ldap ssl = no > case sensitive = No > > [bestbilt] > comment = Mapped as U: > path = /atrium/bestbilt > valid users = @users > force group = users > read only = No > create mask = 0664 > force create mode = 0664 > directory mask = 0775 > force directory mode = 0775 > oplocks = No > level2 oplocks = No > strict locking = No > > *************************************************************** > > The 3.2.3 server > > # Samba config file created using SWAT > # from UNKNOWN () > # Date: 2010/02/02 13:20:51 > > [global] > workgroup = ATRIUM-DW > guest account = bbijimhur > lanman auth = Yes > ldap ssl = no > > [bestbilt] > comment = working production data > path = /atrium/bestbilt > username = bbijimhur > valid users = @users > force group = users > read only = No > guest ok = Yes > > [dosbbilt] > comment = win94 for dos workstations > path = /atrium/bestbilt > read only = No > guest ok = Yes > > This smb.conf file is the best one I have been able to create > for the dos stations. > > With it, I can log in and map the drive. > net use u: \\bbi-sam-2-srv\bestbilt > > > I can do directory listings and change directory to u:\win94 > > When I attempt to run a dos program (tracking.exe) I get the following > > u:\win94\> Tracking > > NET805: NETWORK DEVICE NO LONGER EXISTS READING DRIVE U > > Abort, Retry, Fail? > > f > > Access denied. > > I have much the same error if I put the executable on the local drive and > attempt to use shared .dbf data files from the server. > > I can connect to the old server with the same box. > It takes a few minutes to change all the config files for lanman, but it > works. > > On the old server, I can login, map the drives and run executables and > use the dbf data files. > > It seems to me as if there is some configuration flag where the default has > from 3.0 to 3.2 that I can't find. > > I did a detailed view of both config files from swat and ran a dif on them. > I was unable to identify a place that could be changed that would allow the > dos machines to utilize the samba file server. > > I am willing to use either different client software on the dos stations, > or update the samba setup to a different version. > I like ubuntu, but am not wedded to it. > > However, the dos stations must stay, even if I must maintain a server with > 3.0 on it to keep them running. > > Any ideas? I am more that willing to RTFM, but have exausted my ideas of > which FM and which part of it to read. Hints in this matter would be > welcome. Hints on which config option in smb.conf would be even more > welcome. > > Thanks in advance, > Jim Hurlburt > Atrium Windows and Doors Northwest. > Yakima, WA USA >1.) On your new server add the following to the [global] section of smb.conf: log level = 10 This will raise the debug level of samba - the log file(s) are usually written to /var/log/samba/log.smbd (this might be different in your distro) 2.) Take a network sniff on your new server, details are here: http://wiki.samba.org/index.php/Capture_Packets Now do the failing DOS commands again. The 1.) samba debug log might already be sufficient to track down the problem. Better would be both - the samba debug 10 log and a corresponding network sniff. To track that problem, please open a bug report at https://bugzilla.samba.org/ Cheers, G?nter If you've further questions, feel free to contact me at kukks at samba.org
James Hurlburt put forth on 2/2/2010 4:56 PM:> NET805: NETWORK DEVICE NO LONGER EXISTS READING DRIVE U > > Abort, Retry, Fail?Hi James, You didn't happen to put the new Samba server on a different IP subnet or VLAN than the old server did you? You didn't show the IP's and subnet masks of each machine. IIRC, NETBIOS can have problems crossing some routers and VLANs, possibly other network boundaries. If you aren't already, the first thing I'd do is get the new server on an IP address consecutive to the old server and make sure they're jacked into the same switch. This should eliminate any possible network topology issues causing problems. Is the new server a virtual machine? Make sure the hypervisor is allowing NETBIOS traffic to flow from the physical NIC to/from the VM. Actually, I should say, make sure it isn't disallowing such traffic. This is unlikely, but it's best to check. Running in a VM can often cause goofy hard to solve problems because of things not working at low levels the way we expect them to. Lastly, disable any iptables rules on the new server or other firewall scripting software, and disable SELinux if it is enabled. Look at netstat -an on both servers when connecting with the clients, and make sure all the same ports are being used. That's about all I can think of at this point. As Gunter mentioned, a network trace couldn't hurt. I'd probably try a few of the less time consuming recommendations above before resorting to the trace. -- Stan