Created attachment 1662279 [details] On Samba 4.11.6, some files seen as directory, wrong modification date Description of problem: Screenshot of Nautilus browsing a samba network share. (Really similar to bug #1797875 - can't understand why closed !?) Version-Release number of selected component (if applicable):Fedora 31 Package samba-2:4.11.6-0.fc31.x86_64 How reproducible: Steps to Reproduce: 1. Since my router only supports smb ver 1.0 I have the line "client min protocol = NT1" in my /etc/samba/smb.conf file. 2. Connect to the router with Nautilus and open a shared directory (cf. attachment) 3. Actual results: Some files seen as directories, and the last modifcation date is wrong ; even files NOT seen as directories can not been opened with apps (such as VLC for music tracks) Expected results: The files can be listed normally, opened with abs on shares Additional info: 1. The router only supports SMB v1, I can't change the interface for a more recent version, unfortunately. 2. I tried on a virtual machine with "root, live USB of F31" (on : https://www.fedora-fr.org/), with the original proposed SAMBA version (which seems to be 4.11.0) by the iso ; I have set client min protocol to NT1 : everything runs well !!
Created attachment 1662281 [details] On Samba 4.11.6, some files seen as directory, wrong modification date
Created attachment 1662282 [details] Samba 4.11.6 : Nautilus ok.
Created attachment 1662283 [details] On Samba 4.11.6, some files seen as directory, wrong modification date
Created attachment 1662284 [details] Samba 4.11.0 : Nautilus ok.
Created attachment 1662285 [details] On Samba 4.11.6, clicking on "directory-like" file : "file is not a directory"
Created attachment 1662286 [details] Samba version is 4.11.6
Created attachment 1662287 [details] On Samba 4.11.6, client min protocol set to NT1
*** Bug 1803971 has been marked as a duplicate of this bug. ***
If it helps isolate the changes that result in this I have the same issue on FC30 with samba 4.10.13 and did not experience the issue with 4.10.11 A full OS update on 2020-02-22 included the samba 4.10.13 package set. Downgrading samba-common samba-client-libs samba-common-libs samba-libs samba-client (which surprisingly downgraded to 4.10.2) made the issue go away. No other packages were downgraded to make the issue go away.
I was able to view my smb shares on Thunar with only GVFS-SMB installed not SAMBA so I assumed SAMBA wasn't the problem. I downgraded GVFS-SMB & Thunar but still had the problem.
I noticed that a Samba update is available for F31: libsmbclient.x86_64 2:4.11.7-0.fc31 updates libwbclient.x86_64 2:4.11.7-0.fc31 updates samba-client.x86_64 2:4.11.7-0.fc31 updates samba-client-libs.x86_64 2:4.11.7-0.fc31 updates samba-common.noarch 2:4.11.7-0.fc31 updates samba-common-libs.x86_64 2:4.11.7-0.fc31 updates samba-common-tools.x86_64 2:4.11.7-0.fc31 updates samba-dc-libs.x86_64 2:4.11.7-0.fc31 updates samba-libs.x86_64 2:4.11.7-0.fc31 updates I don't see anything specific relating to this bug in the 4.11.7 change log. Was there an upstream fix requested? Can you confirm if 4.11.7 restores the proper behavior?
I'm not able to confirm this. I am running fedora 30 and there are no updates for samba-* packages at this time.
I just updated & rebooted my xfce fedora 31 installation (3/23/2020) and when I browse the hard drive attached the the usb port on my Linksys router that only supports smb1 via smb with thunar, all files have the folder icon and are inaccessible. Same as bug #1797875 I filed on 2/4/2020. I believe at this point this is not a bug and it must be that there is inherent incompatibility with smb1 that must be regarded as a feature going forward. SUSE Tumbleweed Gecko introduced the same feature about two weeks ago. The Debian distro's haven't upgraded themselves into this smb incompatibility yet but I assume that they will before long. The fix for me was to switch to FTP by enabling it on my router then all shared folders on the attached storage device can be recognized and accessed as usual on both Fedora & SUSE.
Can pre-4.11.6 SMB1/NT1 functionality be restored to fix this unexpected behavior?
The Manjaro distro joined the SMB party in the last couple days. I had a boss who used to say "if you can't fix it, feature it" lol Ubuntu isn't infected yet.
Could anyone who reproduced this issue make a network trace that demonstrates it? Please see https://www.samba.org//~asn/reporting_samba_bugs.txt and especially 'Network traces' section for details. Ideally, we need two traces: one showing working setup and one showing a broken one. Please make sure you are not using your real password in those traces.
Alexander I hope these two trace files are helpful.
Created attachment 1676981 [details] Fedora trace file 4/7/2020
Created attachment 1676982 [details] Xubuntu trace file 4/7/2020
Thanks, Mark. From quick look, Fedora version sends SMBv1 UNIX extension request while XUbuntu sends normal SMBv1. The server actually responds it does support SMBv1 UNIX extensions. However, the POSIX stat requests sent by newer Samba do not contain a file name somehow. Request in packet 201: SMB (Server Message Block Protocol) SMB Header Server Component: SMB [Response in: 202] SMB Command: Trans2 (0x32) NT Status: STATUS_SUCCESS (0x00000000) Flags: 0x10, Canonicalized Pathnames Flags2: 0xc843, Unicode Strings, Error Code Type, Extended Security Negotiation, Long Names Used, Extended Attributes, Long Names Allowed Process ID High: 0 Signature: 0000000000000000 Reserved: 0000 Tree ID: 1 (\\ROUTER\STEVE_JADICK) Process ID: 1947 User ID: 101 Multiplex ID: 16 Trans2 Request (0x32) Word Count (WCT): 15 Total Parameter Count: 8 Total Data Count: 0 Max Parameter Count: 2 Max Data Count: 100 Max Setup Count: 0 Reserved: 00 Flags: 0x0000 Timeout: Return immediately (0) Reserved: 0000 Parameter Count: 8 Parameter Offset: 68 Data Count: 0 Data Offset: 76 Setup Count: 1 Reserved: 00 Subcommand: QUERY_PATH_INFO (0x0005) Byte Count (BCC): 11 Padding: 004420 QUERY_PATH_INFO Parameters Level of Interest: Query File Unix Basic (512) Reserved: 00000000 File Name: and gets a response SMB (Server Message Block Protocol) SMB Header Server Component: SMB [Response to: 201] [Time from request: 0.000740000 seconds] SMB Command: Trans2 (0x32) NT Status: STATUS_SUCCESS (0x00000000) Flags: 0x80, Request/Response Flags2: 0xc841, Unicode Strings, Error Code Type, Extended Security Negotiation, Long Names Used, Long Names Allowed Process ID High: 0 Signature: 0000000000000000 Reserved: 0000 Tree ID: 1 (\\ROUTER\STEVE_JADICK) Process ID: 1947 User ID: 101 Multiplex ID: 16 Trans2 Response (0x32) Subcommand: QUERY_PATH_INFO (0x0005) [Level of Interest: Query File Unix Basic (512)] [File Name: ] Word Count (WCT): 10 Total Parameter Count: 2 Total Data Count: 100 Reserved: 0000 Parameter Count: 2 Parameter Offset: 56 Parameter Displacement: 0 Data Count: 100 Data Offset: 60 Data Displacement: 0 Setup Count: 0 Reserved: 00 Byte Count (BCC): 105 Padding: 00 QUERY_PATH_INFO Parameters EA Error offset: 0 Padding: 0000 QUERY_PATH_INFO Data File size: 0 Number of bytes: 0 Last status change: Apr 7, 2020 18:17:42.000000000 EEST Last access: Feb 16, 2019 01:25:58.000000000 EET Last modification: Apr 7, 2020 18:17:42.000000000 EEST UID: 0 GID: 0 File type: Directory (1) Major device: 0x0000000000000000 Minor device: 0x0000000000000000 Unique ID: 0x0000000000000002 File permissions: 0x00000000000001ed Num links: 5 It is interesting that this response comes pretty much on every request. For example, another one is Request in packet 203: SMB (Server Message Block Protocol) SMB Header Server Component: SMB [Response in: 204] SMB Command: Trans2 (0x32) NT Status: STATUS_SUCCESS (0x00000000) Flags: 0x10, Canonicalized Pathnames Flags2: 0xc843, Unicode Strings, Error Code Type, Extended Security Negotiation, Long Names Used, Extended Attributes, Long Names Allowed Process ID High: 0 Signature: 0000000000000000 Reserved: 0000 Tree ID: 1 (\\ROUTER\STEVE_JADICK) Process ID: 1947 User ID: 101 Multiplex ID: 17 Trans2 Request (0x32) Word Count (WCT): 15 Total Parameter Count: 8 Total Data Count: 0 Max Parameter Count: 2 Max Data Count: 100 Max Setup Count: 0 Reserved: 00 Flags: 0x0000 Timeout: Return immediately (0) Reserved: 0000 Parameter Count: 8 Parameter Offset: 68 Data Count: 0 Data Offset: 76 Setup Count: 1 Reserved: 00 Subcommand: QUERY_PATH_INFO (0x0005) Byte Count (BCC): 11 Padding: 004420 QUERY_PATH_INFO Parameters Level of Interest: Query File Unix Basic (512) Reserved: 00000000 File Name: gets the same response: SMB (Server Message Block Protocol) SMB Header Server Component: SMB [Response to: 203] [Time from request: 0.000735000 seconds] SMB Command: Trans2 (0x32) NT Status: STATUS_SUCCESS (0x00000000) Flags: 0x80, Request/Response Flags2: 0xc841, Unicode Strings, Error Code Type, Extended Security Negotiation, Long Names Used, Long Names Allowed Process ID High: 0 Signature: 0000000000000000 Reserved: 0000 Tree ID: 1 (\\ROUTER\STEVE_JADICK) Process ID: 1947 User ID: 101 Multiplex ID: 17 Trans2 Response (0x32) Subcommand: QUERY_PATH_INFO (0x0005) [Level of Interest: Query File Unix Basic (512)] [File Name: ] Word Count (WCT): 10 Total Parameter Count: 2 Total Data Count: 100 Reserved: 0000 Parameter Count: 2 Parameter Offset: 56 Parameter Displacement: 0 Data Count: 100 Data Offset: 60 Data Displacement: 0 Setup Count: 0 Reserved: 00 Byte Count (BCC): 105 Padding: 00 QUERY_PATH_INFO Parameters EA Error offset: 0 Padding: 0000 QUERY_PATH_INFO Data File size: 0 Number of bytes: 0 Last status change: Apr 7, 2020 18:17:42.000000000 EEST Last access: Feb 16, 2019 01:25:58.000000000 EET Last modification: Apr 7, 2020 18:17:42.000000000 EEST UID: 0 GID: 0 File type: Directory (1) Major device: 0x0000000000000000 Minor device: 0x0000000000000000 Unique ID: 0x0000000000000002 File permissions: 0x00000000000001ed Num links: 5 I think we need to investigate why actual file path is missing from the QUERY_PATH_INFO with POSIX stat request.
Andreas, I think this is related to your work on https://bugzilla.samba.org/show_bug.cgi?id=14101 and https://bugzilla.redhat.com/show_bug.cgi?id=1634057. Could you please confirm?
Mark, I have made a scratch build for Fedora 31 which removes a codepath that forced use of SMBv1 UNIX extensions in the stat call if they were available. Could you please try it? https://koji.fedoraproject.org/koji/taskinfo?taskID=43121988 (ARM versions are still building at this moment but x86_64 is already available)
Alexander, Thanks for your detailed explanation of this problem. I would like to assist but I'm having difficulty finding a way to actually download the patched RPM. (samba-4.11.7-0.1.fc31.src.rpm, x86_64) https://koji.fedoraproject.org/koji/taskinfo?taskID=43122027
Never mind, a good friend of mine dug out the actual download link for me. https://kojipkgs.fedoraproject.org//packages/samba/4.11.7/0.fc31/src/samba-4.11.7-0.fc31.src.rpm He says that I'll be in "dependency hell" I hope DNF can handle it.
Mark, you can download packages from any Koji task with dnf -y install koji koji download-task <taskid> in this case it would be koji download-task 43122027 this will give you all rpms from the build.
Alexander, I downloaded the Koji task and here's what DNF says it needs. Thanks [root@closetputer PatchedSAMBA]# dnf install samba-4.11.7-0.1.fc31.x86_64.rpm Last metadata expiration check: 0:01:12 ago on Sat 11 Apr 2020 10:58:30 AM EDT. Error: Problem: conflicting requests - nothing provides libwbclient = 2:4.11.7-0.1.fc31 needed by samba-2:4.11.7-0.1.fc31.x86_64 - nothing provides samba-client-libs = 2:4.11.7-0.1.fc31 needed by samba-2:4.11.7-0.1.fc31.x86_64 - nothing provides samba-common = 2:4.11.7-0.1.fc31 needed by samba-2:4.11.7-0.1.fc31.x86_64 - nothing provides samba-common-libs = 2:4.11.7-0.1.fc31 needed by samba-2:4.11.7-0.1.fc31.x86_64 - nothing provides samba-common-tools = 2:4.11.7-0.1.fc31 needed by samba-2:4.11.7-0.1.fc31.x86_64 - nothing provides samba-libs = 2:4.11.7-0.1.fc31 needed by samba-2:4.11.7-0.1.fc31.x86_64 (try to add '--skip-broken' to skip uninstallable packages) [root@closetputer PatchedSAMBA]#
You can simply update existing packages by rpm -Fhv *.rpm
By Jove! You've fixed it! Browsing with Thunar via smb to the usb drive on my router works like it used too. I wonder if Fedora rolls out the fixed samba if SUSE & Manjaro will pickup on it? Thank you very much Alexander, I know that software is a lot easier to critique than it is to write! I feel good that I was able to help since I'm no code writer, Basic on a C64 in the 80's was my last playing with it other than batch files and playing computer "Doctor" for other people. lol Thanks, Mark
Thanks. I'll add it to Fedora build. I also acked a revert of the patches that caused this issue on the upstream bug https://bugzilla.samba.org/show_bug.cgi?id=14101, so the revert should eventually land in next 4.10/4.11 releases.
FEDORA-2020-2655ce257f has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-2655ce257f
FEDORA-2020-7f0df2c653 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-7f0df2c653
FEDORA-2020-7f0df2c653 has been pushed to the Fedora 32 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-7f0df2c653` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-7f0df2c653 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-2655ce257f has been pushed to the Fedora 31 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-2655ce257f` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-2655ce257f See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-7f0df2c653 has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2020-2655ce257f has been pushed to the Fedora 31 stable repository. If problem still persists, please make note of it in this bug report.
Hello all, I hadn't the skills neither to investigate you, nor to help you, but I downloaded the official change today and it works fine. Thank you soooooo much to all, for my favourite distro :-D. Best regards, Laurent.
Hello, I've also installed and tested the latest fix. Everything now works just as it did before! Thanks all! Regards, Daniel.