Access to Windows Share stopped working

General system Kernel, boot, graphics & hardware
1

Hi all, don’t know if it fits here, but I’m clueless…

I have a Windows Laptop I can access a Windows Share in my company’s LAN. This still works.

I have my own laptop and could access this share until ~ 25th of January then it suddenly stopped working. No changes on my side regarding passwords etc. I still have a request pending at my company to tell me if there has been a change on share configuration, but I suppose no changes as share is used by > 2000 users.

Access is being done through working VPN. When I try to mount the share with

sudo mount -vvv -t cifs //xxxxxxxx/yyyyyyy /mnt/zzzzzzzz/ -o user=uuuuuuuu,uid=1000,gid=1000,password=pppppppp

I get a
mount error(13): Permission denied
and
[ 1903.366571] CIFS: No dialect specified on mount. Default has changed to a more secure dialect, SMB2.1 or later (e.g. SMB3.1.1), from CIFS (SMB1). To use the less secure SMB1 dialect to access old servers which do not support SMB3.1.1 (or even SMB3 or SMB2.1) specify vers=1.0 on mount.
[ 1903.366573] CIFS: Attempting to mount \xxxxxxxxxxxx
[ 1903.506082] CIFS: Status code returned 0xc000006d STATUS_LOGON_FAILURE
[ 1903.506099] CIFS: VFS: \xxxxxxxxxxxxxx Send error in SessSetup = -13
[ 1903.506137] CIFS: VFS: cifs_mount failed w/return code = -13

trying
sudo mount -vvv -t cifs //xxxxxxxxxxxx/yyyyyyyyyyy /mnt/zzzzzzzzz/ -o user=uuuuuuuuuuuuu,uid=1000,gid=1000,password=pppppppppp,domain=xxxxxxxxx,vers=3.1.1 returns a
mount.cifs kernel mount options: ip=iii.iii.iii.iii,unc=\xxxxxxxxx\yyyyyyyyyyy,vers=3.1.1,uid=1000,gid=1000,user=uuuuuuuuu,domain=xxxxxxxxxxx,pass=********
mount error(13): Permission denied
and a dmesg
[ 2010.707588] CIFS: Attempting to mount \xxxxxxxxx\yyyyyyyy
[ 2010.842411] CIFS: Status code returned 0xc000006d STATUS_LOGON_FAILURE
[ 2010.842432] CIFS: VFS: \xxxxxxxxxxxxxxxxxxx Send error in SessSetup = -13
[ 2010.842476] CIFS: VFS: cifs_mount failed w/return code = -13

Trying a “smb://SERVERNAME” in dolphin returns a list of all shares on that server.

As I said I didn’t change anything reg. mounts or passwords. There was an update to smbclient and of course to the linux-kernel in between that could have broken things.

