2.6.31 - Can't see files in CIFS-mounted directories

Hi,

same problems with 2.6.31-5 and 2.6.31-6.

Additions:

4a) i can 'cd' into one existing, but unvisible directory

4b) i can also copy existing, but unvisible files from 'mountdir' to _any_ other directory.

ciao

I confirm the same behaviour:

1) With kernel 2.6.28-15 the files show up just fine
2) With kernel 2.6.31-6 the files do not appear

(fwiw, I'm using kernel 2.6.31-6 on Jaunty, from following the instructions for X/KernelModeSetting)

Hi,

same problems with kernel 2.6.31-7.18 and smbfs 3.4.0-3.

ciao

Hi,

... and also with kernel 2.6.31-8.28.

ciao

Hi,

guess, what happens with kernel 2.6.31-9.20?

ok, that's boring - so i will announce, if this cifs-mount will work again.

If ever...

ciao

Same here:

Macbook 2,1
Karmic, kernel 2.6.31-3-generic
Samba 3.4.0
"NAS" disk is a shared Apple Time Capsule (perfectly accesible from OpenSuse 11 & Jaunty).
Tried mounting with "smbfs" and "cifs" filesystems.

Another test I tried with sucess is to access the shared disk with "smbclient", and in that scenario I CAN SEE THE FILES with no problem at all. For me it seems then that the mounting of the resource is the problem and discards any problem with the Samba version.

also a problem in Karmic, vmlinuz-2.6.31-11-generic;
cifs-mounted NAS, using ls i can only see about 10% of contents from a specific directory.

Hi,

For those who are having problems can you do the following:

 echo 1 > /proc/fs/cifs/cifsFYI
 dmesg -c
issue command like
 ls -l /<mount point>
and then send dmesg log.

And you can repeat above after unmounting the share with a slight change i.e.
issue a command like
 ls -l /<mount point>/<a_specific_file_name_that_you_know_exists>
and then send dmesg log.

You may also want to issue command
 echo 1 > /proc/fs/cifs/traceSMB
besides the above listed echo command

Regards
chuck

I've attached script output containing the information that you
requested. I can see the share fine if I mount it using Places >
"Connect to Server..." and can even cd around and list things through
~/.gvfs:

$ ls ~/.gvfs/public\ on\ 192.168.6.33/
Music/ Software/ Video/

$ ls ~/.gvfs/public\ on\ 192.168.6.33/Music/
CDs/ LIVE/ Pgh_Punk/ Punk 45s/ Random/

Feel free to contact me directly if you'd like additional info, output,
etc.

  Bill

On Sun, 2009-10-04 at 20:22 +0000, Chuck Short wrote:
> Hi,
>
> For those who are having problems can you do the following:
>
> echo 1 > /proc/fs/cifs/cifsFYI
> dmesg -c
> issue command like
> ls -l /<mount point>
> and then send dmesg log.
>
> And you can repeat above after unmounting the share with a slight change i.e.
> issue a command like
> ls -l /<mount point>/<a_specific_file_name_that_you_know_exists>
> and then send dmesg log.
>
> You may also want to issue command
> echo 1 > /proc/fs/cifs/traceSMB
> besides the above listed echo command
>
> Regards
> chuck
>
>
> ** Changed in: samba (Ubuntu)
> Status: New => Incomplete
>
> ** Changed in: samba (Ubuntu)
> Assignee: (unassigned) => Chuck Short (zulcss)
>

BTW, I'm running the following kernel:

Linux u910 2.6.31-11-generic #38-Ubuntu SMP Fri Oct 2 11:06:40 UTC 2009 x86_64 GNU/Linux

I'm running up-to-date karmic code, last updated this morning. I can also mount and explore this share using smbclient, with no problems. It's only via a vanilla CIFS mount that I seem to have problems seeing the contents of the share.

Works with smbclient, so not an issue in samba.

Here are 3 log files containing the requested information for this bug:

1) output with: echo 1 > /proc/fs/cifs/cifsFYI

2) output with: echo 1 > /proc/fs/cifs/cifsFYI AND echo 1 > /proc/fs/cifs/traceSMB

3) output for the working commands using smbclient

ciao

in my last comment i said that smbclient is working. But the dates in 'output.txt' are rather strange. Connecting from Windows (sorry) gives the real dates, as shown in the attached file.

I don't if this is an important fact, but at least it is a surprising result.

