Description of problem: After upgrading from Fedora 30 to Fedora 31, I am no longer able to read/write to my NAS share either using Nautilus or access the via GVFS smb mount point. Files randomly show up as directories. Version-Release number of selected component (if applicable): - Samba client machine running Fedora 31: samba-4.11.6-0.fc31.x86_64 samba-client-4.11.6-0.fc31.x86_64 samba-client-libs-4.11.6-0.fc31.x86_64 samba-common-4.11.6-0.fc31.noarch samba-common-libs-4.11.6-0.fc31.x86_64 samba-common-tools-4.11.6-0.fc31.x86_64 samba-dc-libs-4.11.6-0.fc31.x86_64 samba-libs-4.11.6-0.fc31.x86_64 gvfs-1.42.2-1.fc31.x86_64 gvfs-afc-1.42.2-1.fc31.x86_64 gvfs-afp-1.42.2-1.fc31.x86_64 gvfs-archive-1.42.2-1.fc31.x86_64 gvfs-client-1.42.2-1.fc31.x86_64 gvfs-fuse-1.42.2-1.fc31.x86_64 gvfs-goa-1.42.2-1.fc31.x86_64 gvfs-gphoto2-1.42.2-1.fc31.x86_64 gvfs-mtp-1.42.2-1.fc31.x86_64 gvfs-smb-1.42.2-1.fc31.x86_64 nautilus-3.34.2-2.fc31.x86_64 dbus-1.12.16-3.fc31.x86_64 dbus-broker-21-6.fc31.x86_64 dbus-common-1.12.16-3.fc31.noarch dbus-daemon-1.12.16-3.fc31.x86_64 dbus-glib-0.110-6.fc31.x86_64 dbus-libs-1.12.16-3.fc31.i686 dbus-libs-1.12.16-3.fc31.x86_64 dbus-tools-1.12.16-3.fc31.x86_64 dbus-x11-1.12.16-3.fc31.x86_64 systemd-243.7-1.fc31.x86_64 systemd-libs-243.7-1.fc31.i686 systemd-libs-243.7-1.fc31.x86_64 - Samba server running v3.0.24 (Dlink DNS-323 NAS). How reproducible: Steps to Reproduce: 1. Added "client min protocol = NT1" to smb.conf on Fedora 31 client (for NT1/SMB1 compatibility). 2. Start Nautilus file manager 3. Access network share which appears under Other Locations -> Networks. 4. Access a random directory in the share. 5. The files listed in any directory randomly show as directories when they are actually files. Retrying to access the directory/file several times may eventually allow you to view the file. 6. If I copy a local file to the share, when I try to access the remote file to delete it, I get "There was an error reading the folder ... Not a directory". 7. I've had no issues on Fedora 30, this issue is clearly caused by the Fedora 31 update. 8. If even tried to access the smb mount in Nautilus with GVFSD running in foreground mode a terminal window: GVFS_DEBUG=1 GVFS_SMB_DEBUG=10 /usr/libexec/gvfsd -r 9. I see repeated errors when trying to access random files. The files in the Windows shares are incorrectly represented as directories. Error is as follows: SMBC_check_options(): server='rmtdns' share='volume_1' path='\file.png' options='' num_setup=1, max_setup=0, param_total=108, this_param=108, max_param=2, data_total=0, this_data=0, max_data=65535, param_offset=68, param_pad=0, param_disp=0, data_offset=176, data_pad=0, data_disp=0 num_setup=1, max_setup=0, param_total=118, this_param=118, max_param=10, data_total=0, this_data=0, max_data=65535, param_offset=68, param_pad=0, param_disp=0, data_offset=188, data_pad=2, data_disp=0 map_errno_from_nt_status: 32 bit codes: code=c0000103 smbc errno NT_STATUS_NOT_A_DIRECTORY -> 20 10. Even when I try to read/write a file by accessing the GVFS smb mount at "/run/user/<uid>/gvfs/<smbmount>/<some_directory>/<some_file>", it also incorrectly represents files as directories. Actual results: - I cannot complete any file read/write operations in any directory. Expected results: - Nautilus should allow me to read/write any file from my Fedora system onto the Windows share as I was able to on Fedora 30. Additional info: - Executing the following from my Fedora machine connects and allows me to read/write files with no issues: $ smbclient //192.168.1.5/Volume_1 - Since I am able to use smbclient to get/put files to the Windows share, something tells me that the problem is the Samba but another component (GVFSD?).
Correction to my last sentence above: - Since I am able to use smbclient to get/put files to the Windows share, something tells me that the problem is NOT Samba but another component (GVFSD?). Does GVFS require a parameter or option to force the mount to use NT1?
Additional debug information when trying to access a PDF smb: Queued new job 0x5637d266d130 (GVfsJobQueryFsInfo) smbc_stat(smb://rmtdns/volume_1/Backup/Downloads/Sample.pdf) SMBC_getatr: sending qpathinfo num_setup=1, max_setup=0, param_total=94, this_param=94, max_param=2, data_total=0, this_data=0, max_data=65535, param_offset=68, param_pad=0, param_disp=0, data_offset=164, data_pad=2, data_disp=0 num_setup=1, max_setup=0, param_total=10, this_param=10, max_param=2, data_total=0, this_data=0, max_data=100, param_offset=68, param_pad=0, param_disp=0, data_offset=80, data_pad=2, data_disp=0 num_setup=1, max_setup=0, param_total=94, this_param=94, max_param=2, data_total=0, this_data=0, max_data=65535, param_offset=68, param_pad=0, param_disp=0, data_offset=164, data_pad=2, data_disp=0 num_setup=1, max_setup=0, param_total=94, this_param=94, max_param=2, data_total=0, this_data=0, max_data=65535, param_offset=68, param_pad=0, param_disp=0, data_offset=164, data_pad=2, data_disp=0 map_open_params_to_ntcreate: fname = \rmtdns\volume_1\Backup\Downloads\Sample.pdf, deny_mode = 0x40, open_func = 0x1 map_open_params_to_ntcreate: file \rmtdns\volume_1\Backup\Downloads\Sample.pdf, access_mask = 0x120089, share_mode = 0x3, create_disposition = 0x1, create_options = 0x40 private_flags = 0x0 num_setup=1, max_setup=0, param_total=2, this_param=2, max_param=0, data_total=0, this_data=0, max_data=560, param_offset=68, param_pad=0, param_disp=0, data_offset=72, data_pad=2, data_disp=0 num_setup=1, max_setup=0, param_total=2, this_param=2, max_param=0, data_total=0, this_data=0, max_data=560, param_offset=68, param_pad=0, param_disp=0, data_offset=72, data_pad=2, data_disp=0 smb: send_reply(0x5637d266d130), failed=0 () smb: backend_dbus_handler org.gtk.vfs.Mount:CreateDirectoryMonitor (pid=180334) smb: Queued new job 0x5637d266d1c0 (GVfsJobCreateMonitor) smb: send_reply(0x5637d266d1c0), failed=1 (Operation not supported) <--------------------- Error here, Nautilus display error "Not a directory" since it thinks it's a directory smb: backend_dbus_handler org.gtk.vfs.Mount:Enumerate (pid=180334)
Thanks for your report. I am not aware of any recent gvfs changes which could cause this, also I do not see this behavior with the same gvfs/libsmbclient versions. Can you please provide a full debug log? Can you also provide "gio info" output for some of those problematic files (it might be good to try it several times to see if it always shows the same for standard::type, standard::content-type...)? Unfortunately, smbclient util doesn't use the same API as gvfs backend if I am not mistaken, so this might still be a bug in libsmbclient library.
As requested, I've attached a full debug log when trying to access the "fun_plug" file. Using smbclient works fine, the issue seems to be only via GVFS.
Created attachment 1664047 [details] GVFSD debug log Output of "GVFS_DEBUG=1 GVFS_SMB_DEBUG=10 /usr/libexec/gvfsd -r" command
My workstation /etc/samba/smb.conf is as follows: [global] workgroup = workgroup security = user passdb backend = tdbsam printing = cups printcap name = cups load printers = yes cups options = raw client min protocol = NT1 client max protocol = NT1 client use spnego = no client ntlmv2 auth = no [homes] comment = Home Directories valid users = %S, %D%w%S browseable = No read only = No inherit acls = Yes [printers] comment = All Printers path = /var/tmp printable = Yes create mask = 0600 browseable = No [print$] comment = Printer Drivers path = /var/lib/samba/drivers write list = @printadmin root force group = @printadmin create mask = 0664 directory mask = 0775 I read somewhere that I needed to set the "client max protocol" for SMB1 support as well, particularly, when using the GVFS (libsmbclient). As for options "client use spnego = no" and "client ntlmv2 auth = no", I believe some defaults changed in the latest samba release which required that these be explicitly set.
Thanks for the log. Although, you haven't provided output from "gio info", I'm quite sure that this file type was returned from smbc_stat. So Nautilus thinks that it is a directory and consequent "Not a directory" error from smbc_opendir is expected. But what is interesting that also smbc_statvfs returned "Not a directory". smbc_statvfs should work for properly for all kinds of files and this error is not expected. This makes me think that also libsmbclient internally thinks that it is a folder and calls some folder specific code. I would suggest downgrading your samba packages and you will see...
Obviously there are more issues like this https://bugzilla.redhat.com/show_bug.cgi?id=1801442, https://bugzilla.redhat.com/show_bug.cgi?id=1797875...
I'll try downgrading Samba to see. Here is the "gio info" output you requested: $ gio info smb://rmtdns/volume_1/fun_plug display name: fun_plug edit name: fun_plug name: fun_plug type: regular size: 1767 uri: smb://rmtdns/volume_1/fun_plug attributes: standard::type: 1 standard::name: fun_plug standard::display-name: fun_plug standard::edit-name: fun_plug standard::icon: application-octet-stream, application-x-generic, application-octet-stream-symbolic, application-x-generic-symbolic standard::content-type: application/octet-stream standard::size: 1767 standard::allocated-size: 2048 standard::symbolic-icon: application-octet-stream-symbolic, application-x-generic-symbolic, application-octet-stream, application-x-generic etag::value: 1581905302 id::filesystem: smb-share:server=rmtdns,share=volume_1 access::can-write: TRUE access::can-trash: FALSE time::modified: 1581905302 time::modified-usec: 0 time::access: 1582120845 time::access-usec: 0 time::changed: 1581905302 time::changed-usec: 0 unix::device: 2971513676 unix::inode: 18446744072543450713 metadata::evince::continuous: 1 metadata::evince::dual-page: 0 metadata::evince::dual-page-odd-left: 0 metadata::evince::fullscreen: 0 metadata::evince::inverted-colors: 0 metadata::evince::sidebar_page: thumbnails metadata::evince::sidebar_size: 132 metadata::evince::sidebar_visibility: 1 metadata::evince::sizing_mode: fit-width metadata::evince::window_maximized: 0 metadata::evince::zoom: 1 metadata::nautilus-list-view-sort-column: name metadata::nautilus-list-view-sort-reversed: false
I've downgraded samba to 4.11.0-3 and things work. As you stated, some code was introduced in the latest samba update (4.11.6-0) that broke things. Could we have this code regression fixed?
*** This bug has been marked as a duplicate of bug 1801442 ***