Anybody out there with a similar problem / error or an odea where to investigate? I already tried some commands from this site (https://www.whitehat.de/smb-enumeration-checkliste-cheat-sheet) but no useful output.

Thanks!

2

If I am understanding the error message correctly, maybe you should try to mouth using your second method but specifying vers=1.0 - something like this:

sudo mount -vvv -t cifs //xxxxxxxxxxxx/yyyyyyyyyyy /mnt/zzzzzzzzz/ -o user=uuuuuuuuuuuuu,uid=1000,gid=1000,password=pppppppppp,domain=xxxxxxxxx,vers=1.0

At least, that would be easy to try?

3

tried vers=1.0 and 2.1, 3.1.1…

none worked …

4

Dolphin suggests you are using KDE.

Try installing the packages gvfs and gvfs-smb

You could try to use

gio mount smb://server/share

I know you say is has worked - so check the file - you should have something specifying the dialect (NT1 being the deprecated SMB1) - the file is a requirement - albeit content is not :slight_smile:

/etc/samba/smb.conf

[global]
  min version = NT1
  workgroup = WORKGROUP
5

Another (temporary) option would be to downgrade the offending version of smbclient, if that was what changed when the trouble started. You could take a look at the /var/log/pacman.log file to make sure before hand - and choose a recent local version to find the one that works.

The command would be: sudo downgrade smbclient if it was smbclient that caused the problem. Just running an upgrade again would return the situation to as it is now (or better) if it doesn’t solve (or delay) the problem.

6

Thanks for your ideas. The gio stuff is GNOME and as I’m using KDE I give the downgrade idea a try first.

Looking at the output of (hopefully involved) updated packages I only found kernel and smbclient.

cat /var/log/pacman.log | grep -i ‘smb|samba|cifs|linux-headers’
fresh endeavour 7.12. - birthday after switching from kubuntu :wink:
[2021-12-07T17:29:22+0100] [ALPM] installed linux-headers (5.15.6.arch2-1)
[2021-12-07T17:31:36+0100] [ALPM] installed cifs-utils (6.14-1)
[2021-12-07T17:31:36+0100] [ALPM] installed smbclient (4.15.2-3)
[2021-12-09T15:08:15+0100] [ALPM] upgraded linux-headers (5.15.6.arch2-1 → 5.15.7.arch1-1)
[2021-12-10T07:59:13+0100] [ALPM] installed libsmbios (2.4.3-3)
[2021-12-13T08:03:58+0100] [ALPM] upgraded libsmbios (2.4.3-3 → 2.4.3-5)
[2021-12-13T08:03:59+0100] [ALPM] upgraded smbclient (4.15.2-3 → 4.15.3-2)
[2021-12-15T18:04:11+0100] [ALPM] upgraded linux-headers (5.15.7.arch1-1 → 5.15.8.arch1-1)
[2021-12-18T09:52:40+0100] [ALPM] upgraded linux-headers (5.15.8.arch1-1 → 5.15.10.arch1-1)
[2021-12-24T16:06:43+0100] [ALPM] upgraded linux-headers (5.15.10.arch1-1 → 5.15.11.arch2-1)
[2021-12-30T17:01:06+0100] [ALPM] upgraded linux-headers (5.15.11.arch2-1 → 5.15.12.arch1-1)
[2022-01-15T21:45:00+0100] [ALPM] upgraded linux-headers (5.15.12.arch1-1 → 5.16.arch1-1)
[2022-01-17T10:59:33+0100] [ALPM] upgraded linux-headers (5.16.arch1-1 → 5.16.1.arch1-1)

critical date where things could have stopped working…
[2022-01-20T11:43:17+0100] [ALPM] upgraded smbclient (4.15.3-2 → 4.15.4-1)
[2022-01-21T15:18:38+0100] [ALPM] upgraded linux-headers (5.16.1.arch1-1 → 5.16.2.arch1-1)
[2022-01-29T09:20:57+0100] [ALPM] upgraded linux-headers (5.16.2.arch1-1 → 5.16.3.arch1-1)
[2022-01-29T11:54:56+0100] [PACMAN] Running ‘/usr/bin/pacman -Rsn linux linux-headers’
[2022-01-29T11:55:06+0100] [ALPM] removed linux-headers (5.16.3.arch1-1)
[2022-01-31T07:15:43+0100] [ALPM] upgraded smbclient (4.15.4-1 → 4.15.4-2)
[2022-02-01T13:19:42+0100] [ALPM] upgraded smbclient (4.15.4-2 → 4.15.5-1)
[2022-02-01T19:40:37+0100] [PACMAN] Running ‘/usr/bin/pacman -S core/linux core/linux-headers’
[2022-02-01T19:40:56+0100] [ALPM] installed linux-headers (5.16.4.arch1-1)
[2022-02-03T14:56:41+0100] [ALPM] upgraded linux-headers (5.16.4.arch1-1 → 5.16.5.arch1-1)

I’ll downgrade to smbclient 4.15.3-2 - let’s see. Although the cifs stuff is being done by the kernel, right?! Trial and error. It can be tested in minutes :wink:

1 Like
7

Hmm, meanwhile I tried things in two VMs I installed in December and January (Kali, Endeavour) - non of them works. So my conclusion is that there must have been a change in configuration on server side in our company. I hope I get a skilled admin to tell me what happened and how I can work around this…

Thanks up to here.

I’ll update this topic when I know the cause for it. :+1:

8

Technically you are correct.

It is next to impossible to have a system using only one toolkit - even limiting the number of toolkit versions can be a challenge.

So I reckon you already have glib and possibly gvfs so adding gvfs-smb wouldn’t present any significant burden :slight_smile: but it could brighten your day.

9

I found a solution - may be not the root cause - but with my domain login it worked. I don’t know what changed on server side but altering the options in fstab

from:
… user=surname.name@mycompany.com,password=MyPassword …

to:
… user=name,domain=MyCompanyDomain,password=MyPassword …

it now works again.

Thanks for any help and hints guys!

1 Like
10

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.