ciao

Hi, "bad" (good?) news:

After formatting my root partition, installing using 9.04 CDROM and then apt-upgrading to 9.10, the problem is gone. I can clearly see the contents on Apple Time Capsule as in 8.10 and before.

My "working" versions:

  linux-image-2.6.31-11-generic 2.6.31-11.38
  samba 3.4.0-3ubuntu5

I concur, this is the same behaviour I am seeing with a mythbuntu 9.10 beta system connecting to an apple time capsule.

About Apple Time Capsules: note that you need Time Capsule Firmware 7.4.2 to run correctly with CIFS (bug 343357)
Is everyone affected on this bug a Time capsule user ?
If not, is it fixed for non-Time-Capsule users ?

Yes, I am running Time Capsule Fireware 7.4.2 and I can connect to the share with a Jaunty based laptop using identical settings.

Based on @Pablo's comments could you confirm the kernel version in Karmic which is showing the issue, and if it is older than 2.6.31-11.38 could you update to the latest kernel (.39 or later) and retest. Please report both success or failure here. With failure please include output requested by Chuck in comment #8.

I am still seeing this problem, and I am not trying to mount a Time Capsule device. The NAS device that I am mounting is an Addonics NASU2 NAS Adapter, which mounted correctly under 8.10 and 9.04. I can access its contents successfully via gvfs and smbclient but not when mounted:

$ cd ~/.gvfs
$ ls
public on 192.168.6.33
$ ls public\ on\ 192.168.6.33
Music Software Video

# grep NAS /etc/fstab
//192.168.6.33/public /mnt/NAS cifs user=WVH/wvh%password,uid=1000,noauto 0 0
# smbclient //192.168.6.33/public -W WVH -U wvh
Enter wvh's password:
Domain=[R] OS=[R] Server=[R]
smb: \> ls
  . D 0 Fri Jan 30 08:35:10 2009
  .. D 0 Fri Jan 30 08:35:10 2009
  Music D 0 Fri Jan 30 08:41:18 2009
  Video D 0 Fri Jan 30 10:29:38 2009
  Software D 0 Fri Jan 30 18:55:20 2009

  59602 blocks of size 16777216. 6804 blocks available
smb: \> quit
# mount /mnt/NAS
# ls -al /mnt/NAS
total 4
drwxr-xr-x 1 wvh root 0 2009-03-01 00:58 .
drwxr-xr-x 29 root root 4096 2009-07-08 12:20 ..

I can successfully mount this device from a netbook running Jaunty, using the same /etc/fstab entry.

As shown in comment #10, I am running 2.6.31-11.38. This is the kernel version from which I submitted the output previously requested by Chuck, and attached to comment #9.

smbclient as well as mount is failing for me , source machine is mythbuntu system running 9.10 beta , the NAS is a time capsule with the latest firmware (7.4.2). The share is visible from a 9.04 laptop.

smbclient :

root@tv:~# smbclient //time/share -U mythtv
Enter mythtv's password:
Domain=[hiddennet] OS=[Apple Base Station] Server=[CIFS 4.32]
smb: \> SMBecho failed. Maybe server has closed the connection

fstab :

//192.168.0.6/share/Movies /mnt/movies smbfs rw,user=mythtv,pass=mythtv,iocharset=utf8 0 0

mount :

root@tv:~# mount /mnt/movies
root@tv:~# ls /mnt/movies/
root@tv:~#

logs from #8 attached.

root@tv:~# uname -a
Linux tv 2.6.31-12-generic #40-Ubuntu SMP Wed Oct 7 04:13:44 UTC 2009 x86_64 GNU/Linux

root@tv:~# dpkg -l | grep smb
ii libsmbclient 2:3.4.0-3ubuntu5 shared library for communication with SMB/CI
ii smbclient 2:3.4.0-3ubuntu5 command-line SMB/CIFS clients for Unix
ii smbfs 2:3.4.0-3ubuntu5 Samba file system utilities

root@tv:~# dpkg -l | grep linux-image
ii linux-image-2.6.31-11-generic 2.6.31-11.38 Linux kernel image for version 2.6.31 on x86
ii linux-image-2.6.31-12-generic 2.6.31-12.40 Linux kernel image for version 2.6.31 on x86
ii linux-image-generic 2.6.31.12.23 Generic Linux kernel image
?field.comment=smbclient as well as mount is failing for me , source machine is mythbuntu system running 9.10 beta , the NAS is a time capsule with the latest firmware (7.4.2). The share is visible from a 9.04 laptop.

