Your message dated Wed, 30 Sep 2026 18:02:29 +0200
with message-id <[email protected]>
and subject line Re: Bug#1059418: nemo stops attempting to mount SMB servers or
shares if an incorrect password is "remembered"
has caused the Debian Bug report #1059418,
regarding nemo stops attempting to mount SMB servers or shares if an incorrect
password is "remembered"
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
1059418: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059418
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: nemo
Version: 5.6.4-1
Severity: important
X-Debbugs-Cc: [email protected]
Dear Maintainer,
nemo (or some underlying system that nemo uses) has a bug where SMB
share/server
mounting will lock up, if an incorrect password was entered previously and the
password was set to be remembered (for a session or forever).
It is possible that the password remember option is not necessary to lock up
nemo,
however I have not tested this.
During this "lock up" state, nemo will appear to be mounting the server/share,
with
the dialog "Opening <servername> (File Sharing)" and the message "You can stop
this
operation by clicking cancel". However, this dialog will never go away and the
server
or share will never mount.
Steps to reproduce:
1. Click on a server/share entry in the "Network" tab
2. Input incorrect credentials
3. Click on one of the remember credentials options (although this may not be
necessary for bug repro)
4. Retry connecting to the server/share again
In this bugged state, the incorrect credentials cannot be removed from memory,
as it does not show up under seahorse. I am assuming that the previous
operation
with the incorrect credentials did not succeed, so it didn't save to the
keystore
yet, but nemo is still waiting on that previous operation to finish, creating
some
sort of deadlock.
Eric
-- System Information:
Debian Release: 12.4
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.1.0-16-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages nemo depends on:
ii cinnamon-desktop-data 5.6.1-1
ii desktop-file-utils 0.26-1
ii gsettings-desktop-schemas 43.0-1
ii gvfs 1.50.3-1
ii libatk1.0-0 2.46.0-5
ii libc6 2.36-9+deb12u3
ii libcairo-gobject2 1.16.0-7
ii libcairo2 1.16.0-7
ii libcinnamon-desktop4 5.6.1-1
ii libexempi8 2.6.3-1
ii libexif12 0.6.24-1+b1
ii libgail-3-0 3.24.38-2~deb12u1
ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1
ii libglib2.0-0 2.74.6-2
ii libglib2.0-data 2.74.6-2
ii libgsf-1-114 1.14.50-1
ii libgtk-3-0 3.24.38-2~deb12u1
ii libnemo-extension1 5.6.4-1
ii libpango-1.0-0 1.50.12+ds-1
ii libpangocairo-1.0-0 1.50.12+ds-1
ii libselinux1 3.4-1+b6
ii libx11-6 2:1.8.4-2+deb12u2
ii libxapp1 2.4.2-3
ii libxml2 2.9.14+dfsg-1.3~deb12u1
ii nemo-data 5.6.4-1
ii shared-mime-info 2.2-1
Versions of packages nemo recommends:
ii catdoc 1:0.95-5
ii cinnamon-l10n 5.6.1-2
ii exif 0.6.22-3
ii gnome-disk-utility 43.0-1
ii gvfs-backends 1.50.3-1
ii gvfs-fuse 1.50.3-1
ii html2text 1.3.2a-28
ii id3 1.1.2-3
ii librsvg2-common 2.54.7+dfsg-1~deb12u1
ii nemo-fileroller 5.6.1-1
ii odt2txt 0.5-7
ii poppler-utils 22.12.0-2+b1
ii python3 3.11.2-1+b1
ii python3-xlrd 1.2.0-3
ii untex 1:1.2-7
Versions of packages nemo suggests:
ii eog 43.2-1
ii evince [pdf-viewer] 43.1-2+b1
ii totem 43.0-2
ii xdg-user-dirs 0.18-1
-- no debconf information
--- End Message ---
--- Begin Message ---
Version: 1.52.2-1
Hi Eric,
sorry for the very late reply. The authentication and the mount are done
by gvfs, not by nemo, and what you describe matches a gvfs bug [1]: the
smb backend of gvfs 1.50 can loop forever on "permission denied" without
asking for the credentials again, so the mount never completes. It was
fixed upstream in gvfs 1.52.2, while bookworm still has 1.50.3.
I could not reproduce it on trixie (nemo 6.4.5, gvfs 1.57.2): after a
wrong password, remembered or not, the authentication dialog comes back
and the mount works with the right one. I have therefore reassigned the
bug to gvfs and I'm closing it with the first version that has the fix.
If you still see it on trixie or later, please let us know.
[1] https://gitlab.gnome.org/GNOME/gvfs/-/issues/703
Thanks,
Fabio
OpenPGP_signature.asc
Description: OpenPGP digital signature
--- End Message ---
