Rob Ginn
1999-Aug-13 17:57 UTC
Help needed using Samba over SSH (DOS works, Win9x doesn't)
Hi all, I've been trying to mount partitions on a UNIX machine behind a firewall on a Windows machine. This works fine inside the firewall, but from outside I need to tunnel through it using SSH. I can get this to work from a DOS window on the Windows machine by forwarding port 139, but when I try to access a file from the GUI, I get a "bad directory" error on windows. An unsatisfactory workaround is to drag the file from the SAMBA server to the local desktop, work oon it, and then drag it back to the SAMBA server. I've tried multiple UNIXes, 2 versions of SSH on UNIX, and 2 versions of SSH on Windows. I also tried both Win95 and Win98. I thought maybe there were some UDP packets necessary from the GUI side, but when I used TCP dump on an unencrypted connection (which worked), I didn't see any. I also tried running SSH inside the firewall which "probably" let any UDP packets through direct (the docs on windows SSH programs didn't really address what happens to the corresponding UDP port when you forward a TCP port). I searched the Usenet (where there are a number of requests on how to do thus but no answers -- plus they don't even have it working with DOS). And I searched the archives of this list -- where I see that someone described the same symptoms back in 1997, but no solution was discussed. So, does anyone know how to do this now? If not, does anyone know why it's not working (i.e. what exactly is the problem -- so I can figure out a work around)? Or, worst case, does anyone know what the specific requests (packets sent) made by DOS programs vs the ones made by Win9x programs. Thanks in advance, Rob Ginn - Rob Ginn rob@sun701.nawcad.navy.mil
Rob Ginn
1999-Aug-16 22:33 UTC
Help needed using Samba over SSH (DOS works, Win9x doesn't)
Cliff, thanks for the info.>So, you're doubleclicking on a file and getting the error? When I do >that, that process just hangs. On the other hand, if I right-click on theMine hangs too, but if you wait about 60 secs, it un-freezes. That's when you get the path error message from windows.>I've defined entries in my local lmhosts file for 127.0.0.1 => my samba >hosts. This in itself is odd, as I don't think you're supposed to have >more than one Netbios name attached to a given ip address. I suppose itit doesn't matter since it only looks it up one way>> Or, worst case, does anyone know what the specific requests (packets >> sent) made by DOS programs vs the ones made by Win9x programs. > >Uh, maybe we're talking about different problems. I'm talking about the >ability to double-click on a registered file type. Are you talking about >the method of mounting a share?No, I am proposing a method of locating the problem based on DOS and Win9x GUI differences and asking for jumpstart info. My problem also shows up if I go into a windows program, select open on the menu, and try to open a file on the Samba mount. Don't you also have that problem? My take on your work-around with the send-to was that you were copying the file to a local version and then running the app on it. Am I missing something? Since it works 100% from a DOS window, but it doesn't from the GUI, it is clear that Win32 programs make different calls to open files. (This is verifyed by fopen() vs winopen() and Samba logs). So, if I can determine which specific SMB request is failing, I can figure out a work-around. Note that I am assuming that it _is_ a failed request which Win9x makes but that DOS does not make and not some bizzare threading problem in Win9x (as has been proposed elsewhere). For example, if someone said that Win9x GUI open calls make a UDP request, I'd know that was the problem right off and could get/write a UDP forwarder. Otherwise, I'll add debugging code to each of the involved calls and see which one is getting messed up. Right now, I'm testing the UDP theory.> >> Thanks in advance, >> Rob Ginn >> >> - Rob Ginn >> rob@sun701.nawcad.navy.mil > >c >-- >Cliff Green >green@umdnj.edu >Academic Computing Service - UMDNJ- Rob Ginn rob@sun701.nawcad.navy.mil