smbclient :

root@tv:~# smbclient //time/share -U mythtv
Enter mythtv's password:
Domain=[hiddennet] OS=[Apple Base Station] Server=[CIFS 4.32]
smb: \> SMBecho failed. Maybe server has closed the connection

fstab :

//192.168.0.6/share/Movies /mnt/movies smbfs rw,user=mythtv,pass=mythtv,iocharset=utf8 0 0

mount :

root@tv:~# mount /mnt/movies
root@tv:~# ls /mnt/movies/
root@tv:~#

logs from #8 attached.

root@tv:~# uname -a
Linux tv 2.6.31-12-generic #40-Ubuntu SMP Wed Oct 7 04:13:44 UTC 2009 x86_64 GNU/Linux

root@tv:~# dpkg -l | grep smb
ii libsmbclient 2:3.4.0-3ubuntu5 shared library for communication with SMB/CI
ii smbclient 2:3.4.0-3ubuntu5 command-line SMB/CIFS clients for Unix
ii smbfs 2:3.4.0-3ubuntu5 Samba file system utilities

root@tv:~# dpkg -l | grep linux-image
ii linux-image-2.6.31-11-generic 2.6.31-11.38 Linux kernel image for version 2.6.31 on x86
ii linux-image-2.6.31-12-generic 2.6.31-12.40 Linux kernel image for version 2.6.31 on x86
ii linux-image-generic 2.6.31.12.23 Generic Linux kernel image

Adam: if smbclient fails, then it's not the same bug as merlin, wvh and Pablo... please open a separate bug.

Nothing has changed with kernel 2.6.31-12.40 (see comment #12):

Here are 3 new log files containing the requested information for this bug:
Karmic 9.10 (uptodate), AMD64, KDE 4.3.2
kernel: Linux merlin 2.6.31-12-generic #40-Ubuntu SMP Wed Oct 7 04:13:44 UTC 2009 x86_64 GNU/Linux

1) output with: echo 1 > /proc/fs/cifs/cifsFYI

2) output with: echo 1 > /proc/fs/cifs/cifsFYI AND echo 1 > /proc/fs/cifs/traceSMB

3) output for the working commands using smbclient

ciao

I have Time Capsule 7.4.2 and it also affects me.

Everything was ok before Karmic.

The smbclient failing is probably a separate bug and I will open another bug for that ( Bug #445595 ). The mount failure is the same bug as this. I have been able to compile smbclient from the latest samba source and the issue is not there.

closing the samba task, this bug is about a kernel mount issue.

Can those running a NAS other than the Apple Time Capsule clarify what NAS it is they're using, and (if possible) what CIFS implementation it's based on?

Could someone who's experiencing this problem try getting a packet capture of the network activity (tcpdump -i <network_interface> -n -s 1500 -w broken-cifs.pcap 'host <server_ip> and (port 139 or port 445)')? This bug may be easier to isolate from the protocol side.

Hi,

ok, i have done, what you wanted in comment #27:

1) The NAS is a FANTEC LD-H35NSU2

see: http://www.fan-tec.com/html/en/2/artId/__2200/gid/__19909019903590/article.html

There is also an user manual (PDF datasheet) on this side, where you can see, what small changes in the samba configuration of this NAS are possible. Of course the latest firmware of this NAS is installed. But it is impossible to get the CIFS implementation of the NAS or change some other settings.

