connection to os/2 warp worked well with version 2.2.8 (from suse linux 8.2) but since 3.0 (suse 9.1) connection is impossible. connection from os/2 to samba (suse linux 9.1) is stable
(In reply to comment #0) > connection to os/2 warp worked well with version 2.2.8 (from suse linux 8.2) > but since 3.0 (suse 9.1) connection is impossible. > connection from os/2 to samba (suse linux 9.1) is stable Regrettably I have to confirm this issue in a similar setup: smbmount //os2w4peer/ourshare /mnt/ourserver -o username=MyIDonServer works on SuSE 8.2 but fails on SuSE 9.1 (SuSEfirewall2 disabled for testing): smbmount will now report success ("tconx ok") irrespective of the password entered (i.e. whether it is right or wrong, on anything except zero-length), but unlike with previous versions, "dir /mnt/ourserver" will now result in an "access denied" error. Attempts of going back to the version of the previous release SuSE 9.0 from ftp://ftp.suse.com/pub/projects/samba/2.2/i386/9.0/samba-client-2.2.9-1.i586.rpm makes rpm -i complain about broken dependencies for libldap.so.2 and liplber.so.2 (which I chose to override by --nodeps, and symlink the respective libl*.2.0.111 from SuSE 8.2), but there are even more (i.e. libcrypto.so.0.9.6 and libssl.so.0.9.6) that are no longer matched in SuSE 9.1 and have to be copied over from an old installation - however after that "dir /mnt/ourserver" (i.e. /bin/ls) times out with an "Input/output error" - so if there is a chance to resurrect samba 2.2.9 on SuSE 9.1 it seems to require a lot of work anyway (probably even recompiling the whole stuff on the new platform). So here's the "lowdown" for the above smbmount (including version details) run in these three setups at debug level 5 (the versions of /etc/samba/smb.conf have been left at their respective defaults as far as possible for producing these logs, without making use of the obvious potential shown for further tweaking): This one works on "SuSE Linux 8.2" (e.g. subsequent "dir /mnt/ourserver" does show whatever files it should see on the host): INFO: Debug class all level = 1 (pid 1897 from pid 1897) mount.smbfs started (version 2.2.7a-SuSE) load_client_codepage: loading codepage 850. load_unicode_map: loading unicode map for codepage 850. load_unicode_map: loading unicode map for codepage ISO8859-1. added interface ip=192.168.100.3 bcast=192.168.100.255 nmask=255.255.255.0 resolve_lmhosts: Attempting lmhosts lookup for name os2w4peer<0x20> getlmhostsent: lmhost entry: 127.0.0.1 localhost resolve_hosts: Attempting host lookup for name os2w4peer<0x20> Connecting to 192.168.100.2 at port 139 socket option SO_KEEPALIVE = 1 socket option SO_REUSEADDR = 0 socket option SO_BROADCAST = 0 socket option TCP_NODELAY = 1 socket option IPTOS_LOWDELAY = 16 socket option IPTOS_THROUGHPUT = 16 socket option SO_SNDBUF = 16384 socket option SO_RCVBUF = 87380 socket option SO_SNDLOWAT = 1 socket option SO_RCVLOWAT = 1 socket option SO_SNDTIMEO = 0 socket option SO_RCVTIMEO = 0 Sent session request size=0 smb_com=0x0 smb_rcls=0 smb_reh=0 smb_err=0 smb_flg=0 smb_flg2=0 smb_tid=0 smb_pid=0 smb_uid=0 smb_mid=0 smt_wct=0 smb_bcc=0 1897: session request ok size=69 smb_com=0x72 smb_rcls=0 smb_reh=0 smb_err=0 smb_flg=137 smb_flg2=1 smb_tid=0 smb_pid=1897 smb_uid=0 smb_mid=1 smt_wct=13 smb_vwv[0]=4 (0x4) smb_vwv[1]=3 (0x3) smb_vwv[2]=4356 (0x1104) smb_vwv[3]=25 (0x19) smb_vwv[4]=1 (0x1) smb_vwv[5]=3 (0x3) smb_vwv[6]=30191 (0x75EF) smb_vwv[7]=0 (0x0) smb_vwv[8]=31213 (0x79ED) smb_vwv[9]=12533 (0x30F5) smb_vwv[10]=65535 (0xFFFF) smb_vwv[11]=8 (0x8) smb_vwv[12]=48 (0x30) smb_bcc=8 size=69 smb_com=0x72 smb_rcls=0 smb_reh=0 smb_err=0 smb_flg=137 smb_flg2=1 smb_tid=0 smb_pid=1897 smb_uid=0 smb_mid=1 smt_wct=13 smb_vwv[0]=4 (0x4) smb_vwv[1]=3 (0x3) smb_vwv[2]=4356 (0x1104) smb_vwv[3]=25 (0x19) smb_vwv[4]=1 (0x1) smb_vwv[5]=3 (0x3) smb_vwv[6]=30191 (0x75EF) smb_vwv[7]=0 (0x0) smb_vwv[8]=31213 (0x79ED) smb_vwv[9]=12533 (0x30F5) smb_vwv[10]=65535 (0xFFFF) smb_vwv[11]=8 (0x8) smb_vwv[12]=48 (0x30) smb_bcc=8 size=41 smb_com=0x73 smb_rcls=0 smb_reh=0 smb_err=0 smb_flg=136 smb_flg2=1 smb_tid=0 smb_pid=1897 smb_uid=4096 smb_mid=1 smt_wct=3 smb_vwv[0]=255 (0xFF) smb_vwv[1]=0 (0x0) smb_vwv[2]=0 (0x0) smb_bcc=0 size=41 smb_com=0x73 smb_rcls=0 smb_reh=0 smb_err=0 smb_flg=136 smb_flg2=1 smb_tid=0 smb_pid=1897 smb_uid=4096 smb_mid=1 smt_wct=3 smb_vwv[0]=255 (0xFF) smb_vwv[1]=0 (0x0) smb_vwv[2]=0 (0x0) smb_bcc=0 1897: session setup ok size=42 smb_com=0x75 smb_rcls=0 smb_reh=0 smb_err=0 smb_flg=136 smb_flg2=1 smb_tid=59392 smb_pid=1897 smb_uid=4096 smb_mid=1 smt_wct=2 smb_vwv[0]=255 (0xFF) smb_vwv[1]=0 (0x0) smb_bcc=3 1897: tconx ok However Samba 3.0.4 fails (with "access denied" on subsequent ls) on "SuSE Linux 9.1 personal" installed with default selections and latest online updates: mount.smbfs started (version 3.0.4-SUSE) added interface ip=192.168.100.3 bcast=192.168.100.255 nmask=255.255.255.0 Opening cache file at /var/lib/samba/gencache.tdb no entry for os2w4peer#20 found. resolve_lmhosts: Attempting lmhosts lookup for name os2w4peer<0x20> getlmhostsent: lmhost entry: 127.0.0.1 localhost resolve_wins: Attempting wins lookup for name os2w4peer<0x20> resolve_wins: WINS server resolution selected and no WINS servers listed. resolve_hosts: Attempting host lookup for name os2w4peer<0x20> namecache_store: storing 1 address for os2w4peer#20: 192.168.100.2:0 Connecting to 192.168.100.2 at port 445 error connecting to 192.168.100.2:445 (Connection refused) Connecting to 192.168.100.2 at port 139 socket option SO_KEEPALIVE = 1 socket option SO_REUSEADDR = 0 socket option SO_BROADCAST = 0 socket option TCP_NODELAY = 1 socket option IPTOS_LOWDELAY = 16 socket option IPTOS_THROUGHPUT = 16 socket option SO_SNDBUF = 16384 socket option SO_RCVBUF = 87380 socket option SO_SNDLOWAT = 1 socket option SO_RCVLOWAT = 1 socket option SO_SNDTIMEO = 0 socket option SO_RCVTIMEO = 0 Sent session request size=0 smb_com=0x0 smb_rcls=0 smb_reh=0 smb_err=0 smb_flg=0 smb_flg2=0 smb_tid=0 smb_pid=0 smb_uid=0 smb_mid=0 smt_wct=0 smb_bcc=0 3601: session request ok size=79 smb_com=0x72 smb_rcls=0 smb_reh=0 smb_err=0 smb_flg=137 smb_flg2=49153 smb_tid=0 smb_pid=3601 smb_uid=0 smb_mid=2 smt_wct=13 smb_vwv[ 0]= 4 (0x4) smb_vwv[ 1]= 3 (0x3) smb_vwv[ 2]= 4356 (0x1104) smb_vwv[ 3]= 25 (0x19) smb_vwv[ 4]= 1 (0x1) smb_vwv[ 5]= 3 (0x3) smb_vwv[ 6]=16941 (0x422D) smb_vwv[ 7]= 0 (0x0) smb_vwv[ 8]=30827 (0x786B) smb_vwv[ 9]=12533 (0x30F5) smb_vwv[10]=65535 (0xFFFF) smb_vwv[11]= 8 (0x8) smb_vwv[12]= 48 (0x30) smb_bcc=18 size=79 smb_com=0x72 smb_rcls=0 smb_reh=0 smb_err=0 smb_flg=137 smb_flg2=49153 smb_tid=0 smb_pid=3601 smb_uid=0 smb_mid=2 smt_wct=13 smb_vwv[ 0]= 4 (0x4) smb_vwv[ 1]= 3 (0x3) smb_vwv[ 2]= 4356 (0x1104) smb_vwv[ 3]= 25 (0x19) smb_vwv[ 4]= 1 (0x1) smb_vwv[ 5]= 3 (0x3) smb_vwv[ 6]=16941 (0x422D) smb_vwv[ 7]= 0 (0x0) smb_vwv[ 8]=30827 (0x786B) smb_vwv[ 9]=12533 (0x30F5) smb_vwv[10]=65535 (0xFFFF) smb_vwv[11]= 8 (0x8) smb_vwv[12]= 48 (0x30) smb_bcc=18 size=41 smb_com=0x73 smb_rcls=0 smb_reh=0 smb_err=0 smb_flg=136 smb_flg2=1 smb_tid=0 smb_pid=3601 smb_uid=59392 smb_mid=3 smt_wct=3 smb_vwv[ 0]= 255 (0xFF) smb_vwv[ 1]= 0 (0x0) smb_vwv[ 2]= 1 (0x1) smb_bcc=0 size=41 smb_com=0x73 smb_rcls=0 smb_reh=0 smb_err=0 smb_flg=136 smb_flg2=1 smb_tid=0 smb_pid=3601 smb_uid=59392 smb_mid=3 smt_wct=3 smb_vwv[ 0]= 255 (0xFF) smb_vwv[ 1]= 0 (0x0) smb_vwv[ 2]= 1 (0x1) smb_bcc=0 3601: session setup ok size=42 smb_com=0x75 smb_rcls=0 smb_reh=0 smb_err=0 smb_flg=136 smb_flg2=1 smb_tid=53248 smb_pid=3601 smb_uid=59392 smb_mid=4 smt_wct=2 smb_vwv[ 0]= 255 (0xFF) smb_vwv[ 1]= 0 (0x0) smb_bcc=3 3601: tconx ok Trying to use the previous Samba 2.2.9 on the above "SuSE Linux 9.1" (after uninstalling samba-client 3.0.4 of course) connects like this (but then ls times out): mount.smbfs started (version 2.2.9-1-SuSE) load_client_codepage: loading codepage 850. load_unicode_map: loading unicode map for codepage 850. load_unicode_map: loading unicode map for codepage ISO8859-1. added interface ip=192.168.100.3 bcast=192.168.100.255 nmask=255.255.255.0 resolve_lmhosts: Attempting lmhosts lookup for name os2w4peer<0x20> getlmhostsent: lmhost entry: 127.0.0.1 localhost resolve_hosts: Attempting host lookup for name os2w4peer<0x20> Connecting to 192.168.100.2 at port 139 socket option SO_KEEPALIVE = 1 socket option SO_REUSEADDR = 0 socket option SO_BROADCAST = 0 socket option TCP_NODELAY = 1 socket option IPTOS_LOWDELAY = 16 socket option IPTOS_THROUGHPUT = 16 socket option SO_SNDBUF = 16384 socket option SO_RCVBUF = 87380 socket option SO_SNDLOWAT = 1 socket option SO_RCVLOWAT = 1 socket option SO_SNDTIMEO = 0 socket option SO_RCVTIMEO = 0 Sent session request size=0 smb_com=0x0 smb_rcls=0 smb_reh=0 smb_err=0 smb_flg=0 smb_flg2=0 smb_tid=0 smb_pid=0 smb_uid=0 smb_mid=0 smt_wct=0 smb_bcc=0 3290: session request ok size=69 smb_com=0x72 smb_rcls=0 smb_reh=0 smb_err=0 smb_flg=137 smb_flg2=1 smb_tid=0 smb_pid=3290 smb_uid=0 smb_mid=1 smt_wct=13 smb_vwv[0]=4 (0x4) smb_vwv[1]=3 (0x3) smb_vwv[2]=4356 (0x1104) smb_vwv[3]=25 (0x19) smb_vwv[4]=1 (0x1) smb_vwv[5]=3 (0x3) smb_vwv[6]=17410 (0x4402) smb_vwv[7]=0 (0x0) smb_vwv[8]=3001 (0xBB9) smb_vwv[9]=12534 (0x30F6) smb_vwv[10]=65535 (0xFFFF) smb_vwv[11]=8 (0x8) smb_vwv[12]=48 (0x30) smb_bcc=8 size=69 smb_com=0x72 smb_rcls=0 smb_reh=0 smb_err=0 smb_flg=137 smb_flg2=1 smb_tid=0 smb_pid=3290 smb_uid=0 smb_mid=1 smt_wct=13 smb_vwv[0]=4 (0x4) smb_vwv[1]=3 (0x3) smb_vwv[2]=4356 (0x1104) smb_vwv[3]=25 (0x19) smb_vwv[4]=1 (0x1) smb_vwv[5]=3 (0x3) smb_vwv[6]=17410 (0x4402) smb_vwv[7]=0 (0x0) smb_vwv[8]=3001 (0xBB9) smb_vwv[9]=12534 (0x30F6) smb_vwv[10]=65535 (0xFFFF) smb_vwv[11]=8 (0x8) smb_vwv[12]=48 (0x30) smb_bcc=8 size=41 smb_com=0x73 smb_rcls=0 smb_reh=0 smb_err=0 smb_flg=136 smb_flg2=1 smb_tid=0 smb_pid=3290 smb_uid=57344 smb_mid=1 smt_wct=3 smb_vwv[0]=255 (0xFF) smb_vwv[1]=0 (0x0) smb_vwv[2]=0 (0x0) smb_bcc=0 size=41 smb_com=0x73 smb_rcls=0 smb_reh=0 smb_err=0 smb_flg=136 smb_flg2=1 smb_tid=0 smb_pid=3290 smb_uid=57344 smb_mid=1 smt_wct=3 smb_vwv[0]=255 (0xFF) smb_vwv[1]=0 (0x0) smb_vwv[2]=0 (0x0) smb_bcc=0 3290: session setup ok size=42 smb_com=0x75 smb_rcls=0 smb_reh=0 smb_err=0 smb_flg=136 smb_flg2=1 smb_tid=55296 smb_pid=3290 smb_uid=57344 smb_mid=1 smt_wct=2 smb_vwv[0]=255 (0xFF) smb_vwv[1]=0 (0x0) smb_bcc=3 3290: tconx ok If any helpful tests could be run, please let us know which... (BTW see also https://bugzilla.samba.org/show_bug.cgi?id=821)
nothing has changed, it does not work to connect to os/2.
I can confirm this is still an issue in 3.0.15.pre2-01. On the client side I had better luck with 3.0.14a, from Linux I was able to browse and read os2 files through KDE3.4 running on SuSE LP 9.3, although I was able to mount the os2 resource any access returns an IO error. With 3.015... I am unable to browse. I am able to get the list of share resources from the os2 servers, but through KDE trying to drill down into the actual resouce returns an error. I still see the same mount behavior as 3.0.14a. On the other hand, with 3.0.15 I am able to connect an os2 client to linux samba server and through the os2 drives object create folders and files, though the access seems to have some long pauses. I am able to see the directory trees and navigate. With the server at the 3.0.14a level I am not able to manipulate through the os2 drive object at all it just hangs. I am able to access throught the os2 command line and create files and folders. I hope I haven't been too confusing, I am a LINUX newbie.
are we any better in the 3.0.20 series?
I'm not seeing any problems using the OS/2 Peer client to connect to a 3.0.26pre1 samba server, but due to broken timestamps in CIFS I had to recompile SUSE 10.2 2.6.18.2-34 kernel to include smbfs support in order for Linux to usefully mount an OS/2 LM share.
(In reply to comment #4) > are we any better in the 3.0.20 series? It's every bit as broken in smbmount 3.0.24 I'm afraid, cf. http://lists4.opensuse.org/opensuse/2005-04/msg01638.html and https://bugs.launchpad.net/samba/+bug/112839 from downstream. # mount -t smbfs //host/share /mnt/warp -o ro,username=user Password: # dir /mnt/warp dir: /mnt/gatekeeper: Input/output error # mount -t cifs //host/share /mnt/warp -o ro,username=user Password: mount error 2 = No such file or directory Refer to the mount.cifs(8) manual page (e.g.man mount.cifs) # mount -t cifs //host/share /mnt/warp -o ro,username=user Password: mount error 112 = Host is down Refer to the mount.cifs(8) manual page (e.g.man mount.cifs) The latter message is repeated on all further attempts to connect. Wonder how Felix Miata even seems to get to the point of having the share mounted and files displayed (albeit with wrong timestamps) - I never did. Given that Samba 3 should be able to connect to OS/2 hosts at some point in its lifetime before the next major release, at least as well as Samba 2 did, and in light of the fact that this has been going on for years, I wonder what can be done about it now.
All /mnt/warp (for consistency in the previous example), of course.
eComStation 1.2 SUSE 10.2 samba 3.0.26pre1.SVN-build-21894 This /etc/fstab entry works: //hostname/sharename /mountpoint smbfs ro,guest,dmask=777,fmask=664 0 0 This works too: smbmount //hostname/sharename /mountpoint -o guest,ro,dmask=777,fmask=664 Both methods also work on Ubuntu Feisty - after disabling IPv6 and installing the optional smbfs deb. Bad timestamps only happened when I tried CIFS mounting an OS/2 share; last tried over 6 months ago.
Still does not work for me using smbmount 3.0.24 (after apt-get install smbfs of course), attempting to connect to an OS/2 Warp 4 host (as Samba 2 can do): IPv6 has been dealt with as per http://ubuntuforums.org/showthread.php?t=6841 (successfully of course, as there is no mention of "inet6" in the output of "ip a" anymore) - and yet trying your proposed anonymous mount per smbmount //host/share /mnt/warp -o guest,ro,dmask=777,fmask=664 or mount -t smbfs //host/share /mnt/warp -o guest,ro,dmask=777,fmask=664 causes file listing attempts to immediately return an access privileges error: # time dir /mnt/warp dir: /mnt/warp: Permission denied real 0m0.005s user 0m0.000s sys 0m0.004s whereas having specified "username=user" instead of "guest" on mount (as it should be, for this is a server where users do have to be asked for a password and differentiated in their rights of access), the same causes the usual error after some delay: # time dir /mnt/warp dir: /mnt/warp: Input/output error real 0m30.006s user 0m0.004s sys 0m0.000s From https://bugzilla.samba.org/show_bug.cgi?id=4090 I understand you are probably using a patch to the password handling though (mentioning a CIFS rebuilt with CONFIG_CIFS_WEAK_PW_HASH), so either this (if any similar change had to be made to SMBFS as well) or your use of a later but rare descendant of OS/2, and/or of an even newer Samba than the one that ships with Ubuntu 7.04 "Feisty Fawn", may also make a difference. So the reporter's opening statement of 2004-05-14 still stands AFAICT. Time permitting, I'm prepared to further investigate, of course - just don't want to clutter up this bugtracker by posting full dumps at extreme loglevels unless we know specifically which part and level of detail we are looking for.
Big dumps are fine if attached rather than pasted as a comment. Bug 4090 only applies to people trying to use CIFS instead of SMBFS. This may be a later descendant of Warp 4, but it is by no means rare, and it has full current support by its supplier, unlike the original Warp 4 released 11 years ago: X:\IBMLAN\SYSLEVEL.PER IBM Peer for OS/2 Version 5.20 Component ID 5639A6000 Current CSD level: IP08608 Prior CSD level: IP08605 X:\IBMLAN\SYSLEVEL.REQ IBM OS/2 LAN Requester Version 5.20 Component ID 562294000 Current CSD level: IP08608 Prior CSD level: IP08605 X:\MPTN\SYSLEVEL.MPT IBM OS/2 TCP/IP Stack Version 6.01 Component ID 5639B1700 Current CSD level: WR08708 Prior CSD level: WR08701 X:\MUGLIB\SYSLEVEL.MUG IBM OS/2 User Profile Management - Client Version 5.20 Component ID 5639A6000 Current CSD level: WR08608 Prior CSD level: WR08605 X:\OS2\INSTALL\SYSLEVEL.ECS eComStation Operating System 1.1 Version 1.10 Component ID 5639A6101 Type 0C Current CSD level: XR0C004 Prior CSD level: XR04502 X:\OS2\INSTALL\SYSLEVEL.FPK OS/2 Convenience Package Service Level Version 1.00 Component ID 566933010 Type Fixpak Current CSD level: XR0C004 Prior CSD level: XR0C004 X:\OS2\INSTALL\SYSLEVEL.OS2 Convenience Package - OS/2 Warp 4 Base Operating System Version 4.52 Component ID 5639A6101 Type 0C Current CSD level: XR0C004 Prior CSD level: XR04503 X:\tcpip\bin\SYSLEVEL.TCP IBM TCP/IP for Warp Version 4.32 Component ID 5639A6600 Current CSD level: UN02334 Prior CSD level: UN02206
> Big dumps are fine if attached rather than pasted as a comment. And yet they ought to contain something someone is specifically looking for. I.e. we'd need an indication of specific operations to perform, with a defined log level, as well as somebody well acquainted with the protocols and Samba's implementation - and probably a way to test Samba 2 and 3 in parallel. > [eComStation] This may be a later descendant of Warp 4, > but it is by no means rare, > and it has full current support by its supplier, > unlike the original Warp 4 released 11 years ago ...which has given me and many others virtually continuous uptime ever since (with driver support in particular for several pieces of ISDN hardware that have never been fully supported by Linux), and for many years worked well as a server for smbclient/smbmount until something got broken in or around Samba 3. Both eComStation and OS/2 Warp 4 are (still) around for a reason, and probably will be for quite a while, so rather than debating the merits of either system, of course the priority ought to be getting this issue fixed ASAP.
Any progress on this bug? While there is no indication of what needs to be logged specifically when performing which steps, it is hard for users to supply any meaningful details on what goes wrong at protocol level (with no further clues but https://bugzilla.samba.org/show_bug.cgi?id=821#c3), let alone to compare them to find out what eComStation may be doing differently from OS/2 Warp 4. AFAICS https://bugs.launchpad.net/samba/+bug/112839 is related, and https://bugs.launchpad.net/ubuntu/+source/foomatic-filters/+bug/60931 may be.
This is an issue with smbfs, which is going to be dropped from the Linux kernel soon. Please retest with mount.cifs.
mount.cifs will not work on kernels omitting CONFIG_CIFS_WEAK_PW_HASH, which is needed for the required last mount parameter -o servern=MYHOST,sec=lanman to work. The man page needs to explain the use of these options, and distributions need to use appropriate defaults for their kernels (cf. https://bugs.launchpad.net/samba/+bug/112839) so as not to break access to OS/2 (and probably Win9x as well).
first of all - really great irc talk with you today on channel #samba-os2 :-) Nice to have such experienced os/2 / linux users around. The facts: ========== the kernel module smbfs.ko and the (original!) samba userland helper applets - smbmount - smbmnt - smbumount will be dropped _very_ soon. This raises the burden on the successor of smbfs - cifs vfs - to also support legacy servers like win9x/me, os/2, DOS,... Today and the future: ===================== Some leftover work has to be done to cifs vfs to "support legacy servers as much as possible" - lots of legacy support has already been implemented. THE PROBLEM: ============ Distro maintainers _now_ have to decide, whether to build todays and future kernels with the build option CONFIG_CIFS_WEAK_PW_HASH or not ...! It's a security concern. Todays REAL situation: ====================== I have been told, that many distros already deliver kernels with CONFIG_CIFS_WEAK_PW_HASH disabled - if smbfs has also been removed - this would simply mean: - no mount support _at all_ for legacy clients anymore! I'm pretty sure, this will be discussed in more detail soon. Cheers, Guenter
If it's still broken in 3.5, please reopen. 3.0 isn't supported anymore.