Description of problem: Version-Release number of selected component (if applicable): Last working version samba-client-2:4.16.0-0.2.rc3.fc36.x86_64 First failing version samba-client-2:4.16.0-6.fc36.x86_64 How reproducible: Always Steps to Reproduce: 1. In Nautilus go to Other Locations, Fedora Server shows up 2. double click on the Fedora Server 3. the shares show up, double click one of them Actual results: Dialog says Unable to access location Failed to mount Windows share: Invalid argument Nothing is recorded in the journal. Expected results: Should get an authentication dialog. Additional info: There are intermediate updates available in koji, I'll test those to see if this can be narrowed down.
samba-client-2:4.16.0-0.4.rc4.fc36.x86_64 is OK samba-client-2:4.16.0-0.5.rc5.fc36.x86_64 is OK samba-client-2:4.16.0-6.fc36.x86_64 fails as described
gnome-shell-42~rc-3.fc36.x86_64 gvfs-smb-1.50.0-2.fc36.x86_64
smb-network: backend_dbus_handler org.gtk.vfs.Mount:MountMountable (pid=4824) smb-network: Queued new job 0x55a1acd1f530 (GVfsJobMountMountable) smb-network: send_reply(0x55a1acd1f530), failed=0 () smb: g_vfs_backend_smb_init: default workgroup = 'NULL' smb: Added new job source 0x562d4a0df080 (GVfsBackendSmb) smb: Queued new job 0x562d4a0e01a0 (GVfsJobMount) INFO: Current debug levels: all: 10 tdb: 10 printdrivers: 10 lanman: 10 smb: 10 rpc_parse: 10 rpc_srv: 10 rpc_cli: 10 passdb: 10 sam: 10 auth: 10 winbind: 10 vfs: 10 idmap: 10 quota: 10 acls: 10 locking: 10 msdfs: 10 dmapi: 10 registry: 10 scavenger: 10 dns: 10 ldb: 10 tevent: 10 auth_audit: 10 auth_json_audit: 10 kerberos: 10 drs_repl: 10 smb2: 10 smb2_credits: 10 dsdb_audit: 10 dsdb_json_audit: 10 dsdb_password_audit: 10 dsdb_password_json_audit: 10 dsdb_transaction_audit: 10 dsdb_transaction_json_audit: 10 dsdb_group_audit: 10 dsdb_group_json_audit: 10 Using netbios name FOVO. Using workgroup SAMBA. smb: do_mount - URI = smb://fnuc.local/finance smb: do_mount - try #0 smbc_stat(smb://fnuc.local/finance) smb: auth_callback - kerberos pass smb: auth_callback - out: last_user = 'chris', last_domain = 'SAMBA' SMBC_server: server_n=[fnuc.local] server=[fnuc.local] -> server_n=[fnuc.local] server=[fnuc.local] Opening cache file at /var/lib/samba/lock/gencache.tdb tdb(/var/lib/samba/lock/gencache.tdb): tdb_open_ex: could not open file /var/lib/samba/lock/gencache.tdb: Permission denied gencache_init: Opening user cache file /home/chris/.cache/samba/gencache.tdb. sitename_fetch: No stored sitename for realm '' internal_resolve_name: looking up fnuc.local#20 (sitename (null)) namecache_fetch: name fnuc.local#20 found. remove_duplicate_addrs2: looking for duplicate address/port pairs Connecting to 10.0.0.249 at port 445 socket options: SO_KEEPALIVE=0, SO_REUSEADDR=0, SO_BROADCAST=0, TCP_NODELAY=1, TCP_KEEPCNT=9, TCP_KEEPIDLE=7200, TCP_KEEPINTVL=75, IPTOS_LOWDELAY=0, IPTOS_THROUGHPUT=0, SO_REUSEPORT=0, SO_SNDBUF=87040, SO_RCVBUF=131072, SO_SNDLOWAT=1, SO_RCVLOWAT=1, SO_SNDTIMEO=0, SO_RCVTIMEO=0, TCP_QUICKACK=1, TCP_DEFER_ACCEPT=0, TCP_USER_TIMEOUT=0 cli_session_setup_spnego_send: Connect to fnuc.local as chris@SAMBA using SPNEGO GENSEC backend 'gssapi_spnego' registered GENSEC backend 'gssapi_krb5' registered GENSEC backend 'gssapi_krb5_sasl' registered GENSEC backend 'spnego' registered GENSEC backend 'schannel' registered GENSEC backend 'ncalrpc_as_system' registered GENSEC backend 'sasl-EXTERNAL' registered GENSEC backend 'ntlmssp' registered GENSEC backend 'ntlmssp_resume_ccache' registered GENSEC backend 'http_basic' registered GENSEC backend 'http_ntlm' registered GENSEC backend 'http_negotiate' registered Starting GENSEC mechanism spnego Starting GENSEC submechanism gse_krb5 smb_gss_krb5_import_cred ccache[KCM:1000] failed with [No credentials were supplied, or the credentials were unavailable or inaccessible: No credentials cache found] -the caller may retry after a kinit. Failed to start GENSEC client mech gse_krb5: NT_STATUS_INTERNAL_ERROR gensec_spnego_client_negTokenInit_step: Could not find a suitable mechtype in NEG_TOKEN_INIT gensec_update_send: spnego[0x7f7ed801c150]: subreq: 0x7f7ed80230c0 gensec_update_done: spnego[0x7f7ed801c150]: NT_STATUS_INVALID_PARAMETER tevent_req[0x7f7ed80230c0/../../auth/gensec/spnego.c:1631]: state[3] error[-7963671676338569203 (0x917B5ACDC000000D)] state[struct gensec_spnego_update_state (0x7f7ed8023280)] timer[(nil)] finish[../../auth/gensec/spnego.c:1947] SPNEGO login failed: An invalid parameter was passed to a service or function. map_errno_from_nt_status: 32 bit codes: code=c000000d smb: do_mount - [smb://fnuc.local/finance; 0] res = -1, cancelled = 0, errno = [22] 'Invalid argument' smb: do_mount - (errno != EPERM && errno != EACCES), cancelled = 0, breaking smb: send_reply(0x562d4a0e01a0), failed=1 (Failed to mount Windows share: Invalid argument)
Looks related. https://gitlab.gnome.org/GNOME/gvfs/-/issues/611
Most likely it is related to this change that went in between rc5 and 4.16.0 final: https://gitlab.com/samba-team/samba/-/commit/34771e1931587807d0395c7ac7f4be18654997f4 I'll create a test build reverting only that patch.
Testbuilds available here: https://koji.fedoraproject.org/koji/taskinfo?taskID=84929948
libsmbclient-2:4.16.0-7.fc36.x86_64 is working OK.
Proposing this as a Final freeze exception, this is the kinda thing people will want to do from live environments so fixing it wiht an update would not be sufficient. Can we do an official build/update with the revert, if a proper fix can't be found? Thanks!
Bad version shouldn't have made it to stable, I gave it negative karma when I discovered the bug. It would be one of the working 4.16 release candidates (rc5?) that'd end up on the final release media though without a freeze exception.
oh, yeah, indeed. Doesn't need an FE then, unless we really want the final release in stable. I've unpushed the update, no reason to leave a broken build in u-t.
As per the upstream report, this seems should be fixed in gvfs instead.
FEDORA-2022-84703f9ea7 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-84703f9ea7
FEDORA-2022-84703f9ea7 has been pushed to the Fedora 36 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-84703f9ea7` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-84703f9ea7 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
I am on gvfs-1.50.1-1.fc36 but I still get the error message above: Failed to mount Windows share: Invalid argument
it seems it does not do anonymous login, because I did not select that user@domain Apr 28 12:03:55 el-ryzerino gvfsd[7405]: Kerberos auth with 'martin@SAMBA' (SAMBA\martin) to access '10.0.0.4' not possible Apr 28 12:04:25 el-ryzerino gvfsd[7431]: Kerberos auth with 'martin@SAMBA' (SAMBA\martin) to access '10.0.0.4' not possible
Was just bitten by this bug on Fedora 35 when I upgraded to libsmbclient-2:4.15.7-0.fc35.x86_64, problem was solved by downgrading back down to libsmbclient-2:4.15.0-13.fc35.x86_64. Been trying to figure out how this update made its way to stable but I can't find the listing for any of the packages on Bodhi.
Same here as @jaskerx, as of this morning the update on Fedora 35 Workstation forces to use smb://username.x.x/share in order to get into an SMB share in the network here, to avoid the error message first seen on Fedora beta 36.
In your smb.conf set `client use kerberos = off` as a workaround till Gnome gets fixed.
Tried putting `client use kerberos = off` in my /etc/samba/smb.conf but it didn't work, so I just downgraded again and added a dnf exclude rule for libsmbclient until this gets solved.
@jaskerx libsmbclient gets shipped with the samba package. This update (https://bodhi.fedoraproject.org/updates/FEDORA-2022-5c64120636) got also me in trouble, it went stable on Saturday. As it seems, none of the three testers did the "desktop network smb" test case.
I suppose that "client use kerberos = off" won't help as gvfsd-smb enables the kerberos support explicitly. Can you please be more concrete about what use-cases don't work with gvfs-1.50.1? Are all related to anonymous mode? If so, I am just working on a fix. If not, can you please provide debug log using https://wiki.gnome.org/Projects/gvfs/debugging with the GVFS_SMB_DEBUG=10 envar set?
Hopefully this is ok since I'm still using Fedora 35 and gvfs-1.48.1-2.fc35. Here is requested debug log. file:///home/jason/Downloads/gvfsd.log
Ok drag and drop doesn't work, no obvious file upload button. Sorry for the spam. We'll try this https://pastebin.com/m0UDFnby.
Thanks, but the log with gvfs-1.48.1 is useful. I really need the log with gvfs-1.50.1 (or 1.50.0-4 at least). You can try to update to gvfs version from Fedora 36, it might fix your issue (e.g. "sudo dnf update gvfs-smb --releasever=36" should work).
Created attachment 1877011 [details] gvfsd debug log Here is debug log for gvfs-1.50.0-2.fc36 and libsmbclient-2:4.15.7-0.fc35.
Thanks, but 1.50.0-2 is still too old. I haven't realized that it is still in testing, sorry. So "sudo dnf update gvfs-smb --releasever=36 --enabler=updates-testing" should be the command you need to get 1.50.1...
Happy to report that gvfs-1.50.1 fixes the issue and works well with libsmbclient-2:4.15.7-0. Let me know if you still want a debug log.
No, thanks. I needed a debug log from people which claim that gvfs-1.50.1 doesn't fix their issue...
FEDORA-2022-fe23fcfb82 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-fe23fcfb82
I've just pushed a new update, which should fix an anonymous login issue, Martin Wolf, does it work for you?
Yes it works, thank you for fixing it. I really appreciate it!
Running Fedora 35 here, already updated to gvfs-smb-1.50.1-2.fc36.x86_64 from https://bodhi.fedoraproject.org/updates/FEDORA-2022-fe23fcfb82 Still having issues with nautilus (smb://hpmicro/daniele/): "Failed to mount Windows share: Cannot allocate memory" INFO: Current debug levels: all: 10 tdb: 10 printdrivers: 10 lanman: 10 smb: 10 rpc_parse: 10 rpc_srv: 10 rpc_cli: 10 passdb: 10 sam: 10 auth: 10 winbind: 10 vfs: 10 idmap: 10 quota: 10 acls: 10 locking: 10 msdfs: 10 dmapi: 10 registry: 10 scavenger: 10 dns: 10 ldb: 10 tevent: 10 auth_audit: 10 auth_json_audit: 10 kerberos: 10 drs_repl: 10 smb2: 10 smb2_credits: 10 dsdb_audit: 10 dsdb_json_audit: 10 dsdb_password_audit: 10 dsdb_password_json_audit: 10 dsdb_transaction_audit: 10 dsdb_transaction_json_audit: 10 dsdb_group_audit: 10 dsdb_group_json_audit: 10 Using netbios name GEMLATITUDE5450. Using workgroup SAMBA. smbc_stat(smb://hpmicro/data/daniele) SMBC_server: server_n=[hpmicro] server=[hpmicro] -> server_n=[hpmicro] server=[hpmicro] Opening cache file at /var/lib/samba/lock/gencache.tdb tdb(/var/lib/samba/lock/gencache.tdb): tdb_open_ex: could not open file /var/lib/samba/lock/gencache.tdb: Permission denied gencache_init: Opening user cache file /home/daniele/.cache/samba/gencache.tdb. sitename_fetch: No stored sitename for realm '' internal_resolve_name: looking up hpmicro#20 (sitename (null)) namecache_fetch: name hpmicro#20 found. remove_duplicate_addrs2: looking for duplicate address/port pairs Connecting to 192.168.10.100 at port 445 socket options: SO_KEEPALIVE=0, SO_REUSEADDR=0, SO_BROADCAST=0, TCP_NODELAY=1, TCP_KEEPCNT=9, TCP_KEEPIDLE=7200, TCP_KEEPINTVL=75, IPTOS_LOWDELAY=0, IPTOS_THROUGHPUT=0, SO_REUSEPORT=0, SO_SNDBUF=87040, SO_RCVBUF=131072, SO_SNDLOWAT=1, SO_RCVLOWAT=1, SO_SNDTIMEO=0, SO_RCVTIMEO=0, TCP_QUICKACK=1, TCP_DEFER_ACCEPT=0, TCP_USER_TIMEOUT=0 cli_session_setup_spnego_send: Connect to hpmicro as daniele@SAMBA using SPNEGO GENSEC backend 'gssapi_spnego' registered GENSEC backend 'gssapi_krb5' registered GENSEC backend 'gssapi_krb5_sasl' registered GENSEC backend 'spnego' registered GENSEC backend 'schannel' registered GENSEC backend 'naclrpc_as_system' registered GENSEC backend 'sasl-EXTERNAL' registered GENSEC backend 'ntlmssp' registered GENSEC backend 'ntlmssp_resume_ccache' registered GENSEC backend 'http_basic' registered GENSEC backend 'http_ntlm' registered GENSEC backend 'http_negotiate' registered Starting GENSEC mechanism spnego Starting GENSEC submechanism gse_krb5 gensec_update_send: gse_krb5[0x7f2f90020e60]: subreq: 0x7f2f900050f0 gensec_update_send: spnego[0x7f2f9001b590]: subreq: 0x7f2f90022d90 gensec_update_done: gse_krb5[0x7f2f90020e60]: NT_STATUS_NO_MEMORY tevent_req[0x7f2f900050f0/../../source3/librpc/crypto/gse.c:848]: state[3] error[-7963671676338569193 (0x917B5ACDC0000017)] state[struct gensec_gse_update_state (0x7f2f900052b0)] timer[(nil)] finish[../../source3/librpc/crypto/gse.c:862] gensec_spnego_client_negTokenInit_step: gse_krb5: creating NEG_TOKEN_INIT for cifs/hpmicro failed (next[(null)]): NT_STATUS_NO_MEMORY gensec_update_done: spnego[0x7f2f9001b590]: NT_STATUS_NO_MEMORY tevent_req[0x7f2f90022d90/../../auth/gensec/spnego.c:1631]: state[3] error[-7963671676338569193 (0x917B5ACDC0000017)] state[struct gensec_spnego_update_state (0x7f2f90022f50)] timer[(nil)] finish[../../auth/gensec/spnego.c:2039] SPNEGO login failed: {Not Enough Quota} Not enough virtual memory or paging file quota is available to complete the specified operation. map_errno_from_nt_status: 32 bit codes: code=c0000017 It works fine with smb://daniele@hpmicro/daniele
(In reply to Daniele Viganò from comment #32) > Running Fedora 35 here, already updated to gvfs-smb-1.50.1-2.fc36.x86_64 > from https://bodhi.fedoraproject.org/updates/FEDORA-2022-fe23fcfb82 > > Still having issues with nautilus (smb://hpmicro/daniele/): "Failed to mount > Windows share: Cannot allocate memory" Please open a new bug report for this as it is a different error, thanks.
FEDORA-2022-fe23fcfb82 has been pushed to the Fedora 36 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-fe23fcfb82` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-fe23fcfb82 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
On FC35, i confirm that upgrading GVFS packages to recent version 1.48.1-3 solved the smb mounting issue with Gnome Files (Nautilus). See: https://bodhi.fedoraproject.org/updates/FEDORA-2022-45c9d57591 updated and tested ok. Bodhi Karma for this update already got three positive votes and now has been requested to stable. FC35 users can already get gvfs 1.48.1-3 packages from here: https://koji.fedoraproject.org/koji/buildinfo?buildID=1963021 Regards, Ludovic
FEDORA-2022-fe23fcfb82 has been pushed to the Fedora 36 stable repository. If problem still persists, please make note of it in this bug report.
*** Bug 2068867 has been marked as a duplicate of this bug. ***
this problem still persists in Fedora 37 / Gnome 43.1 with samba 4.17.3
This is issue is not fixed. Fedora 37 and RHEL 9.1. If I kinit a user it fails with error: Failed to mount share: Cannot allocate memory. It is working only if I kdestroy then I can mount it. I tried "client use kerberos = off" but it is not change anything. My samba server is not using kerberos, just local users. # gio list smb://WORKGROUP MYSERVER # gio mount smb://MYSERVER/mymedia gio: smb://myserver/mymedia/: Failed to mount Windows share: Cannot allocate memory #kdestroy then I can mount it without problem.