2) The tcpdump output is attached. I also put the given commands in another file. And i also added the output, which i wanted to get. There is no problem to get this f.e. from jaunty (see comment #1).

And this is really interesting: although i can't interpret the tcp output, i see great parts of the invisible directory listing. That's why i added two real directory listing from another system.

ciao

I can also confirm this bug and notice the following behaviour:
I mounted a Iomega NAS over a wireless network via cifs with the
following line in /etc/fstab:

//192.168.1.20/User /home/user/NAS cifs
iocharset=utf8,file_mode=0777,dir_mode=0777,noperm,credentials=/home/user/.smbcredentials,uid=1000
0 0

I can browse to a directory I know with cd, but ls returns no output.
However, when I copy a file to my computer, it works fine, but if I copy
another file it just creates a new file with the contents of the first
file that was copied. I had to umount/mount every time to get all my
images. Example of what I did:

Result: two identical images:
sudo mount -a
cd "NAS/Drive D (D) on ENTRESOL/Work User/Pictures/2008/20081119 Various
Pictures"
cp DSC03726.JPG ~/Desktop/gs
cp DSC03727.JPG ~/Desktop/gs

Result: two different images:
cd ~
sudo umount NAS
sudo mount -a
cd "NAS/Drive D (D) on ENTRESOL/Work User/Pictures/2008/20081119 Various
Pictures"
cp DSC03726.JPG ~/Desktop/gs
cd ~
sudo umount NAS
sudo mount -a
cd "NAS/Drive D (D) on ENTRESOL/Work User/Pictures/2008/20081119 Various
Pictures"
cp DSC03727.JPG ~/Desktop/gs

Hope this helps.

Oh yes, that's true for me too... another surprising result:

i have copied two invisible, but existing mp3 files to my home directory and now there are two different new entries. But when i play the music, i must recognize that the same song is played. And this is the first one, which was copied.

@Steve: feel free to ask for some other logs ...

ciao

Addition to comment #30:

getting these two mp3 files with smbclient creates two different songs in my home directory. So this is definitely not a problem of samba...

... and this could be a critical bug for everyone now, as cifs changes files.

ciao

Thanks for the network trace.

Notable differences between this trace and a cifs mount trace to a recent version of Samba, in the negprot_response:

SHARE security mode vs. USER security mode
capabilities field of 0x0080f3fd vs. 0x008023fd, which means the server doesn't support large read/write or dfs.

The server in the trace also doesn't support the QUERY_FS_INFO Device Info call, and indicates no support for case sensitive searching in the response to QUERY_FS_INFO Attribute Info.

I don't notice any discrepancies at first glance in the data returned in response to a file listing query.

The NAS that I am using is an Addonics NASU2 NAS adapter with a 1 GB disk attached. This worked fine under Ubuntu 9.04 and 8.10. I'm attaching two output files from the tcpdump command that you requested - the file broken-cifs-9.10-wvh.pcap is packet capture info from my fully updated 9.10 system (uname -a output: Linux u910.vonhagen.org 2.6.31-13-generic #44-Ubuntu SMP Sat Oct 10 15:27:14 UTC 2009 x86_64 GNU/Linux). The commands that I executed during this capture session were:

mount /mnt/NAS
ls /mnt/NAS
cd /mnt/NAS/Music
ls

No files or directories were shown by either of the ls commands. The Music directory was a directory that I knew to be there. My /etc/fstab entry for this device is:

//192.168.6.33/public /mnt/NAS cifs user=WVH/wvh%password,uid=1000,noauto 0 0

The second tcpdump output file (broken-cifs-9.04-wvh.pcap) was produced by using the same tcpdump command on a netbook running Ubuntu 9.04. I executed the same commands after initiating the packet capture. The /etc/fstab entry is identical. That system (32 bit) is running kernel version 2.6.28-15, and is wireless. After the mount on that system, I can see all files, directories, etc - just like the good old days!

Hope this helps. I'll be glad to capture any other data that you'd like, as well as any other side-by-side comparisons.

Hmmm - I wasn't able to attach multiple files for some reason., I've attached the 9.04 output to this comment. See previous comment for details.

Looking at the two traces, there seems to be a different argument to FIND_FIRST2 for listing files. In the working case it is using
Level of Interest: Find File Directory Info (257) while in the non-working case it uses Level of Interest: Unknown (261). This other number seems to have been present for a while but started to be used recently. Maybe related to this, could you try to mount using "nolinux" as an additional mount option when doing the cifs mount, and check whether this would return files.

Addition to comments #30/31/35:

nor mount option nounix or nolinux or disabling LinuxExtensions with 'echo 0 > /proc/fs/cifs/LinuxExtensionsEnabled' changes anything: no files are visible.

ciao

Addition to comment #28:

wvh has had a good idea in comment #33, so i also added the network trace of a working cifs mount, which i have done under jaunty (kernel 2.6.28-11): all files are visible, no problems at all.

Perhaps you will find a difference to the trace of the broken cifs in comment #28, which was done under karmic. Hope this helps...

ciao

Trying to analyze (better compare) the broken cifs network trace from comment #28 (karmic) and the working cifs trace from comment #37 (jaunty) with wireshark, i see that

- the first FIND_FIRST2 request with pattern '\*' gives all entries (working cifs with jaunty)

- wireshark doesn't show any entries for this first FIND_FIRST2 request with the broken cifs of karmic, although all these entries are present in the trace.

Is this helpful for someone, who is able to interpret the trace?

ciao

Just as an additional data point: could you try mounting with the "noserverino" option, and let us know if that fixes the problem?

Yes! Adding this mount option enables me to see files and directories after a mount, I was also able to read and write successfully to the mounted filesystem. I'm not clear why having the client generate inode numbers corrects the problem or is necessary, but it's at least a workaround. Thanks for the suggestion.

Chasing up with some samba folks, will report back with any answers. Will also see if I can get a wireshark dissector that understands the SMB_FIND_FILE_ID_FULL_DIR_INFO responses.

In the meantime, we have a small workaround.

Lowering the bug importance based on the availability of a workaround.

I can imagine why mounting with serverino could made a difference. If the server has broken support for returning serverinode numbers (or at least for the specific findfirst level that returns search information + server inode numbers) then things like resume keys could get messed up which would make it hard to parse the response, or could cause us to not find the next entry in the search response if the directory has more than a certain number of files (perhaps 50).

To help the tracing it may be helpful to uncomment the tracing call (in fs/cifs/readdir.c)

/* cFYI(1, ("filldir on %s",pqst->name)); */

or to add a debug entry before the call to filldir (in the same file fs/cifs/readdir.c)

Obviously if we decide that the findfirst or findnext response from the server is messed up, then the next question is how to detect this in the client - and if we can detect it in the client, then we turn off serverinode numbers on the fly (after logging something about the broken server) - but first would be good to get wireshark to decode this level or decode some of it by hand.

<sahlberg1> tridge, jk that packet in the trace is infolevel 105 BUT it is encoded exactly the same as info level 104 (BOTH DIRECTORY Info), i.e. there is no new field here.
<sahlberg1> tridge, jk, this is either 0x104 and 0x105 are identical or a bug in the implementation in the server in this trace.
<jk> sahlberg1: it looks like the client has correctly parsed the response though, as it iterates through the directory contents...
<tridge> jk: each entry has a "next offset" ptr
<tridge> jk: so you can iterate, but you won't see the filenames
<tridge> jk: as the filename data will be at the wrong offset

Steve - Ronnie Sahlberg has just coded up a dissector for this (possibly broken) packet format, want me to put him in touch with you?

Yes! I can also confirm that this mount option solves the problem.

All files and directories are now visible and also the copy problem from comments #29/#30 disappeared.

I can confirm this helps with the apple time capsule

I too was having this problem with the apple time capsule and the -o noserverino workaround has resolved my issue.

Hi!. I'm also affected.

I have a Conceptronics Grab'n'Go NAS box and I've lost my backup files today after upgrade.

Please, can anybody post where do I need to put the 'serverino' option inside my /etc/fstab file sentence?

Thanks in advance. I'll come with feedback soon.

Regards,
^_Pepe_^

Something like this , taken from fstab

//1.1.1.1/share/ /mnt/mountpoint smbfs noserverino,nolinux,rw,user=MrBen,pass=ShopKeeper,dirmode=0777,filemode=0777 0 0

Thanks.

I've been able to put my NAS to work in 9.04 (after some bugs) with CIFS command. Something like this

//192.168.1.20/User /home/user/NAS cifs iocharset=utf8,file_mode=0777,dir_mode=0777,noperm,uid=1000 0 0

Should it be the same?

Thanks in advance.
^_Pepe_^

I'm pretty sure the problem I'm having is related to this bug, so I'll throw in my two cents.

When I connect to a windows share on my Jaunty box, I use:
sudo mount -t cifs -o username=xxx,password=yyy //192.168.xxx.xxx/share /mnt/share
and I'm able to connect, read, write and delete files just fine without using sudo.

When I do the same on my Karmic box, it connects and I can read files without issue. However, I cannot edit, write or delete anything without being root or sudo.

Disregard my comment. Adding file_mode=0777,dir_mode=0777 to the mount options solved my problem.

Hi!

noserverino option worked like a charm into my Conceptronic NAS disk. Thanks to all!

Regards,
^_Pepe_^

I have a Timecapsule (latest firmware) and thi bug affects me too, with karmic.

Tell me what I should provide you to help debugging.

after reading carefully every comment I can confirm the positive effects of the "noserverino" option

likewise, success with noserverinfo. NAS is Iomega home network running 102 firmware and mounted as smbfs (cifs has always failed with this device)

Hi all, another success with noserverino option in /etc/fstab.

I'm running a Repotec NA2310 NAS - 400GB disk inside, supports "samba" and FTP. I noticed random missing files in random directories when using Karmic, all OK in Jaunty. When viewing a directory with obvious missing files, select all then delete works, all the visible files are deleted, then the previously-invisible files are suddenly visible.

This problem ONLY occurred when using the 'nounix' mount option.

I'm running Karmic final release with all updates installed. smbclient installed version is 3.4.0-3ubuntu5 (same problem also happened in Karmic beta).

Anyway, noserverino fixed it for me - great news as I was starting to get really really worried about this one!

CD

I also see this bug on Arch Linux when using nounix. Option noserverino does *not* fix it. Guess it's an upstream issue.

Linux: 2.6.31.5-1
smbclient: 3.4.3-2 (testing)
NAS: FRITZ!Box Fon WLAN 7270 (UI) Firmware-Version 54.04.76
cat /proc/fs/cifs/DebugData
Display Internal CIFS Data Structures for Debugging
---------------------------------------------------
CIFS Version 1.60
Active VFS Requests: 0
Servers:
1) Name: 192.168.178.1 Domain: WORKGROUP Uses: 1 OS: Unix
 NOS: Samba 3.0.24 Capability: 0x80f3fd
 SMB session status: 1 TCP status: 1
 Local Users To Server: 2 SecMode: 0x2 Req On Wire: 0
 Shares:
 1) \\fritz.box\WDCWD10-EACS-22D6B1-02 Mounts: 1 Type: NTFS DevInfo: 0x0 Attributes: 0xb
