Your message dated Tue, 14 Sep 2021 20:50:09 +0200 with message-id <YUDu4fW7zQ2/[email protected]> and subject line Re: Bug#951867: nfs-common: input/output error for directory listing with 5 files with 173 <= sum(name lengths) <= 176 has caused the Debian Bug report #951867, regarding nfs-common: input/output error for directory listing with 5 files with 173 <= sum(name lengths) <= 176 to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 951867: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=951867 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: nfs-common Version: 1:1.3.4-2.5+b1 Severity: important Dear Maintainer, please find my observations on a specific scenario of an NFS directory listings. I have to apologize that my possibilities to track down the actual source are quite limited. However, I could test the issue against different debian/ubuntu installations: NFS client systems tested: * debian testing (this system, up-to-date): fail * debian unstable (up-to-date): fail * ubuntu 1910 (up-to-date): ok NFS server * ubuntu LTS 18.04.4 (up-to-date) NFS setup (identical on all tested systems) * NFSv4 + kerberos/ldap What led up to the situation? * create empty directory /path/to/nfs/directory/testdirectory on an NFS share * within this directory, create 5 files or directories with total length of 173 .. 176 characters Example with sub-directories, total name length = 173 characters: user@nfs-server:~$ ls -la /path/to/nfs/directory/testdirectory drwxr-xr-x 7 user group 7 Feb 22 14:02 . drwxr-sr-x 9 user group 9 Feb 22 13:32 .. drwxr-xr-x 2 user group 2 Feb 22 13:16 0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF drwxr-xr-x 2 user group 2 Feb 22 13:16 123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0 drwxr-xr-x 2 user group 2 Feb 22 13:17 23456789ABCDEF0123456789ABCDEF0123456789ABCDEF01 drwxr-xr-x 2 user group 2 Feb 22 13:17 3456789ABCDEF012 drwxr-xr-x 2 user group 2 Feb 22 13:26 456789ABCDEF0 Example with files, total name length = 176 characters: user@nfs-server:~$ ls -la /path/to/nfs/directory/testdirectory drwxr-xr-x 2 user group 7 Feb 22 13:32 . drwxr-sr-x 9 user group 9 Feb 22 13:32 .. -rw-r--r-- 1 user group 0 Feb 22 13:32 0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF -rw-r--r-- 1 user group 0 Feb 22 13:32 123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0 -rw-r--r-- 1 user group 0 Feb 22 13:32 23456789ABCDEF0123456789ABCDEF0123456789ABCDEF01 -rw-r--r-- 1 user group 0 Feb 22 13:32 3456789ABCDEF012 -rw-r--r-- 1 user group 0 Feb 22 13:32 456789ABCDEF0123 What was the outcome of this action? * on debian testing and unstable NFS clients: user@nfs-client:~$ ls -la /path/to/nfs/directory/testdirectory ls: reading directory '/path/to/nfs/directory/testdirectory': Input/output error * on ubuntu NFS client: directory listing is fine What exactly did you do (or not do) that was effective (or ineffective)? * Vary file name lengths within 173 ... 176: still I/O errors * Vary file name lengths above 176 or below 173 characters: no error * Add/remove file/sub-directory and widely vary file name lengths: no error What outcome did you expect instead? * no I/O errors in all cases Log file content * dmesg: no related entries * syslog: no related entries * daemon.log: no related entries -- Package-specific info: -- rpcinfo -- program vers proto port service 100000 4 tcp 111 portmapper 100000 3 tcp 111 portmapper 100000 2 tcp 111 portmapper 100000 4 udp 111 portmapper 100000 3 udp 111 portmapper 100000 2 udp 111 portmapper -- /etc/default/nfs-common -- NEED_STATD= STATDOPTS= NEED_IDMAPD= NEED_GSSD= -- /etc/idmapd.conf -- [General] Verbosity = 0 Pipefs-Directory = /run/rpc_pipefs [Mapping] Nobody-User = nobody Nobody-Group = nogroup -- /etc/fstab -- -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (800, 'testing'), (700, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-4-amd64 (SMP w/6 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages nfs-common depends on: ii adduser 3.118 ii keyutils 1.6.1-2 ii libc6 2.29-10 ii libcap2 1:2.32-1 ii libcom-err2 1.45.5-2 ii libdevmapper1.02.1 2:1.02.167-1 ii libevent-2.1-7 2.1.11-stable-1 ii libgssapi-krb5-2 1.17-6 ii libkeyutils1 1.6.1-2 ii libkrb5-3 1.17-6 ii libmount1 2.34-0.1 ii libnfsidmap2 0.25-5.1 ii libtirpc3 1.2.5-1 ii libwrap0 7.6.q-30 ii lsb-base 11.1.0 ii rpcbind 1.2.5-8 ii ucf 3.0038+nmu1 Versions of packages nfs-common recommends: ii python 2.7.17-2 Versions of packages nfs-common suggests: pn open-iscsi <none> pn watchdog <none> -- no debconf information
--- End Message ---
--- Begin Message ---Control: tags -1 + moreinfo unreproducible On Sat, Feb 22, 2020 at 02:55:35PM +0100, emw wrote: > Package: nfs-common > Version: 1:1.3.4-2.5+b1 > Severity: important > > Dear Maintainer, > > please find my observations on a specific scenario of an NFS directory > listings. > I have to apologize that my possibilities to track down the actual source are > quite limited. > However, I could test the issue against different debian/ubuntu installations: > > NFS client systems tested: > * debian testing (this system, up-to-date): fail > * debian unstable (up-to-date): fail > * ubuntu 1910 (up-to-date): ok > > NFS server > * ubuntu LTS 18.04.4 (up-to-date) > > NFS setup (identical on all tested systems) > * NFSv4 + kerberos/ldap > > > What led up to the situation? > > * create empty directory /path/to/nfs/directory/testdirectory on an NFS > share > > * within this directory, create 5 files or directories with total length of > 173 .. 176 characters > > Example with sub-directories, total name length = 173 characters: > user@nfs-server:~$ ls -la /path/to/nfs/directory/testdirectory > drwxr-xr-x 7 user group 7 Feb 22 14:02 . > drwxr-sr-x 9 user group 9 Feb 22 13:32 .. > drwxr-xr-x 2 user group 2 Feb 22 13:16 > 0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF > drwxr-xr-x 2 user group 2 Feb 22 13:16 > 123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0 > drwxr-xr-x 2 user group 2 Feb 22 13:17 > 23456789ABCDEF0123456789ABCDEF0123456789ABCDEF01 > drwxr-xr-x 2 user group 2 Feb 22 13:17 3456789ABCDEF012 > drwxr-xr-x 2 user group 2 Feb 22 13:26 456789ABCDEF0 > > Example with files, total name length = 176 characters: > user@nfs-server:~$ ls -la /path/to/nfs/directory/testdirectory > drwxr-xr-x 2 user group 7 Feb 22 13:32 . > drwxr-sr-x 9 user group 9 Feb 22 13:32 .. > -rw-r--r-- 1 user group 0 Feb 22 13:32 > 0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF > -rw-r--r-- 1 user group 0 Feb 22 13:32 > 123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0 > -rw-r--r-- 1 user group 0 Feb 22 13:32 > 23456789ABCDEF0123456789ABCDEF0123456789ABCDEF01 > -rw-r--r-- 1 user group 0 Feb 22 13:32 3456789ABCDEF012 > -rw-r--r-- 1 user group 0 Feb 22 13:32 456789ABCDEF0123 > > > What was the outcome of this action? > > * on debian testing and unstable NFS clients: > > user@nfs-client:~$ ls -la /path/to/nfs/directory/testdirectory > ls: reading directory '/path/to/nfs/directory/testdirectory': Input/output > error > > * on ubuntu NFS client: directory listing is fine > > What exactly did you do (or not do) that was effective (or ineffective)? > > * Vary file name lengths within 173 ... 176: still I/O errors > > * Vary file name lengths above 176 or below 173 characters: no error > > * Add/remove file/sub-directory and widely vary file name lengths: no error > > What outcome did you expect instead? > > * no I/O errors in all cases > > Log file content > > * dmesg: no related entries > > * syslog: no related entries > > * daemon.log: no related entries I cannot reproduce this issue. In case you still can with a recent nfs-utils version (ideally test the one from experimental) feel free to repoen. Regards, Salvatore
--- End Message ---
