Cifs won't mount with filesystems

[uggla]

This command doesn't work with filesystems-2.6.33.3-tinycore64.tcz (but it works with samba3.tcz).

sudo mount -t cifs -o guest //192.168.98.49/Xtreamer /home/tc/Xtreamer

[curaga]

Do you have util-linux loaded? Only busybox mount can do cifs/nfs without the corresponding client package.

[uggla]

Ok, now I've loaded utils-linux but it still doesn't work. I get:

tc@box:~$ sudo mount -t cifs -o guest //192.168.98.49/Xtreamer /home/tc/Xtreamer
mount: wrong fs type, bad option, bad superblock on //192.168.98.49/Xtreamer,
       missing codepage or helper program, or other error
       (for several filesystems (e.g. nfs, cifs) you might
       need a /usr/local/sbin/mount.<type> helper program)
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

[curaga]

No, I meant that your original error might've been from that - util-linux mount _can't_ do that.

[uggla]

Then it isn't working with util-linux and not without either.

[maro]

I'm not sure what the problem might be, as I can mount CIFS with BusyBox as well as the 'util-linux-ng.tcz' extension on a "plain" TC 3 system (i.e. freshly booted from CD-ROM, without any persistence):

Code: [Select]

tc@box:~$ tce-load -wi filesystems-$(uname -r) util-linux-ng 2> /dev/null
Downloading: mtd-2.6.33.3-tinycore.tcz
mtd-2.6.33.3-tinycore.tcz: OK
Downloading: filesystems-2.6.33.3-tinycore.tcz
filesystems-2.6.33.3-tinycore.tcz: OK
ncurses.tcz.dep OK
Downloading: ncurses-common.tcz
ncurses-common.tcz: OK
Downloading: ncurses.tcz
ncurses.tcz: OK
Downloading: util-linux-ng.tcz
util-linux-ng.tcz: OK

tc@box:~$ hash -r
tc@box:~$ sudo mkdir /mnt/x-drive
tc@box:~$ which mount
/usr/local/bin/mount

tc@box:~$ sudo busybox mount -t cifs //192.168.178.48/c$ /mnt/x-drive -o user=USER,pass=PW
tc@box:~$ mount | grep x-drive
//192.168.178.48/c$ on /mnt/x-drive type cifs (rw,mand,relatime,unc=\\192.168.178.48\c$,username=USER,
uid=0,noforceuid,gid=0,noforcegid,addr=192.168.178.48,file_mode=0755,dir_mode=0755,rsize=16384,wsize=57344)

tc@box:~$ ls -l /mnt/x-drive/boot.ini
-rwxr-xr-x    1 root     root           217 Jun 18  2010 /mnt/x-drive/boot.ini
tc@box:~$ head -3 /mnt/x-drive/boot.ini
[boot loader]
timeout=3
default=multi(0)disk(0)rdisk(0)partition(1)\WINNT
tc@box:~$ sudo umount /mnt/x-drive

tc@box:~$ sudo /usr/local/bin/mount -t cifs //192.168.178.48/c$ /mnt/x-drive -o user=USER,pass=PW
tc@box:~$ mount | grep x-drive
//192.168.178.48/c$ on /mnt/x-drive type cifs (rw,relatime,unc=\\192.168.178.48\c$,username=USER,
uid=0,noforceuid,gid=0,noforcegid,addr=192.168.178.48,file_mode=0755,dir_mode=0755,serverino,rsize=16384,wsize=57344)

tc@box:~$ ls -l /mnt/x-drive/boot.ini
-rwxr-xr-x    1 root     root           217 Jun 18  2010 /mnt/x-drive/boot.ini
tc@box:~$ head -3 /mnt/x-drive/boot.ini
[boot loader]
timeout=3
default=multi(0)disk(0)rdisk(0)partition(1)\WINNT
tc@box:~$ sudo umount /mnt/x-drive/
tc@box:~$

The only differences to the OP that I'm aware is the use of a password and an administrative share (i.e. 'c$'). But the latter should not make any difference at all.

[Rich]

Hi uggla
I have the 32 bit version of filesystems installed and could not mount cifs either.
Downloading cifs-utils fixed that.

[maro]

Darn, I had initially overlooked that the OP was using a 64-bit system. I've since done a few more tests purely with the respective 'filesystems-2.6.33.3-$(uname -r)' extension:

(1) the evidence from reply #5 was collected on "real" HW (a HP nx8440),
(2) initial testing with an emulated 32-bit system (QEMU v0.11.1 with KQEMU on a WinXP host) was inconclusive, I had some failures, but after I increased the memory from 48M to 64M the mounting seemed to be working every time,
(3) testing with a emulated 64-bit system (QEMU v0.11.1 without KQEMU on a WinXP host) lead initially to "Connection timed out", but after about the 3rd attempt the mounting seemed to be working,
(4) repeating test (2), but this time without KQEMU (which leads to a slower running 32-bit system), but this did not change the picture: all mounting attempts worked well,
(5) repeating test (3), but with letting 'tcpdump' run in another VT, this time around the mounting appeared to be successful from the 2nd attempt onwards.

Another observation was that "Slow work thread pool ..." messages were showing up (e.g. in the 'dmesg').

So in summary: there might be timing issues, and it would probably make sense to keep an eye on the 'dmesg' output and maybe do some network monitoring and analysis.

[Rich]

According to the mount.cifs man file on my Debian system "It is usually invoked indirectly
by the mount command when using the "-t cifs" option.". This suggests that you need
mount.cifs. According to the mount man file if you give a file type it looks for mount.type.
If you say "-t auto" it will try to guess. Using auto with filesystems installed does work.
I removed cifs-utils, rebooted and tried it. Filesystems is a dependency of cifs-utils so
make sure you don't remove that.

[uggla]

mount -t auto doesn't work with filesystems-2.6.33.3-tinycore64.tcz alone.

mount -t cifs works fine with cifs-utils loaded.