PathComponentMax: 255 Status: 0x1 type: 0

 MIDs:

Using CIFS as the mount type along with both noserverinfo and file_mode=0777,dir_mode=0777 did the trick. Thank you for the quick fix!

On Arch Linux downgrading smbclient from 3.4.3-2 to 3.3.8-1 in addition to noserverino did the trick.

Had the permission issues with Karmic also. Original box was upgraded from Jaunty....and all mounts showed up as ro, without being able to fix it with an rw setting. Directories mounted into also had their ownership changed to root.

file_mode=0777,dir_mode=0777 fixed the permission problems....this is with smbfs. Seems the default settings have been changed in 9.10, given all my commands were pulled from this page:

http://www.debian-administration.org/articles/165

This will definitely cause major problems for anyone not expecting the change and without the time or expertise to search the planet for a fix (took me a few hours to locate this fix).

Forgot to mention, after the upgrade the HD crapped out. I then had to put a new 9.10 on new HD, and issues were identical. This is a major change in how mount works.....and needs to noted or changed back to previous.

Neither noserverino nor permissions fix worked for me. I still can't list the files on my Time Capsule, although I can navigate using directory names I remember. I've tried both lines below with no luck - am I messing up this work-around?
//10.0.1.1/Time\040Capsule /mnt/mmslab cifs noserverino,file_mode=0777,dir_mode=0777,username=myuserID,password=mypassword 0 0

