Unfortunately no one can be told what fun_plug is - you have to see it for yourself.
You are not logged in.
I want to back up the content from DNS-323 to other HDD which I shared on the network. So I tried to use the following but have no idea what is wrong:
root# mkdir /mnt/m1201 root# mount -t smbfs -o //192.168.1.100/m1201 /mnt/m1201 mount: can't find /mnt/m1201 in /etc/fstab
So far I can only use smbclient but the functionality provided by smbclient is too limited.
Any help?
Offline
Ok, I remove the -o option but this error message appear:
root# mount -t smbfs //192.168.1.100/m1201 /mnt/m1201/ mount: mounting //192.168.1.100/m1201 on /mnt/m1201/ failed: No such device
Offline
I don't think you have the right files to do "mount -t smbfs". Try "mount -t junk" and you'll get the same "No such device" error message.
I don't find mount.smbfs on my dns-323 (with all the FFP packages). I do have mount.cifs from the Samba 3.3.2 FFP pacakge which is what you probably want (mount -t cifs)... it's the newer replacement (see http://samba.org/samba/smbfs/). If I recall correctly I had issues with >2GB files and such last time I used smbfs. But even with mount.cifs you need the additional cifs.ko kernel module as I don't think the DNS-323 kernel has built-in support for smbfs or cifs.
With the kernel module loaded (compiled against 1.06 sources) using "insmod cifs.ko"; I can get further trying to mount a Windows share. But I still haven't made it work end-to-end. I'm getting "mount error(112): Host is down" for a share that works 100% when I use mount.cifs from a Debian PC.
I've attached the kernel module for anyone who wants to try...
EDIT - See the next post with cifs.1.50.ko before downloading the module from this post. I'll leave this one here as it matches the source for the DNS-323 kernel but it appears to have fatal bugs (at least for my environment). The cifs-fs 1.50 version seems to work although has minimal testing at this point.
-Jeff
Last edited by jdoering (2009-04-19 13:37:10)
Offline
Okay... got it working (UNTESTED WARNING) and some clarifications.
First the utility for smbfs is smbmount (not mount.smbfs); but I don't have that either. Second both smbmount and mount.cifs are just helpers (they handle password input better, etc). You don't need them to use smbfs and cifs respectively; regular mount alone will do. For troubleshooting I recommend using /bin/mount explicitly (rather than /ffp/bin/mount which may be first in your path). The FFP copy of mount comes from busybox and generally has less complete error messages than the standalone version.
Based on these clarifications I tried smbfs (even though it's old). That failed with a different issue that I didn't bother to track down. From dmesg:
smbfs: mount_data version 1919251317 is not supported smbfs: mount_data version 0 is not supported
There are various google hits on the error; but it wasn't clear what was wrong.
Back to cifs (which should be better anyway). I didn't check dmesg earlier when I tested this. I was getting messages like:
CIFS VFS: Length less than smb header size CIFS VFS: bad smb detected. Illegal length. mid=1 CIFS VFS: No response for cmd 114 mid 1 CIFS VFS: cifs_mount failed w/return code = -112
This resulted in the incorrect host down error. Turns out it's a bug in cifs: http://lists.samba.org/archive/linux-ci … 1010.html. The Linux 2.6.12.6 kernel includes version 1.35 of cifs. The issue may have been corrected in 1.38.
I grabbed the latest version of cifs (1.50c). Apparently they test back to kernel 2.6.14; I went ahead and compiled it against 2.6.12.6. I had to replace a few occurences of "mutex_lock" -> "down" and "mutex_unlock" with "up". It looks like those are in newer Linux kernels (strangely it looks like newer than 2.6.14 as well). It compiled cleanly.
Mapping my Windows (Vista) share worked fine after that. WARNING I haven't done much testing and this cifs is backported to an older kernel than they reportedly test against. See: http://linux-cifs.samba.org/
I've attached the new version of the kernel module. I guess the original one is useless if it fails against both XP and Vista (apparently MSFT does something funny in the packet sizes, maybe the original one would work with another samba server?).
-Jeff
Offline
jdoering wrote:
Okay... got it working (UNTESTED WARNING) and some clarifications.
First the utility for smbfs is smbmount (not mount.smbfs); but I don't have that either. Second both smbmount and mount.cifs are just helpers (they handle password input better, etc). You don't need them to use smbfs and cifs respectively; regular mount alone will do. For troubleshooting I recommend using /bin/mount explicitly (rather than /ffp/bin/mount which may be first in your path). The FFP copy of mount comes from busybox and generally has less complete error messages than the standalone version.
Based on these clarifications I tried smbfs (even though it's old). That failed with a different issue that I didn't bother to track down. From dmesg:Code:
smbfs: mount_data version 1919251317 is not supported smbfs: mount_data version 0 is not supportedThere are various google hits on the error; but it wasn't clear what was wrong.
Back to cifs (which should be better anyway). I didn't check dmesg earlier when I tested this. I was getting messages like:Code:
CIFS VFS: Length less than smb header size CIFS VFS: bad smb detected. Illegal length. mid=1 CIFS VFS: No response for cmd 114 mid 1 CIFS VFS: cifs_mount failed w/return code = -112This resulted in the incorrect host down error. Turns out it's a bug in cifs: http://lists.samba.org/archive/linux-ci … 1010.html. The Linux 2.6.12.6 kernel includes version 1.35 of cifs. The issue may have been corrected in 1.38.
I grabbed the latest version of cifs (1.50c). Apparently they test back to kernel 2.6.14; I went ahead and compiled it against 2.6.12.6. I had to replace a few occurences of "mutex_lock" -> "down" and "mutex_unlock" with "up". It looks like those are in newer Linux kernels (strangely it looks like newer than 2.6.14 as well). It compiled cleanly.
Mapping my Windows (Vista) share worked fine after that. WARNING I haven't done much testing and this cifs is backported to an older kernel than they reportedly test against. See: http://linux-cifs.samba.org/
I've attached the new version of the kernel module. I guess the original one is useless if it fails against both XP and Vista (apparently MSFT does something funny in the packet sizes, maybe the original one would work with another samba server?).
-Jeff
wait2...a little bit over my head...too fast.
how to use this cifs.ko? where to keep this file and how to use it? is it the same as:
mount -t cifs -o username=<name>,password=<passwd> //sambashare /mountpoint
Offline
Keep it where you like; either somewhere simple (similiar to DNS-323 firmware pattern for kernel modules):
"/ffp/lib/modules/cifs.1.50.ko"
or a highly structured location (like Debian uses):
"/ffp/lib/modules/2.6.12.6-arm1/kernel/fs/cifs/cifs.1.50.ko"
Load it with "insmod <PATH>/cifs.1.50.ko". You can also rename the kernel module to the standard "cifs.ko" if you like. I kept the name descriptive here so those downloading it would know what it is. Keep in mind that cifs-fs code is probably very stable; but that this backport to 2.6.12.6 is untested... I'll use it but I'm a gambler.
Your mount example looks right. You can also get "mount.cifs" from the FFP samba package if you want. It will handle prompting for the password (instead of passing it on the command line) and probably other convenience options.
-Jeff
Offline
Still unsuccessful,
root@nashawa:/mnt/usb/ffp/home/root# insmod /mnt/HD_a2/cifs.ko root@nashawa:/mnt/usb/ffp/home/root# mkdir /mnt/HD_a2/m1201 root@nashawa:/mnt/usb/ffp/home/root# mount -t cifs -o //192.168.1.100/m1201 /mnt/HD_a2/m1201/ mount: can't find /mnt/HD_a2/m1201/ in /etc/fstab
Any idea?
Last edited by iazmin (2009-04-21 04:01:54)
Offline
-o ?
Offline
Mijzelf wrote:
-o ?
If I omit the -o, this will be the output:
root@nashawa:/mnt/usb/ffp/start# mkdir /mnt/HD_a2/m1201 root@nashawa:/mnt/usb/ffp/start# mount -t cifs -o username=XXX,password=xxxxx //192.168.1.101/m1201 /mnt/HD_a2/m1201/ mount: mounting \\192.168.1.101\m1201 on /mnt/HD_a2/m1201/ failed: Not a directory root@nashawa:/mnt/usb/ffp/start# mount -t cifs username=XXX,password=xxxxx //192.168.1.101/m1201 /mnt/HD_a2/m1201/ BusyBox v1.12.1 (2008-09-29 20:38:04 CEST) multi-call binary Usage: mount [flags] DEVICE NODE [-o options,more-options] Mount a filesystem. Filesystem autodetection requires /proc be mounted. Options: -a Mount all filesystems in fstab -f don't mount -r Read-only mount -t fs-type Filesystem type -w Read-write mount (default) -o option: loop Ignored (loop devices are autodetected) [a]sync Writes are asynchronous / synchronous [no]atime Disable / enable updates to inode access times [no]diratime Disable / enable atime updates to directories [no]relatime Disable / enable atime updates relative to modification time [no]dev Allow use of special device files / disallow them [no]exec Allow use of executable files / disallow them [no]suid Allow set-user-id-root programs / disallow them [r]shared Convert [recursively] to a shared subtree [r]slave Convert [recursively] to a slave subtree [r]private Convert [recursively] to a private subtree [un]bindable Make mount point [un]able to be bind mounted bind Bind a directory to an additional location move Relocate an existing mount point remount Remount a mounted filesystem, changing its flags ro/rw Mount for read-only / read-write There are EVEN MORE flags that are specific to each filesystem You'll have to see the written documentation for those filesystems
Last edited by iazmin (2009-05-05 18:47:07)
Offline
Not sure what to tell you. Mijzelf's comment was a reaction to your earlier example where you used "-o" with no argument (you followed it with the remote path). Your example that follows -o with username/password looks correct.
Of course you final try with username and password but no -o won't work.
All I can suggest is trying different combinations with regard to creation of the local directory, what permissions it has, etc. Try a local directory that's not mounted on your disk (on the RAMFS instead). Voodoo, yes, but sometimes that's the best way to figure out a pattern of what does work versus what doesn't when trying to pinpoint a strange error. Try lots of different combinations (different directory names, etc). But there's no point in trying with invalid syntax to mount; that will fail every time.
I'll repeat my earlier suggestion to try /bin/mount instead of FFP mount (which is in your path and really provided by busybox). The native mount provides more detailed error messages in some cases compared to the busybox version. You might check dmesg as well, just in case something is showing up there when you try your mount command.
-Jeff
Offline
jdoering wrote:
Not sure what to tell you. Mijzelf's comment was a reaction to your earlier example where you used "-o" with no argument (you followed it with the remote path). Your example that follows -o with username/password looks correct.
Of course you final try with username and password but no -o won't work.
All I can suggest is trying different combinations with regard to creation of the local directory, what permissions it has, etc. Try a local directory that's not mounted on your disk (on the RAMFS instead). Voodoo, yes, but sometimes that's the best way to figure out a pattern of what does work versus what doesn't when trying to pinpoint a strange error. Try lots of different combinations (different directory names, etc). But there's no point in trying with invalid syntax to mount; that will fail every time.
I'll repeat my earlier suggestion to try /bin/mount instead of FFP mount (which is in your path and really provided by busybox). The native mount provides more detailed error messages in some cases compared to the busybox version. You might check dmesg as well, just in case something is showing up there when you try your mount command.
-Jeff
So far still not successful
Offline
There is something that is worth to share although still unsuccessful. The mount goes fine without any error message when I use "\" instead of forward slash "/" for the folder of the remote server //. the problem is there is nothing in the mounted folder although I already dumped some files in the source folder. It is empty. The result is:
root@nashawa:/mnt/usb/iogear#insmod /mnt/HD_a2/cifs.ko root@nashawa:/mnt/usb/iogear# mount -t cifs -o username=xxxx,password=xxx //192.168.1.101\usb1_d1p1 /mnt/usb/iogear root@nashawa:/mnt/usb/iogear# ls -al drwxr-xr-x 2 root root 4096 May 7 22:15 . drwxrwxrwx 5 root root 4096 May 7 22:15 .. root@nashawa:/mnt/usb/iogear#
Any idea?
Last edited by iazmin (2009-05-07 17:33:11)
Offline
Don't use busybox mount (as I suggested before). Use /bin/mount explicitly.
I just tried your experiment. That backslash doesn't work; the busybox mount just fails silently. Check the contents of /proc/mounts. The "real" mount reports a much more useful error:
mount: wrong fs type, bad option, bad superblock on //192.168.0.70C,
missing codepage or other error
In some cases useful info is found in syslog - try
dmesg | tail or so
What error does the real mount give when you use the correct syntax (forward slashes, etc)? Does if vary if you try to connect to a phony share (same-ip + phony share name, bogus ip, etc)? Try mount points on ramfs (/mnt/mntpoint) instead of real disks. No magic; just permutations to try and flush out the real problem.
I did replicate the "resource temporarily unavailable" issue. But I had existing (old) mounts working. When I unmounted all of them and tried again it started working. And that error occurred even when I gave bogus remote shares; so I think cifs was in some "funny" state.
-Jeff
Offline
If I use /bin/mount:
root@=:/mnt/usb/ffp/home/root# /bin/mount -t cifs -o username=NAME,password=XXXX //192.168.1.101/usb1_d1p1 /mnt/cifs/ mount: Not a directory
If I just use mount:
root@=:/mnt/usb/ffp/home/root# mount -t cifs -o username=NAME,password=XXXXXX //192.168.1.101/usb1_d1p1 /mnt/cifs mount: mounting \\192.168.1.101\usb1_d1p1 on /mnt/cifs failed: Not a directory
My check from here http://ou800doc.caldera.com/en/NET_nfs/ … _msgs.html shows that if such "Not a directory" there is something wrong with the local directory. So I try to chmod 777 the folder but this the error persist.
Offline
cifs.1.50.ko worked fine for me! I was able to mount a share on WindowsXP on DNS-323. I was getting infamous file path/name is too long error when I using windows explorer on XP to copy my files. Now I can use cp command on DNS-323. Thanks for the great work! All I did was below.
insmod cifs.1.50.ko
mkdir /mnt/sharename
mount -t cifs //windowspcname/sharename /mnt/sharename -o username=windows-login-name,password=windows-login-password
Offline
Yes, it also now work for me using cifs.1.50.ko! I think my failure last time was because I use the old cifs.ko
anyway I solved my problem and I can connect to any other samba drive in the network.
Thank you to kennethxu!
Offline
annyway how to unmount the drive?
Offline
to unmount use the following command:
umount -t cifs //windowspcname/sharename /mnt/sharename
Offline
when unmount, you only need to specify your mount dir:
umount /mnt/sharename
Offline
Not related to mounting but I do have a problem with charset on windows share. I couldn't get utf8 to work!
# mount -t cifs //windowspcname/sharename /mnt/sharename -o username=windows-login-name,password=windows-login-password,iocharset=utf8 mount: mounting \\windowspcname\sharename on /mnt/sharename failed: Can not access a needed shared library # dmesg CIFS VFS: CIFS mount error: iocharset utf8 not found
I searched Google and found that I'm missing nls_utf8.ko. I'm kind of new and not sure how to compile one myself so would anybody kindly help to upload one?
Offline