I’m seeing problems with mounted SMB v1 folders in Tumbleweed with kernel 7.x. So far I’ve tested with 7.0.2, 7.0.7, 7.0.9, and 7.0.10 and have seen problems with all of them. The current longterm kernels, including the most recent 6.18.34 don’t seem to have this problem. The trouble seems to happen only with SMB v1 and not SMB v2 or v3 mounts and manifests as incomplete or garbled directory listings.
Anyone else seeing this or have some clue on what’s happening or how to fix it?
As you are no doubt already aware, SMB1 is deprecated from a security perspective, but there is still kernel support for it. If there’s a reproducible regression between 6.18 and 7.0, it’s still worth reporting IMHO. (Whether it gets fixed quickly may depend on the quality of the bug report and how easy it is to identify the offending change.)
Any errors or warnings evident?
journalctl -k -b | grep -i cifs
Is the issue intermittent? If you list the share a few times, does the output change at all?
ls -la /mnt/share
ls -la /mnt/share
ls -la /mnt/share
If you bypass any caching with
sudo mount -o remount,cache=none /mnt/share
or unmount and remount with something like
sudo mount -t cifs //server/share /mnt/share -o vers=1.0,cache=none,...
does the directory corruption disappear?
Does smblient expose the same issue? For example
sudo smbclient //server/share -m NT1
then examine the listing from smb: \> ls
Same issue?
Thank you for the quick reply. These are all good questions and ones I should have thought of myself.
I know SMB v1 support is deprecated. Unfortunately the mounted share is in a piece of equipment running Windows XP which cannot be replaced or upgraded so I’m stuck needing SMB v1.
I’m definitely seeing errors in the journal. The messages look like some sort of bug may have crept into the CIFS client. I’ll attach a snippet of them at the end of this message.
The issue is intermittent; multiple lists of the share sometimes return different, but never correct, results. Remounting or dismounting and mounting the share with the cache=none does not make any difference in the problem.
Mounting the share with smbclient seems to work fine and always returns correct results.
Here is what I’m seeing in the journal regarding when I have errors in CIFS:
emfhq-dt-0nyd kernel: WARNING: fs/smb/client/smb1transport.c:400 at cifs_check_trans2+0x542/0x7a0 [cifs], CPU#5: cifsd/4130
Jun 08 09:52:33 emfhq-dt-0nyd kernel: Modules linked in: nls_utf8 cifs nls_ucs2_utils libarc4 cifs_md4 dns_resolver netfs af_packet bridge stp llc nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat ebtable_nat ebtable_broute ip6table_nat ip6table_mangle ip6table_raw ip6table_security iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 iptable_mangle iptable_raw iptable_security ip_set ebtable_filter ebtables ip6table_filter ip6_tables qrtr nf_tables vboxnetadp(O) vboxnetflt(O) vboxdrv(O) iptable_filter ip_tables ccp dm_mod x_tables snd_hda_codec_alc269 snd_hda_codec_realtek_lib snd_hda_codec_intelhdmi snd_hda_codec_hdmi snd_hda_scodec_component snd_hda_codec_generic snd_hda_intel snd_hda_codec spi_nor snd_hda_core snd_intel_dspcfg mtd snd_intel_sdw_acpi snd_hwdep mei_pxp iTCO_wdt intel_pmc_bxt mei_hdcp at24 snd_pcm snd_timer spi_intel_platform snd spi_intel mei_wdt intel_rapl_msr mei_me intel_rapl_common mei soundcore firmware_attributes_class pcspkr i2c_i801
Jun 08 09:52:33 emfhq-dt-0nyd kernel: CPU: 5 UID: 0 PID: 4130 Comm: cifsd Tainted: G O 7.0.10-2-default #1 PREEMPT(full) openSUSE Tumbleweed cae8b7d4f053cbcf6dd2018030314afe6941bc85
Jun 08 09:52:33 emfhq-dt-0nyd kernel: RIP: 0010:cifs_check_trans2+0x54c/0x7a0 [cifs]
Jun 08 09:52:33 emfhq-dt-0nyd kernel: cifs_handle_standard+0xc1/0x1a0 [cifs 35fda3cb21502366937f3932e1701b12320ce846]
Jun 08 09:52:33 emfhq-dt-0nyd kernel: cifs_demultiplex_thread+0xa6e/0xcf0 [cifs 35fda3cb21502366937f3932e1701b12320ce846]
Jun 08 09:52:33 emfhq-dt-0nyd kernel: ? __pfx_cifs_demultiplex_thread+0x10/0x10 [cifs 35fda3cb21502366937f3932e1701b12320ce846]
Jun 08 09:52:33 emfhq-dt-0nyd kernel: ? __pfx_cifs_demultiplex_thread+0x10/0x10 [cifs 35fda3cb21502366937f3932e1701b12320ce846]
Jun 08 09:52:33 emfhq-dt-0nyd kernel: CIFS: VFS: Autodisabling the use of server inode numbers on \\JTB\JTBWorkFolder
Jun 08 09:52:33 emfhq-dt-0nyd kernel: CIFS: VFS: The server doesn't seem to support them properly or the files might be on different servers (DFS)
Jun 08 09:52:33 emfhq-dt-0nyd kernel: CIFS: VFS: Hardlinks will not be recognized on this mount. Consider mounting with the "noserverino" option to silence this message.
Jun 08 09:52:49 emfhq-dt-0nyd kernel: CIFS: VFS: bad search response length 809701530 past smb end
Jun 08 09:52:49 emfhq-dt-0nyd kernel: CIFS: VFS: bad search response length 809701530 past smb end
Jun 08 09:52:51 emfhq-dt-0nyd kernel: CIFS: VFS: bad search response length 1195853639 past smb end
Jun 08 09:52:51 emfhq-dt-0nyd kernel: CIFS: VFS: bad search response length 1195853639 past smb end
And here is what I see when it’s working properly in the 6.18.34 kernel:
Jun 08 10:24:36 emfhq-dt-0nyd kernel: CIFS: Attempting to mount //JTB/JTBWorkFolder
Jun 08 10:24:46 emfhq-dt-0nyd kernel: WARNING: CPU: 1 PID: 3693 at fs/smb/client/smb1ops.c:368 cifs_check_trans2+0x560/0x7c0 [cifs]
Jun 08 10:24:46 emfhq-dt-0nyd kernel: Modules linked in: nls_utf8 cifs nls_ucs2_utils libarc4 cifs_md4 dns_resolver netfs af_packet nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat bridge ebtable_nat ebtable_broute stp llc ip6table_nat ip6table_mangle ip6table_raw ip6table_security iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 iptable_mangle iptable_raw iptable_security ip_set ebtable_filter ebtables ip6table_filter ip6_tables qrtr nf_tables iptable_filter ip_tables x_tables dm_mod snd_hda_codec_alc269 snd_hda_scodec_component snd_hda_codec_realtek_lib snd_hda_codec_intelhdmi snd_hda_codec_generic snd_hda_codec_hdmi intel_rapl_msr snd_hda_intel intel_rapl_common x86_pkg_temp_thermal snd_hda_codec intel_powerclamp snd_hda_core coretemp snd_intel_dspcfg snd_intel_sdw_acpi spi_nor kvm_intel mtd snd_hwdep firmware_attributes_class hp_wmi snd_pcm kvm iTCO_wdt spi_intel_platform snd_timer platform_profile sparse_keymap tiny_power_button snd spi_intel rfkill
Jun 08 10:24:46 emfhq-dt-0nyd kernel: CPU: 1 UID: 0 PID: 3693 Comm: cifsd Not tainted 6.18.34-1-longterm #1 PREEMPT(full) openSUSE Tumbleweed 9a14d7b8efcb9d16e718adf4f8a5dba6fbcce579
Jun 08 10:24:46 emfhq-dt-0nyd kernel: RIP: 0010:cifs_check_trans2+0x560/0x7c0 [cifs]
Jun 08 10:24:46 emfhq-dt-0nyd kernel: cifs_handle_standard+0xbb/0x1a0 [cifs d85e7f05d0bb1e01f68cdd52c5a29848db0157f8]
Jun 08 10:24:46 emfhq-dt-0nyd kernel: cifs_demultiplex_thread+0xa75/0xd00 [cifs d85e7f05d0bb1e01f68cdd52c5a29848db0157f8]
Jun 08 10:24:46 emfhq-dt-0nyd kernel: ? __pfx_cifs_demultiplex_thread+0x10/0x10 [cifs d85e7f05d0bb1e01f68cdd52c5a29848db0157f8]
Good to know that smbclient works as expected. The repeated bad search response length ... past smb end messages from cifs_check_trans2() do seem to point towards a possible regression in the kernel CIFS client’s SMB1 directory enumeration code path.
Are you in a position where you could test against another SMBv1 host? That might be useful before submitting a bug report.
Having said that, the comparative results between 6.18.34 and 7.0.x, together with the cifs_check_trans2() warnings, may already be sufficient to justify filing a bug report.
I made sure SMB1 was still enabled on a Windows 7 machine and created a share there to test with. I am seeing the same problem there as with the XP machine but only if I mount it as SMB1 (i.e. option vers=1.0); It works correctly if mounted as SMB2 or if mounted as SMB1 with the earlier kernel. I think it’s definitely some sort of regression in the CIFS client.
Would there be any good way to grab and install a 6.19 kernel from an earlier Tumbleweed release onto this system so I could see whether the regression happened with 6.19 or 7.x?
If you are using Btrfs and snapper you could roll back to the 6.19 kernel? What snapshots are shown as available by GRUB in your system?
Otherwise, for diagnostic purposes you could consider the (Tiwai maintainer’s) home:tiwai:kernel:6.19 stable backport repo perhaps…
Unfortunately, I use Btrfs but snapper won’t help me as this system was updated from 6.17 to 7.0x directly then from 6.12 to 6.18 as the LTS kernel. I was thinking something more along the lines of grabbing older kernel RPMs from an earlier version of tumbleweed or slowroll and installing them alongside the existing kernel versions. I think I’ve got an older tumbleweed DVD which I think has 6.19.10 on it. Nothing between that and 7.0.2 though. I just wasn’t sure if that would be a good way to go about it.
Yes, or the Tiwai repo as suggested.
Yes, that repo is very handy. I’ve added it and installed the kernel from the 6.19 repo there (which is actually 6.19.12) as well as the just released 7.0.11 from the main repo and both have the problem. I’ll try and find and work back through earlier 6.19 releases to see if I can narrow it down any more.
A little more testing: Kernel 6.19.10 (from tumbleweed DVD snapshot 20260330) and 6.19.6 (from tumbleweed DVD snapshot 20260310) both fail as well.
I’ve submitted this on the SUSE Bugzilla as bug 1268068 and I’ll see what comes of things via that route as well.
Thank you very much for all of your help so far.
Direct link to bugreport:
https://bugzilla.opensuse.org/show_bug.cgi?id=1268068
After a quick test, I’m able to confirm that the 7.1.2 kernel has the same problem.