//10.0.1.1/Time\040Capsule /mnt/mmslab smbfs noserverino,rw,user=myuserID,pass=mypassword,dirmode=0777,filemode=0777 0 0

hey mike d,

suggest you add 'nounix' into the mix, i.e :

//10.0.1.1/Time\040Capsule /mnt/mmslab cifs nounix,noserverino,file_mode=0777,dir_mode=0777,username=myuserID,password=mypassword 0 0

If you don't have nounix in there, you may find your NAS/server and your computer try to do magical things with permissions, which can only end in pain.

By putting file_mode and dir_mode you're setting your own mount permissions, just try nounix to prevent the system from over-riding it.

Good luck!

Callan

nounix did the trick! And I finally have full file permissions again too! Thanks!

With my basic Linux knowledge it wasnt easy to find this solution. First i was thinking it was just me doing something wrong.
i am running 9.04 with 2.6.31

A collegue saw it on my netbook and he installed ubuntu 9.1 NBR. He also had problems mounting his NAS.
Windows had no problems to mount it.

This made him think linux isnt really that user friendly.. he would never find this solution

imo i think these kind of bugs should get importance high, because network file access is highly used and people with not much knowledge about linux won't probaby find this solution.

unless ubuntu doesnt want to aim at user friedlyness.. :=)

