GNU bug report logs - #68283
ls -l issues on cifs mounted directories

Previous Next

To reply to this bug, email your comments to 68283 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Bjoern Voigt <bjoernv <at> arcor.de>
To: bug-coreutils <at> gnu.org
Subject: ls -l issues on cifs mounted directories
Date: Sat, 6 Jan 2024 14:08:04 +0100

After upgrading coreutils from version 9.3 to 9.4, "ls -l" shows error 
messages, if the files or directories are in a cifs/smb3 mounted directory.

Example:
/mnt/cifstest here is mounted with "mount -t cifs -o username=myuser 
//192.168.1.2/all /mnt/cifstest/". The server is a Samba 4.19.2 server. 
The kernel is version 6.1.71.

# ls -l /mnt/cifstest/
ls: /mnt/cifstest/: Resource temporarily unavailable
ls: /mnt/cifstest/opt: Resource temporarily unavailable
ls: /mnt/cifstest/dev: Resource temporarily unavailable
ls: /mnt/cifstest/var: Resource temporarily unavailable
ls: /mnt/cifstest/usr: Resource temporarily unavailable
ls: /mnt/cifstest/sbin: Resource temporarily unavailable
ls: /mnt/cifstest/boot: Resource temporarily unavailable
ls: /mnt/cifstest/lib: Resource temporarily unavailable
ls: /mnt/cifstest/etc: Resource temporarily unavailable
ls: /mnt/cifstest/lib64: Resource temporarily unavailable
ls: /mnt/cifstest/run: Resource temporarily unavailable
ls: /mnt/cifstest/proc: Resource temporarily unavailable
ls: /mnt/cifstest/lost+found: Resource temporarily unavailable
ls: /mnt/cifstest/root: Resource temporarily unavailable
ls: /mnt/cifstest/sys: Resource temporarily unavailable
ls: /mnt/cifstest/bin: Resource temporarily unavailable
ls: /mnt/cifstest/srv: Resource temporarily unavailable
ls: /mnt/cifstest/home: Resource temporarily unavailable
ls: /mnt/cifstest/mnt: Resource temporarily unavailable
ls: /mnt/cifstest/tmp: Resource temporarily unavailable
total 0
drwxr-xr-x 2 root root 0 Jan  6 12:01 bin
drwxr-xr-x 2 root root 0 Jan  5 20:47 boot
drwxr-xr-x 2 root root 0 Jan  6 13:14 dev
drwxr-xr-x 2 root root 0 Jan  5 21:00 etc
drwxr-xr-x 2 root root 0 Dec  6 22:54 home
drwxr-xr-x 2 root root 0 Jan  4 21:51 lib
drwxr-xr-x 2 root root 0 Jan  5 21:00 lib64
drwxr-xr-x 2 root root 0 Dec 21  2014 lost+found
drwxr-xr-x 2 root root 0 Jun  9  2021 mnt
drwxr-xr-x 2 root root 0 Dec 26 22:34 opt
drwxr-xr-x 2 root root 0 Jan  5 23:17 proc
drwxr-xr-x 2 root root 0 Dec 10 19:49 root
drwxr-xr-x 2 root root 0 Jan  6 13:53 run
drwxr-xr-x 2 root root 0 Jan  5 20:59 sbin
drwxr-xr-x 2 root root 0 Dec 27  2021 srv
drwxr-xr-x 2 root root 0 Jan  6 01:19 sys
drwxr-xr-x 2 root root 0 Jan  6 13:53 tmp
drwxr-xr-x 2 root root 0 Dec 10 19:49 usr
drwxr-xr-x 2 root root 0 Dec 12 08:37 var

"ls -l" from coreutils 9.3 does not show any errors.

Probably it is not just the error message. "dmesg -w" shows several 
errors after executing "ls -l":

[17563.999109] smb2_reconnect: 3 callbacks suppressed
[17563.999113] CIFS: VFS: reconnect tcon failed rc = -11
[17564.160117] CIFS: VFS: reconnect tcon failed rc = -11
[17564.192244] CIFS: VFS: reconnect tcon failed rc = -11
[17564.223303] CIFS: VFS: reconnect tcon failed rc = -11
[17564.256080] CIFS: VFS: reconnect tcon failed rc = -11
[17564.287887] CIFS: VFS: reconnect tcon failed rc = -11
[17564.410323] CIFS: VFS: reconnect tcon failed rc = -11
[17564.442095] CIFS: VFS: reconnect tcon failed rc = -11
[17564.474065] CIFS: VFS: reconnect tcon failed rc = -11
[17564.569435] CIFS: VFS: reconnect tcon failed rc = -11

I debugged this problem a bit. The changes in 
coreutils-9.4/lib/file-has-acl.c:file_has_acl are probably responsible 
for the errors. The system call listxttr produces the error message 
"Resource temporarily unavailable". I could not find the reasons for 
error messages shown with "dmesg".

The listxattr.c test program in the manual page (man listxattr) shows 
the following output:

# ./listxattr /mnt/cifstest/
listxattr: Resource temporarily unavailable

Work-around are to downgrade to coreutils 9.3 or not to use the "-l" 
option for ls.

Björn

Message #8 received at 68283 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Bjoern Voigt <bjoernv <at> arcor.de>, 68283 <at> debbugs.gnu.org
Cc: Ondrej Valousek <ondrej.valousek.xm <at> renesas.com>,
 Thiago Rafael Becker <trbecker <at> gmail.com>
Subject: Re: bug#68283: ls -l issues on cifs mounted directories
Date: Sat, 6 Jan 2024 14:48:21 +0000

On 06/01/2024 13:08, Bjoern Voigt via GNU coreutils Bug Reports wrote:
> After upgrading coreutils from version 9.3 to 9.4, "ls -l" shows error
> messages, if the files or directories are in a cifs/smb3 mounted directory.
> 
> Example:
> /mnt/cifstest here is mounted with "mount -t cifs -o username=myuser
> //192.168.1.2/all /mnt/cifstest/". The server is a Samba 4.19.2 server.
> The kernel is version 6.1.71.
> 
> # ls -l /mnt/cifstest/
> ls: /mnt/cifstest/: Resource temporarily unavailable


> "ls -l" from coreutils 9.3 does not show any errors.
> 
> Probably it is not just the error message. "dmesg -w" shows several
> errors after executing "ls -l":
> 
> [17563.999109] smb2_reconnect: 3 callbacks suppressed
> [17563.999113] CIFS: VFS: reconnect tcon failed rc = -11

> I debugged this problem a bit. The changes in
> coreutils-9.4/lib/file-has-acl.c:file_has_acl are probably responsible
> for the errors. The system call listxttr produces the error message
> "Resource temporarily unavailable". I could not find the reasons for
> error messages shown with "dmesg".
> 
> The listxattr.c test program in the manual page (man listxattr) shows
> the following output:
> 
> # ./listxattr /mnt/cifstest/
> listxattr: Resource temporarily unavailable
> 
> Work-around are to downgrade to coreutils 9.3 or not to use the "-l"
> option for ls.

Thanks for the details.
EAGAIN is not a documented return from listxattr,
and it seems like the cifs client should not let that leak.
Perhaps the kernel needs another change along the lines of:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6efa994e35a
(That was included in v5.18).

Perhaps something to ask at linux-cifs <at> vger.kernel.org ?

If this is a common enough issue then it might be appropriate for us to handle,
but given the current info, ls is just informing you of an actual issue on your system.

thanks,
Pádraig

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.