Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Hello Ondro, I am hitting the same issue in RHEL, would it be possible to backport this ?
gvfs-client-1.48.1-3.el9.x86_64
gvfs-1.48.1-3.el9.x86_64
gvfs-fuse-1.48.1-3.el9.x86_64
gvfs-goa-1.48.1-3.el9.x86_64
gvfs-gphoto2-1.48.1-3.el9.x86_64
gvfs-mtp-1.48.1-3.el9.x86_64
gvfs-smb-1.48.1-3.el9.x86_64
+++ This bug was initially created as a clone of Bug #2068976 +++
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.
--- Additional comment from Chris Murphy on 2022-03-28 01:18:43 UTC ---
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
--- Additional comment from Chris Murphy on 2022-03-28 01:20:20 UTC ---
gnome-shell-42~rc-3.fc36.x86_64
gvfs-smb-1.50.0-2.fc36.x86_64
--- Additional comment from Chris Murphy on 2022-03-28 01:37:11 UTC ---
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)
--- Additional comment from Chris Murphy on 2022-03-28 02:40:00 UTC ---
Looks related.
https://gitlab.gnome.org/GNOME/gvfs/-/issues/611
--- Additional comment from Guenther Deschner on 2022-03-30 09:51:28 UTC ---
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.
--- Additional comment from Guenther Deschner on 2022-03-30 11:13:31 UTC ---
Testbuilds available here: https://koji.fedoraproject.org/koji/taskinfo?taskID=84929948
--- Additional comment from Chris Murphy on 2022-03-31 18:26:54 UTC ---
libsmbclient-2:4.16.0-7.fc36.x86_64 is working OK.
--- Additional comment from Adam Williamson on 2022-04-01 19:33:15 UTC ---
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!
--- Additional comment from Chris Murphy on 2022-04-02 00:03:37 UTC ---
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.
--- Additional comment from Adam Williamson on 2022-04-02 00:44:59 UTC ---
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.
--- Additional comment from Ondrej Holy on 2022-04-13 08:39:28 UTC ---
As per the upstream report, this seems should be fixed in gvfs instead.
--- Additional comment from Fedora Update System on 2022-04-13 09:39:01 UTC ---
FEDORA-2022-84703f9ea7 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-84703f9ea7
--- Additional comment from Fedora Update System on 2022-04-13 19:49:11 UTC ---
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.
--- Additional comment from Martin Wolf on 2022-04-28 09:51:55 UTC ---
I am on gvfs-1.50.1-1.fc36 but I still get the error message above: Failed to mount Windows share: Invalid argument
--- Additional comment from Martin Wolf on 2022-04-28 10:05:45 UTC ---
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
--- Additional comment from on 2022-05-01 09:43:40 UTC ---
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.
--- Additional comment from on 2022-05-01 10:30:45 UTC ---
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.
--- Additional comment from Andreas Schneider on 2022-05-01 18:15:54 UTC ---
In your smb.conf set `client use kerberos = off` as a workaround till Gnome gets fixed.
--- Additional comment from on 2022-05-01 18:58:02 UTC ---
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.
--- Additional comment from tiberias on 2022-05-02 17:11:30 UTC ---
@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.
--- Additional comment from Ondrej Holy on 2022-05-04 10:17:17 UTC ---
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?
--- Additional comment from on 2022-05-04 10:39:25 UTC ---
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
--- Additional comment from on 2022-05-04 10:45:53 UTC ---
Ok drag and drop doesn't work, no obvious file upload button. Sorry for the spam. We'll try this https://pastebin.com/m0UDFnby.
--- Additional comment from Ondrej Holy on 2022-05-04 11:32:11 UTC ---
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).
--- Additional comment from on 2022-05-04 11:48:34 UTC ---
Here is debug log for gvfs-1.50.0-2.fc36 and libsmbclient-2:4.15.7-0.fc35.
--- Additional comment from Ondrej Holy on 2022-05-05 06:21:12 UTC ---
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...
--- Additional comment from on 2022-05-05 09:39:08 UTC ---
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.
--- Additional comment from Ondrej Holy on 2022-05-05 10:54:11 UTC ---
No, thanks. I needed a debug log from people which claim that gvfs-1.50.1 doesn't fix their issue...
--- Additional comment from Fedora Update System on 2022-05-05 10:56:39 UTC ---
FEDORA-2022-fe23fcfb82 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-fe23fcfb82
--- Additional comment from Ondrej Holy on 2022-05-05 10:57:58 UTC ---
I've just pushed a new update, which should fix an anonymous login issue, Martin Wolf, does it work for you?
--- Additional comment from Martin Wolf on 2022-05-05 11:10:15 UTC ---
Yes it works, thank you for fixing it.
I really appreciate it!
--- Additional comment from Daniele Viganò on 2022-05-05 19:07:21 UTC ---
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
--- Additional comment from Ondrej Holy on 2022-05-06 09:14:27 UTC ---
(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.
--- Additional comment from Fedora Update System on 2022-05-06 11:01:48 UTC ---
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.
--- Additional comment from Ludovic Gruttadauria on 2022-05-06 12:31:30 UTC ---
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
--- Additional comment from Fedora Update System on 2022-05-10 01:54:10 UTC ---
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.
This is tested by soffice_save_file_to_samba in LibreOffice test suite.
gvfs-client-1.48.1-4.el9.x86_64
gvfs-debugsource-1.48.1-4.el9.x86_64
gvfs-debuginfo-1.48.1-4.el9.x86_64
gvfs-1.48.1-4.el9.x86_64
gvfs-tests-1.48.1-4.el9.x86_64
gvfs-fuse-1.48.1-4.el9.x86_64
gvfs-mtp-1.48.1-4.el9.x86_64
gvfs-goa-1.48.1-4.el9.x86_64
gvfs-gphoto2-1.48.1-4.el9.x86_64
gvfs-smb-1.48.1-4.el9.x86_64
gvfs-goa-debuginfo-1.48.1-4.el9.x86_64
gvfs-fuse-debuginfo-1.48.1-4.el9.x86_64
gvfs-mtp-debuginfo-1.48.1-4.el9.x86_64
gvfs-smb-debuginfo-1.48.1-4.el9.x86_64
gvfs-gphoto2-debuginfo-1.48.1-4.el9.x86_64
gvfs-client-debuginfo-1.48.1-4
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory (gvfs bug fix and enhancement update), and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://access.redhat.com/errata/RHBA-2022:8140