the mount command: mount.cifs //iSeries/share /mountpoint response a errormessages. mount error 112 = Host is down. the old mount command mount -t smbfs //iSeries/share /mountpoint works properly
Created attachment 1940 [details] binary file about the connection - request
Created attachment 1941 [details] binary file about the connection - response
I did not notice this problem in mounting to OS/400 server but did notice that share names typically have to be uppercased (due to a return code mapping problem, the return code sent back by the OS/400 server was mapped to the same error as "cifs filesystem not supported" so the cifs mount helper does not automatically retry with uppercase share name as the server expects) I have fixed the return code mapping problem (will be in 2.6.18 Linux kernel and cifs version 1.44) I was not able to read your ethereal trace it appears corrupted(you should be able to save the file once - which includes request and response directly from the ethereal menus). On your error "host is down" - please check two things: 1) that you can ping the name "iSeries" and if that works can you try mounting to its ip address directly e.g. 2) mount -t cifs //10.20.30.40/SHARE /mnt -o user=your_user,pass=your_password
Also note that to mount port 445 (preferred) or port 139 needs to be open on both server and client sides (unless you override the ports on mount - which is quite rare).
Created attachment 1949 [details] new try request binary
Created attachment 1950 [details] new try response binary
Dear Steve, i tried to mount like you said. ..here is the konsole output: [root@laptop ~]# ping as400 PING as400.rolandberger.net (172.20.23.10) 56(84) bytes of data. 64 bytes from as400.rolandberger.net (172.20.23.10): icmp_seq=1 ttl=61 time=16.8 ms 64 bytes from as400.rolandberger.net (172.20.23.10): icmp_seq=2 ttl=61 time=1.18 ms 64 bytes from as400.rolandberger.net (172.20.23.10): icmp_seq=3 ttl=61 time=1.20 ms ^C64 bytes from as400.rolandberger.net (172.20.23.10): icmp_seq=4 ttl=61 time=1.25 ms --- as400.rolandberger.net ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 2998ms rtt min/avg/max/mdev = 1.180/5.126/16.858/6.773 ms [root@laptop ~]# mount.cifs //172.20.23.10/BICHLER /mnt/Bichler/ -o username=bichlera,password=PASSWORD mount error 112 = Host is down Refer to the mount.cifs(8) manual page (e.g.man mount.cifs) [root@laptop ~]# [root@laptop ~]# tail -n 5 /var/log/messages Jun 6 09:38:57 laptop kernel: CIFS VFS: Calculated size 0x5a vs actual length 0x58 Jun 6 09:38:57 laptop kernel: CIFS VFS: bad smb size detected for Mid=1 Jun 6 09:38:57 laptop kernel: Jun 6 09:39:15 laptop kernel: CIFS VFS: No response for cmd 114 mid 1 Jun 6 09:39:15 laptop kernel: CIFS VFS: cifs_mount failed w/return code = -112 Thanks Andi
Just tried mount to OS/400 Netserve and do not see this a problem with their negotiate protocol response - I wonder if it has been fixed in netserve os/400 code.
We are running in the same problem as descriped. Here is a trace: (I xxxed the IP) Nov 14 12:35:20 ids2 kernel: fs/cifs/cifsfs.c: Devname: //xxx.xxx.xxx.xxx/ROOT flags: 64 Nov 14 12:35:20 ids2 kernel: fs/cifs/connect.c: CIFS VFS: in cifs_mount as Xid: 12 with uid: 0 Nov 14 12:35:20 ids2 kernel: fs/cifs/connect.c: Username: FEP Nov 14 12:35:20 ids2 kernel: fs/cifs/connect.c: UNC: \\xxx.xxx.xxx.xxx\ROOT ip: xxx.xxx.xxx.xxx Nov 14 12:35:20 ids2 kernel: fs/cifs/connect.c: Socket created Nov 14 12:35:20 ids2 kernel: fs/cifs/connect.c: sndbuf 16384 rcvbuf 87380 rcvtimeo 0x7fffffff Nov 14 12:35:20 ids2 kernel: fs/cifs/connect.c: Demultiplex PID: 17782 Nov 14 12:35:20 ids2 kernel: fs/cifs/connect.c: Existing smb sess not found Nov 14 12:35:20 ids2 kernel: fs/cifs/transport.c: For smb_command 114 Nov 14 12:35:20 ids2 kernel: fs/cifs/transport.c: Sending smb of length 47 Nov 14 12:35:20 ids2 kernel: | 0x00 0x00 0x00 0x2f 0xff 0x53 0x4d 0x42 | _ _ _ / 377 S M B Nov 14 12:35:20 ids2 kernel: | 0x72 0x00 0x00 0x00 0x00 0x00 0x01 0x80 | r _ _ _ _ _ _ _ Nov 14 12:35:20 ids2 kernel: | 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 | _ _ _ _ _ _ _ _ Nov 14 12:35:20 ids2 kernel: | 0x00 0x00 0x00 0x00 0x00 0x00 0x75 0x45 | _ _ _ _ _ _ u E Nov 14 12:35:20 ids2 kernel: | 0x00 0x00 0x01 0x00 0x00 0x0c 0x00 0x02 | _ _ _ _ _ _ _ _ Nov 14 12:35:20 ids2 kernel: | 0x4e 0x54 0x20 0x4c 0x4d 0x20 0x30 0x2e | N T L M 0 . Nov 14 12:35:20 ids2 kernel: | 0x31 0x32 0x00 | 1 2 _ Nov 14 12:35:20 ids2 kernel: fs/cifs/connect.c: rfc1002 length 0x58) Nov 14 12:35:20 ids2 kernel: | 0x54 0x00 0x00 0x00 0xff 0x53 0x4d 0x42 | T _ _ _ 377 S M B Nov 14 12:35:20 ids2 kernel: | 0x72 0x00 0x00 0x00 0x00 0x80 0x01 0x80 | r _ _ _ _ _ _ _ Nov 14 12:35:20 ids2 kernel: | 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 | _ _ _ _ _ _ _ _ Nov 14 12:35:20 ids2 kernel: | 0x00 0x00 0x00 0x00 0x00 0x00 0x75 0x45 | _ _ _ _ _ _ u E Nov 14 12:35:20 ids2 kernel: | 0x00 0x00 0x01 0x00 0x11 0x00 0x00 0x03 | _ _ _ _ _ _ _ _ Nov 14 12:35:20 ids2 kernel: | 0x05 0x00 0x01 0x00 0x00 0x10 0x00 0x00 | _ _ _ _ _ _ _ _ Nov 14 12:35:20 ids2 kernel: | 0x00 0x10 0x00 0x00 0x2d 0xae 0x00 0x00 | _ _ _ _ - 256 _ _ Nov 14 12:35:20 ids2 kernel: | 0x1d 0xc2 0x00 0x00 0x80 0xe6 0x5a 0x0f | _ 302 _ _ _ 346 Z _ Nov 14 12:35:20 ids2 kernel: | 0xe1 0x07 0xc7 0x01 0x88 0xff 0x08 0x11 | 341 _ 307 _ _ 377 _ _ Nov 14 12:35:20 ids2 kernel: | 0x00 0x32 0x5c 0x91 0xfa 0x98 0x49 0x8e | _ 2 \ _ 372 _ I _ Nov 14 12:35:20 ids2 kernel: | 0x1f 0x00 0x00 0x00 0xd8 0xc7 0x81 0x00 | _ _ _ _ 330 307 _ _ Nov 14 12:35:20 ids2 kernel: | _ _ _ _ 330 307 _ _ Nov 14 12:35:20 ids2 kernel: CIFS VFS: Calculated size 0x5a vs actual length 0x58 Nov 14 12:35:20 ids2 kernel: CIFS VFS: bad smb size detected for Mid=1 Nov 14 12:35:20 ids2 kernel: Bad SMB: : dump of 48 bytes of data at 0xe50b1100 Nov 14 12:35:20 ids2 kernel: Nov 14 12:35:20 ids2 kernel: 00000054 424d53ff 00000072 80018000 T . . . 377 S M B r . . . . . . . Nov 14 12:35:20 ids2 kernel: 00000000 00000000 00000000 45750000 . . . . . . . . . . . . . . u E Nov 14 12:35:20 ids2 kernel: 00010000 03000011 00010005 00001000 . . . . . . . . . . . . . . . . Nov 14 12:35:38 ids2 kernel: CIFS VFS: No response for cmd 114 mid 1 Nov 14 12:35:38 ids2 kernel: fs/cifs/transport.c: marking request for retry Nov 14 12:35:38 ids2 kernel: fs/cifs/misc.c: Null buffer passed to cifs_small_buf_release Nov 14 12:35:38 ids2 kernel: fs/cifs/transport.c: tcp session dead - return to caller to retry Nov 14 12:35:38 ids2 kernel: fs/cifs/connect.c: No session or bad tcon Nov 14 12:35:38 ids2 kernel: fs/cifs/connect.c: CIFS VFS: leaving cifs_mount (xid = 12) rc = -112 Nov 14 12:35:38 ids2 kernel: CIFS VFS: cifs_mount failed w/return code = -112
The server I tried claimed a verison of OS400 V5R4M0 What is the version number of your OS400 Netserver? Is there an OS/400 bug number (APAR or PMR number) I could correlate this with? It looks like a malformed response, but it would be good to know if it is alread fixed on the server.
(In reply to comment #10) > The server I tried claimed a verison of OS400 V5R4M0 > What is the version number of your OS400 Netserver? > Is there an OS/400 bug number (APAR or PMR number) I could correlate > this with? > It looks like a malformed response, but it would be good to know > if it is alread fixed on the server. We use V5R2. I don´t know about a bug number, but maybe it is fixed with V5R4. Sadly, updating is out of the question at this time...
(In reply to comment #11) > (In reply to comment #10) > > The server I tried claimed a verison of OS400 V5R4M0 > > What is the version number of your OS400 Netserver? > > Is there an OS/400 bug number (APAR or PMR number) I could correlate > > this with? > > It looks like a malformed response, but it would be good to know > > if it is alread fixed on the server. > We use V5R2. > I don´t know about a bug number, but maybe it is fixed with V5R4. Sadly, > updating is out of the question at this time... There is a PTF in V5R3 of OS/400 (MF40347), but I had applied the V5R2 patch related to this prior to my release upgrade. Don't know if it will solve your problem........
I was trying to cleanup old bugs, and in looking at this was trying to examine the trace files - none of them are readable by standard tools. Can you simply capture these with wireshark or tcpdump from the client so we can make 100% sure that this is a server bug (presumably long since fixed). http://wiki.samba.org/index.php/Capture_Packets
Still seeing the uppercase problem testing against v6r1 w/ # /sbin/mount.cifs -V -h mount.cifs version: 1.10 [root@rchs3bld ~]# mount.cifs //9.1.2.3/books /mnt -o username=x, password=pass mount error 6 = No such device or address Refer to the mount.cifs(8) manual page (e.g.man mount.cifs) [root@rchs3bld ~]# mount.cifs //9.1.2.3/BOOKS /mnt -o username=x, password=x will test w/ newer cifs code
Still seeing the upper/lowercase thing w/ a test kernel from jlayton # uname -a Linux xxx 2.6.18-132.el5.jtltest.64 #1 SMP Sun Feb 22 17:38:13 EST 2009 i686 i686 i386 GNU/Linux # mount.cifs //9.1.2.3/books /mnt -o username=x,password=y mount error 6 = No such device or address Refer to the mount.cifs(8) manual page (e.g.man mount.cifs) # mount.cifs //9.1.2.3/BOOKS /mnt -o username=x,password=y
The auto-uppercasing thing is done by mount.cifs. You may want to try that on a more recent mount.cifs version. In particular, you may need: commit dd9002cf498e177b769eabd2fed40213069cd239 Author: Jeff Layton <jlayton@redhat.com> Date: Thu Oct 9 09:58:39 2008 -0400 mount.cifs: have uppercase_string return success on NULL pointer We currently don't attempt to uppercase the device portion of the mount string if there isn't a prefixpath. Fix that by making uppercase_string return success without doing anything on a NULL pointer. Signed-off-by: Jeff Layton <jlayton@redhat.com>
uppercasing of sharename is now autoretried by mount.cifs and can be entered on mount (in all uppercase) to workaround for older mount.cifs