[RESOLVED] Strangeness with ls on mounted Samba share

houn · 2010-02-09 15:40:21

I've been all over the 'net, and I can't find anything to even point me in the right direction, so hopefully someone here can help. I just installed Arch on my workstation, largely without issue, but there's one thing that's rather troubling. For work, I spend a lot of time working with files on a Windows Share. I can mount the share, read and write files without issue, everything seems to be working, but ls output is completely garbage.

What's in the directory:
file1
file2
file3
file with spaces

ls Output:

$ ls -l /media/athens/siteconfig/houn_test
ls: cannot access /media/athens/siteconfig/houn_test/P: No such file or directory
ls: cannot access /media/athens/siteconfig/houn_test/l: No such file or directory
ls: cannot access /media/athens/siteconfig/houn_test/le with spacesX: No such file or directory
ls: cannot access /media/athens/siteconfig/houn_test/le1: No such file or directory
ls: cannot access /media/athens/siteconfig/houn_test/le2: No such file or directory
ls: cannot access /media/athens/siteconfig/houn_test/le3: No such file or directory
total 0
d????????? ? ? ? ?            ? l
-????????? ? ? ? ?            ? le1
-????????? ? ? ? ?            ? le2
-????????? ? ? ? ?            ? le3
-????????? ? ? ? ?            ? le with spacesX
d????????? ? ? ? ?            ? P

/etc/fstab:

//athens/SiteConfig     /media/athens/siteconfig  cifs  credentials=/home/houn/.smbpasswd,dir_mode=0777,file_mode=0777,isocharset=utf8,nounix 0 0

I've tried several different options in the fstab. In addition, the houn_test directory and the files inside were created while the share was mounted with md and touch. I can work with them fine, so long as I reference them directly by name. Of course, I won't always know the name of every file in a directory I might need to access, so...

Any ideas? I'm stumped on this.

*edit* Additional Information:

 echo /media/athens/siteconfig/houn_test/*
/media/athens/siteconfig/houn_test/l /media/athens/siteconfig/houn_test/le1 /media/athens/siteconfig/houn_test/le2 /media/athens/siteconfig/houn_test/le3 /media/athens/siteconfig/houn_test/le with spacesX /media/athens/siteconfig/houn_test/P

Last edited by houn (2010-02-14 14:27:32)

hw-tph · 2010-02-09 17:10:09

Your fstab specifies isocharset. You probably want to change that to iocharset instead, or try mounting the directory without specifying the character set conversion altogether.

houn · 2010-02-09 17:31:40

I fixed that, and have tried iocharset=utf8 and iocharset=iso8859-1. No change in behavior. Also tried it with no iocharset option.

houn · 2010-02-09 18:55:30

More curious. I can access the share with smbclient and get no issues listing files/directories there. What is the difference, I wonder?

skanky · 2010-02-09 21:01:19

Try removing the nounix option as I believe that has something to do with file information - it's not in my man page for mount.cifs though.

houn · 2010-02-09 21:26:15

Already done, no change. Also tried the sfu option. Nothing else is looking relvant.

Taking tcpdumps of the traffic both with the Arch box and with a Windows box accessing the share, the request and response seems nearly identical, but the Arch box seems to be interpreting the response from the server wrong. Also, I got another guy at the office here to test with Ubuntu, and he's getting the same thing. Not sure if IT changed something on the file server, or if something's broken in newer mount.cifs versions.

skanky · 2010-02-09 22:05:53

I'd have a check with the people running the server. Seems to be the common denominator.

houn · 2010-02-14 14:27:17

Found the issue. Adding "noserverino" to the mount options fixed it. Strange times.

hw-tph · 2010-02-14 20:06:50

Thanks for letting us know the solution to your problem.

skanky · 2010-02-14 22:17:01

Yes, thanks for that. Here's the manual entry:

 serverino
           Use inode numbers (unique persistent file identifiers) returned by the server instead of
           automatically generating temporary inode numbers on the client. Although server inode
           numbers make it easier to spot hardlinked files (as they will have the same inode numbers)
           and inode numbers may be persistent (which is userful for some sofware), the server does
           not guarantee that the inode numbers are unique if multiple server side mounts are
           exported under a single share (since inode numbers on the servers might not be unique if
           multiple filesystems are mounted under the same shared higher level directory). Note that
           not all servers support returning server inode numbers, although those that support the
           CIFS Unix Extensions, and Windows 2000 and later servers typically do support this
           (although not necessarily on every local server filesystem). Parameter has no effect if
           the server lacks support for returning inode numbers or equivalent.
           
       noserverino
           client generates inode numbers (rather than using the actual one from the server) by
           default.

Suggests the server is not support returning inode numbers?

Arch Linux

#1 2010-02-09 15:40:21

[RESOLVED] Strangeness with ls on mounted Samba share

#2 2010-02-09 17:10:09

Re: [RESOLVED] Strangeness with ls on mounted Samba share

#3 2010-02-09 17:31:40

Re: [RESOLVED] Strangeness with ls on mounted Samba share

#4 2010-02-09 18:55:30

Re: [RESOLVED] Strangeness with ls on mounted Samba share

#5 2010-02-09 21:01:19

Re: [RESOLVED] Strangeness with ls on mounted Samba share

#6 2010-02-09 21:26:15

Re: [RESOLVED] Strangeness with ls on mounted Samba share

#7 2010-02-09 22:05:53

Re: [RESOLVED] Strangeness with ls on mounted Samba share

#8 2010-02-14 14:27:17

Re: [RESOLVED] Strangeness with ls on mounted Samba share

#9 2010-02-14 20:06:50

Re: [RESOLVED] Strangeness with ls on mounted Samba share

#10 2010-02-14 22:17:01

Re: [RESOLVED] Strangeness with ls on mounted Samba share

Board footer