anyway, good work.. i love ubuntu

i also had to add nounix to make it work

nounix made it work for me too.

I can also confirm this bug also effects me, I went from having this line in my fstab:-

//192.168.16.50/share/documents /mnt/documents cifs guest 0 0

to

//192.168.16.50/share/documents /mnt/documents cifs nounix,noserverino,file_mode=0777,dir_mode=0777,guest 0 0

But however now when iam doing a sync between our remote sites with exactually the same setup instead of 10 sites taking 20 minutes to be checked this is now taking over an hour using rsync.

Can anyone help me speed this backup? They are all NAS boxes with no permissions a Buffalo Drivestation.

Thanks

Andy

Hi,
Since today I do not have access any more to my NAS.
Reading this and other forum entries and trying some described solutions did not help to fix my problem.

Situation:
  System : Ubuntu 9.10
  NAS : WD MyBook Word Edition II

/etc/fstab:
  //192.168.1.100/public /media/MyBookNAS1 cifs nounix,noserverino,guest,rw,iocharset=utf8,file_mode=0777,dir_mode=0777 0 0
  # smbfs mount also does not work
  #//192.168.1.100/public /media/MyBookNAS1 smbfs user,uid=pie,uid=1000,file_mode=0777,dir_mode=0777 0 0

when mounting (mount -a) I get the following error:
  mount error(12): Cannot allocate memory
  Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

I also tried with smbfs (as it worked bevor) but without any success.

Please help me, I'm new in the Ubuntu-World and I need some beginner help :-)

Hi
I found out, that the problem may be my NAS, because I do not get any Web access to it. So I will have to see first what's going on with the NAS.

I can confirm I'm dealing with the same problem on Ubuntu 9.10

$ uname -a
Linux dog 2.6.31-16-generic #53-Ubuntu SMP Tue Dec 8 04:02:15 UTC 2009 x86_64 GNU/Linux

