Through KDE's Konqueror, I am attempting to view the directories and files on a Cisco NSLU2. I'm using smb://hostname This is not a permissions issue, as I am connecting as Admin, which is equivalent to root.

The NSLU2 is running the latest image from Cisco. The USB disk on the Samba NSLU2 is unfortunately formatted with fat32. I suspect this is the problem. I can still connect normally to the NSLU2 from other systems running XP. And I can connect normally to Server 2003 shares using smb and Konqueror.

I am running a generic Slackware 2.6.27.7-SMP image with full packages install.

Errors I get -
While the directory is loading, I get numerous errors such as "file does not exist smb://admin@qbook/PRGM" which is actually a folder "/PRGMS".
All files and folders show zero bytes
All subdirectories that do show available show empty

Does the Client need to have some version of FAT support loaded when connecting VIA Samba? Which one?

Is there a way to list which file systems are supported?

Thanks

This kernel does not support the smbfs file system. Try mounting the share using the cifs filesystem. The cifs file system now supplies the functionality of the deprecated smbfs file system.

This link may also offer some ideas.
http://groups.google.com.au/group/al...0631796c654ced

I saw this yesterday, thought about it, and I don't think this is the same issue. The thread you listed refers to the access protocol lanman, which is still supported in Windows, but is considered deprecated. It is connecting on port 139, which is Netbios.

I'm able to connect and authenticate, but my Linux system does not appear to be properly interpreting the remote file system. All my Windows to Cisco work fine, and all my Linux to Windows works fine, but my Linux to Cisco, which runs Samba on Linux connects but does not seem to interpret the directory data properly.

So I'm still looking.

Thanks.

Yes, I have seen this problem when attempting to remotely access a Samba share from a Windows98 machine mounted on a server running Slackware 12.2 with the 2.6.27.7-smp kernel. From the local server, I can see all the files but the inode count is incorrect.
All the other shares from Windows2000 and WindowsXP machines are fine.

The problem was not present prior to upgrade from 12.1 to 12.2, when support for smbfs was removed.

The problem is partly due to a bug in CIFS support for legacy file systems. (I did actually write a little patch for inode.c that partly resolved the problem). I am unsure of the status of the bug in kernels later than 2.6.27.7. I just diff'd the kernel source for inode.c in 2.6.29.6 against my patched file and note quite a few differences. Obviously time for me to do some more testing!

Ok, now I understand. You threw my thinking off with the windows98 reference. Thank you.

Hi
I have got the same problem, but I'm using Debian. Could you please tell what should I exactly do to solve this?
I can't figure out how it was solved in here.

Regards
zdun

cifs = Common Internet File System.
smbfs = Server Message Block File System

Before you could just browse a remote file system in X on demand with smbfs. However, smbfs is not supported starting with Linux Kernel 2.6.27. The X applications have not caught up with this change. So for now you have to manually mount the remote system into your local filesystem tree first with cifs.

mount -t cifs //tcp-name-of-server/sharename /mnt/some-name -o user=username,pass=password,sec=(ntlm or lanman),servern=NETBIOS_NAME

For the security, use ntlm, which is what I'm using. But if that does not work, you may have to use lanman. You won't need the Password field unless you are adding this to your initialization script. The TCP/IP Server name is not the same as the "servern" field. The TCP/IP name is similar to "www.fred.com" where the "servern" is the WINS same, or Netbios name.

Hopefully the X Applications will catch up to this change soon and bring back the ease we once enjoyed connecting to our Cisco NAS devices.

Today I upgraded the kernel from 2.6.27.7-smp to 2.6.27.31-smp on the server that I have mounting a Win98 share. I have not fully investigated the results of the kernel change, but it appears that the problem persists.

I was just getting ready to do an update, so I'm glad you mentioned that.

Clarification! You need to enclose the share name in quotes if it contains any spaces. The default naming on the NSLU2 uses share names of "/Disk 1" and "/Disk 2". This is not mentioned in the man page. Also you must use // and not \\, even though the mount help screen says you can use either.

Example:
mount -t cifs "//tcp-name-of-server/sharename" /mnt/some-name -o user=username,sec=ntlm,servern=NETBIOS_NAME,ip=192.168.2.101

The man page is mount.cifs

Suncoast thank you very much, the access to the disk is now working properly, despite the fact that I must add the permissions to the files, because I can't access to them, but that is not a problem (although it will take some time).

Now I must focus on having the wifi connection speeded up, because the slowness of disc is killing me.

Thanks very much again ;]

Unfortunately I can't access to the files, I've typed chmod -R +rwx /mnt/hdd1 but It doesn't seem to be the problem of permissions.

The NSLU2 uses either a Fat32 or NTFS file system. So I don't think you can apply that logic to those files, although I've never tried. And you set permissions for folders and drives through the NSLU2 Web Interface, not from the Linux CLI.