trying to mount NAS disk from command line. I use simple OEM NAS enclosure (Chipset: RDC-S3282) with 1TB disk
(purchased from http://www.smalldrives.com/network-external-drives-31/lan-server-drive-1000gb-147.html)

Everything works well if I connect using Nautilus and ~/.gvfs. I can also access files using smbclient:

mloskot@dog:/mnt$ smbclient //browarekhd/mloskot -U mloskot
Enter mloskot's password:
Domain=[R] OS=[R] Server=[R]
smb: \> ls
  . D 0 Wed Dec 23 22:38:02 2009
  .. D 0 Wed Dec 23 22:38:02 2009
  README.txt A 65 Sat Dec 26 17:01:40 2009
  doc D 0 Thu Dec 24 10:47:42 2009
  workshop D 0 Thu Dec 24 10:55:58 2009
  dev D 0 Thu Dec 24 11:08:08 2009
  software D 0 Fri Dec 25 17:06:34 2009
  Videos D 0 Sat Dec 26 12:48:12 2009
  mgr D 0 Sat Dec 26 16:56:52 2009
  Music D 0 Sat Dec 26 12:49:58 2009
  Documents D 0 Sat Dec 26 16:56:12 2009
  xbackup D 0 Sat Dec 26 19:33:44 2009
  Pictures D 0 Sat Dec 26 21:51:42 2009
  x.txt 0 Sun Dec 27 16:52:38 2009

  59602 blocks of size 16777216. 53403 blocks available
smb: \>

If I try to use mount command, I can mount the share but directories and files are not visible, though I can enter known directory or list known file.

Following suggestions given by Chuck Short, I've attached log with dmesg outputs - attached in 3 separate files:
- after moun
- after ls against known directory
- after ls against known file

I'm not really an expert of Samba implementation, but as far as I can decode the output, it indicates there are some problems.

I'd be thankful for any fix to this issue.
-- Mat

Happy New Year everyone !
I had the ls problem with Time Capsule, noserverino worked fine. Good job !
Mateusz, have you been trying all tests on this forum ? Noserverino, nounix ? What line do you try exactly ?

Hi guys,

I had also the same problem, but doing the changes that Andy suggested seems to work:

//192.168.16.50/share/documents /mnt/documents cifs guest 0 0

to

//192.168.16.50/share/documents /mnt/documents cifs nounix,noserverino,file_mode=0777,dir_mode=0777,guest 0 0

Cheers

I'm having the same issue with Karmic and an Airport Disk. Adding noserverino has fixed it, after a couple of hours of banging my head against walls and trying to get the right search term to finally bring me to this thread! Thanks!

Invalidated in 20100210 meeting. Kernel issue, and I'm not sure requiring special options to access a special device is really a bug.

It's surprising to me that a regression like this is not considered a bug. Requring special options is not a bug; changing the defaults for no apparent reason is. Changing the default from noserverino to serverino means that every person with an existing installation that mounts SMB/CIFS shares will have to know about this and modify their fstab manually during any upgrade, or their shares will appear to be broken. That's hardly friendly. I know that NFS mounts did a similar thing with some of their defaults in the 3 -> 4 transition, but I don't really think that's a good model to follow and there was actually some justification for that. Is there some reason to have changed the default options used by CIFS mounts?

Iam really disappointed that this also has not been classed as a bug buy the server team.
from going from a simply configuration on my fstab of between Januty & Karnic.
//server/mnt /mnt/mountpoint cifs guest 0 0
to
//server/mnt /mnt/mountpoint cifs nounix,noserverino,file_mode=0777,dir_mode=0777,guest 0 0

which is a big change in configuartion especially when this is not documented really well apart from on this bug report.

I would belive this should be classed as a server papercut for Lucid, and especially with it being a LTS. I expect there will be quite a few people using CIFS shares on Hardy who will jump to Lucid, and will not really know whats happened.

How can we get this reconsidered for a fix for Lucid?

> Iam really disappointed that this also has not been classed as a bug buy the server team.
> from going from a simply configuration on my fstab of between Januty & Karnic.
> //server/mnt /mnt/mountpoint cifs guest 0 0
> to
> //server/mnt /mnt/mountpoint cifs nounix,noserverino,file_mode=0777,dir_mode=0777,guest 0 0
>
> which is a big change in configuartion especially when this is not
> documented really well apart from on this bug report.

I'm afraid I have to agree with Andy Rogers here.

My experience is in using Ubuntu right since 6.06, and using Ubuntu with
a NAS device since 7.04.

I learned early that the NOUNIX option was useful, as this allows
user/group permissions to be set on the local mount point.

But the 'noserverino' option was never, ever needed. I always used the
same fstab entry all the way from 7.04 from 9.04.

For the record, my fstab had always been :

//server/mnt /mnt/mountpoint cifs
nounix,user=username,password=password,uid=uid,gid=gid,file_mode=0770,dir_mode=0770 0 0

If this is a kernel bug then I understand Ubuntu may not have direct
control over this, but I guess my feedback is that it's a very nasty
issue that cropped up by surprise, and it took me several weeks of
google and forum searching to find the answer. For a new user, or a less
experienced user, this may be a showstopper.

I will accept whatever outcome is decided, I thought I'd just post my
feedback in support of Andy's comments.

Cheers
Callan

It's not valid as a server papercut, since it affects a kernel team package /and/ the fix is probably not simple.
It is still valid as a bug, though: I agree this is an undesirable behavior change that should be fixed if possible.

 Hi
i've got the same problem and i spend many time to search a answer. (oh my head hurts me so!)usb hdd connecterd to a addonics nas adapter

Linux PC-mini 2.6.31-19-generic

somethings strange: i never read about the options "nolinux" and "noserverinfo" in all the websites and forums i visit.

but IT WORKS !!!

Thank you very much to all the people who intervent in this post
and greetings from France
by...

Option 'noserverino' worked for me also. Thanks for your work.

I can confirm that the "noserverinfo" worked for me as well.

Linux version 2.6.31-20-generic (buildd@crested) (gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu8) )

I use my laptop in many different environments accessing NTFS shares on servers and workstations as well as a home CoolNAS (bare embedded solaris NAS with 250GB internal drive)

Initial access to the mount without the "noserverinfo" option resulted in a blank window but subfolders could be accessed, if known. With the option, mount appears as it normally should.

Thanks guys, I hope a fix is not too difficult. I've seen many "bugs" that the noserverinfo option has fixed.

This bug was filed against a series that is no longer supported and so is being marked as Won't Fix. If this issue still exists in a supported series, please file a new bug.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

This bug was nominated against a series that is no longer supported, ie karmic. The bug task representing the karmic nomination is being closed as Won't Fix.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.