mac os catalina (10.15.7) cannot mount wiz shares

[Altimes]

This is a boringly recurrent issue with Apple. Apply updates and stuff that was working stops working This time, have allowed the latest security updates, I can no longer mount SMB shares from either U4 or T4 Wizen. Mac can mount smb shares off of Synolgy NAS and Win10 boxes, just not the Wiz. I've had a look around in the Wiz Samba log files and they shown no evidence of any issues. I can mount and access Mac share (NFS) onto Wiz which suggests no underlying network issue and suggesting a smb issue.

An attempt of a CLI mount on the Mac gives

mount_smbfs //guest@beyonwizt4.local/Movie ./junk
mount_smbfs: server connection failed: Socket is not connected

My google searching has not brought up anything useful.

Any Mac Users amongst us who either do, or don't see a similar issue ? And any samba gurus that can suggest an appropriate sequence of smbutil commands or any other tests that might help identify a root cause.

TIA.

Alan.

[MrQuade]

prl is possibly the best person to test this, as he is an Apple user, though he is away on holiday at the moment.

My only suggestion, is that since this sounds like a result of tightened security, then the OSX SMB stack isn't allowing the guest/anonymous connection.

You may try using the usernames "beyonwiz", or "Administrator", both of which are equivalent to the "root" user as far as the wiz is concerned.

I am not actually sure what the "root" user's default SMB password is (stored in /etc/samba/private/smbpasswd), it may actually be synchronised with your Beywonwiz's root password. (it looks like mine currently is my Wiz's root password, and I don't recall ever manually setting the SMB password).

[Altimes]

Thanks for that, yes my guess is that (*#$ Apple have gone over the top with "SECURITY". I have just tried using beyonwiz after using smbpasswd to set the password (you learn something new every time ). Sadly no change, but I many need to reboot the box (which is not possible for me currently).

The two are kind of talking to each other

smbutil status -a beyonwizt4
Using IP address of beyonwizt4: 192.168.1.20
NetBIOS Name Number Type Description
BEYONWIZT4 0x00 UNIQUE [Workstation Service]
BEYONWIZT4 0x03 UNIQUE [Messenger Service]
BEYONWIZT4 0x20 UNIQUE [File/Print Server Service]
__MSBROWSE__ 0x01 GROUP [Master Browser]
WORKGROUP 0x00 GROUP [Domain Name]
WORKGROUP 0x1d UNIQUE [Master Browser]
WORKGROUP 0x1e GROUP [Browser Service Elections]

But anything else that I try leads to a socked not connected complaint.

Alan

[MrQuade]

I have just tried using beyonwiz after using smbpasswd to set the password (you learn something new every time ). Sadly no change, but I many need to reboot the box (which is not possible for me currently).

You probably didn't need to manually set the SMB password since as I said, I *think* it remains synchronised to the Wiz's root password.

Either way, try using user "beyonwiz" with both the Wiz's root password and with whatever password you manually set using smbpasswd.

I believe that the samba settings take effect more or less immediately (or within a minute or two), but if you want to make sure, you should be able to restart the samba service manually from the GUI.

However, yea. Very possible it isn't as simple as requiring a password now. Seems a strange setting to enforce on the client side.

[blip]

I found a couple of references to Catalina dropping support for smb v1 and smb v2 and only supporting smb v3. Could this be the problem? I know nothing about Macs.

[Paul_oz53]

If blip is correct, the default protocol setting on the Wiz would need to be replaced with:

Code: Select all

min protocol = SMB3

I'm not sure if you can achieve this by adding the line to /etc/samba/smb-user.conf though.

It may be that you need to amend the files in the /etc/samba/distro folder but that is meant to be off limits to mere mortals. You would need to change smb-branding.conf to point to smb-secure,conf and edit smb-secure.conf to version 3. Currently version 2.02.

[MrQuade]

It may be that you need to amend the files in the /etc/samba/distro folder but that is meant to be off limits to mere mortals. You would need to change smb-branding.conf to point to smb-secure,conf and edit smb-secure.conf to version 3. Currently version 2.02.

You should be able to override any setting that is in the secure config file with an equivalent line in smb-user as they all apply to [global] settings.

However, that setting shouldn't do anything at all since it is setting a *minimum* level with the objective to block out clients running old versions of SMB. Unless OSX is doing something really braindead and saying "oh do you support SMB2? HAHA! INSECURE, NO CONNECTION!" even when the server ALSO supports SMB3.
(this is somewhat like what some DVD players used to do when they checked for region compatibility to catch out those users who had set their players to "all regions, but in that case, it made a bit more sense).


Also, I got curious about the SMB and root password synchronisation, and I can see that PAM is doing that job after having a look at the config files on my V2. However, my U4 does not have the corresponding SMB entries in its PAM configuration files......very odd that there is a difference there!

[Paul_oz53]

Hmm. That makes Altimes situation unmanageable then.

I would have hoped it set the server to version 3 too. It may still be worth a try to see if Catalina is fooled by the setting.

I wonder if the Wiz can mount a Catalina share using vers=3.0 in the mount settings. If that were possible at least copies from the Wiz to Catalina could be originated on the Wiz.

Otherwise, it may become a case of sneakernet is the only way to bypass the networking problems!

[MrQuade]

I would have hoped it set the server to version 3 too. It may still be worth a try to see if Catalina is fooled by the setting.

The server does support V3. The client side initiates the communication and the server responds with whatever version level it was contacted with (more or less).

I wonder if the Wiz can mount a Catalina share using vers=3.0 in the mount settings. If that were possible at least copies from the Wiz to Catalina could be originated on the Wiz.

That might work on the Wiz boxes that run later version kernels.
The Wiz's SMB maximum version is limited by the kernel when it is acting as a client, but when the Wiz is acting as the server, the maximum supported version is determined by the version of Samba.

So testing a client connection on the Wiz won't tell you anything about it's server capabilities.

[Paul_oz53]

I would have hoped it set the server to version 3 too. It may still be worth a try to see if Catalina is fooled by the setting.

The server does support V3. The client side initiates the communication and the server responds with whatever version level it was contacted with (more or less).

I'd be hopeful that Catalina requests V3 and accepts the response if the minimum protocol is set. Of course, we don't know how Catalina requests the available server version. In theory, it should work simply based on the current Wiz firmware supporting V3. But it doesn't. Trying an amended smb-user.conf is a Hail Mary situation but we'll never know until someone tries it.

I wonder if the Wiz can mount a Catalina share using vers=3.0 in the mount settings. If that were possible at least copies from the Wiz to Catalina could be originated on the Wiz.

That might work on the Wiz boxes that run later version kernels.
The Wiz's SMB maximum version is limited by the kernel when it is acting as a client, but when the Wiz is acting as the server, the maximum supported version is determined by the version of Samba.

So testing a client connection on the Wiz won't tell you anything about it's server capabilities.

Some of my PC mounts are set to vers=3.0 and work perfectly. I assume that means both sides are running 3.0.

[Altimes]

Thanks for the thoughts and suggestions.

OK, so I've tried a couple of things.

Full reboot and set min protocol = SMB3 in smb-user.conf

Validated that it is being accepted using testparm, which gives

testparm
Load smb config files from /etc/samba/smb.conf
rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384)
WARNING: The "null passwords" option is deprecated
Processing section "[Movie]"
Processing section "[Logs]"
Processing section "[Movie]"
Processing section "[Logs]"
Loaded services file OK.
Server role: ROLE_STANDALONE

Press enter to see a dump of your service definitions

# Global parameters
[global]
disable spoolss = Yes
guest account = root
load printers = No
map to guest = Bad User
null passwords = Yes
obey pam restrictions = Yes
passdb backend = smbpasswd
printcap name = /dev/null
security = USER
server min protocol = SMB3
server string = Beyonwiz %h network services
smb passwd file = /etc/samba/private/smbpasswd
username map = /etc/samba/private/users.map
idmap config * : backend = tdb
include = /etc/samba/distro/smb-shares.conf
level2 oplocks = No
oplocks = No
posix locking = No
strict locking = No


[Movie]
comment = /hdd/movie
guest ok = Yes
path = /media/hdd/movie
read only = No


[Logs]
comment = Log files
guest ok = Yes
include = /etc/samba/smb-user.conf
path = /home/root/logs
read only = No

From the Finder (gui), trying to expand the Wiz network node I get

URLs with the type “smb:” are not supported.

From CLI I get

mount_smbfs //beyonwiz:******@beyonwizt4.local/Movie ./junk
mount_smbfs: server connection failed: Operation not supported

Modifying min protocol to SMB 2 gets me back to the socket not connected message.

So progress, of a sort

Seeing the deprecation warning, I've comment out the null password option down in distro (yes, I know it will get overwritten) and it made no change to the results.

My next test is to swap from insecure to secure config.

Alan

[Altimes]

OK, changed to secure, no success.

Upped the log level to 9 ( not that I understand a fraction of the output)

One interesting line that shows up in the log is

[2021/05/04 12:42:19.031017, 3] ../source3/smbd/smb2_negprot.c:294(smbd_smb2_request_process_negprot)
Selected protocol SMB3_02

also looking suspicious (given the mount was for beyonwizt4.local)

[2021/05/04 12:42:27.118360, 3] ../lib/util/util_net.c:255(interpret_string_addr_internal)
interpret_string_addr_internal: getaddrinfo failed for name beyonwizt4 (flags 34) [Name or service not known]
[2021/05/04 12:42:27.118509, 3] ../source3/lib/util_sock.c:1187(get_mydnsfullname)
get_mydnsfullname: getaddrinfo failed for name beyonwizt4 [Unknown error]

ending up with

[2021/05/04 12:42:30.190928, 5] ../source3/smbd/uid.c:425(smbd_change_to_root_user)
change_to_root_user: now uid=(0,0) gid=(0,0)
[2021/05/04 12:42:30.192612, 3] ../source3/smbd/server_exit.c:236(exit_server_common)
Server exit (NT_STATUS_INVALID_PARAMETER)

The really frustrating part being that it all worked just fine before the Apple update.

Alan

[Altimes]

OK, problem appears to be resolved and OK, it was me....... The name lookup failure was the key. I run split brain DNS server on the Synology to ease remote VPN access. The .local domain is from long term use of Netgear routers. Whilst the Netgear DHCP is basically OK, the one thing that it does NOT facilitate is pushing out a DNS server.

Changing the Wiz Interface from DHCP to static and giving it the Synology DNS Server for its DNS entry has allowed me to mount the T4 on the Mac again.

Why has it just started happening, I have no idea.....

Anyway thanks to all for your thoughts and input.

Now to put everything that I've futzed with back to normal

Alan.

[Paul_oz53]

My Google search also yielded no useful tips. Apple's silence is deafening!

Short of using the NAS as common storage the problem seems intractable. If you do go that route my preference would be to change the Wiz's default recording location(s) in
Menu >> Setup >> TV >> Recording settings.

The alternative of setting a mount option to "Use as hdd replacement" is being investigated at the moment to resolve a number of bugs. Best avoided for the time being.

[MrQuade]

Changing the Wiz Interface from DHCP to static and giving it the Synology DNS Server for its DNS entry has allowed me to mount the T4 on the Mac again.

Strange that this would have resolved the issue then, because clearly the IP address was being resolved from the OSX side (seeing as changing the minimum protocol on the U4 side resulted in a change in behaviour).

Perhaps the U4 needed to validate a name or domain in the other direction which caused some sort of mismatch. I don't know enough about SMB to know what it does down at that level.

Good to have it fixed though, and not at all a straightforward answer given your unique LAN situation!

[Paul_oz53]

Changing the Wiz Interface from DHCP to static and giving it the Synology DNS Server for its DNS entry has allowed me to mount the T4 on the Mac again.

Strange that this would have resolved the issue then, because clearly the IP address was being resolved from the OSX side (seeing as changing the minimum protocol on the U4 side resulted in a change in behaviour).

Perhaps the U4 needed to validate a name or domain in the other direction which caused some sort of mismatch. I don't know enough about SMB to know what it does down at that level.

Good to have it fixed though, and not at all a straightforward answer given your unique LAN situation!

+1. Recently we have seen the odd instance of DHCP not working as expected for some users but assigning a static IP fixing the problem. I never expected it to be an issue for Alan.

Curious to know what SMB version you end up with Alan.

[Altimes]

FWIW looking through the samba log files (which grow *really* quickly ), the Mac OS connection seems to the protocol SMB 3_02 whilst the between Wizen (U4 mounting T4) appears to be protocol SMB 2_10.

Curiously, the log also shows record of the the GUEST user not existing on the Mac, thus it looks like samba is doing some sort of mutual authentication.

root@beyonwizt4:/var/log/samba# grep SMB log.smbd
netbios connect: name1=*SMBSERVER 0x20 name2=BEYONWIZU4 0x0
Selected protocol SMB2_10
Auth: [SMB2,(null)] user [BEYONWIZT4]\[guest] at [Tue, 04 May 2021 18:00:34.625517 AEST] with [NTLMv2] status [NT_STATUS_NO_SUCH_USER] workstation [] remote host [ipv4:192.168.1.24:38068] mapped to [BEYONWIZT4]\[guest]. local host [ipv4:192.168.1.20:139]
netbios connect: name1=*SMBSERVER 0x20 name2=BEYONWIZU4 0x0
Selected protocol SMB2_10
Auth: [SMB2,(null)] user [BEYONWIZT4]\[guest] at [Tue, 04 May 2021 19:22:35.001582 AEST] with [NTLMv2] status [NT_STATUS_NO_SUCH_USER] workstation [] remote host [ipv4:192.168.1.24:34374] mapped to [BEYONWIZT4]\[guest]. local host [ipv4:192.168.1.20:139]
netbios connect: name1=*SMBSERVER 0x20 name2=BEYONWIZU4 0x0
Selected protocol SMB2_10
Auth: [SMB2,(null)] user [BEYONWIZT4]\[guest] at [Tue, 04 May 2021 22:27:45.855530 AEST] with [NTLMv2] status [NT_STATUS_NO_SUCH_USER] workstation [] remote host [ipv4:192.168.1.24:36044] mapped to [BEYONWIZT4]\[guest]. local host [ipv4:192.168.1.20:139]
Selected protocol SMB3_02
Auth: [SMB2,(null)] user []\[GUEST] at [Wed, 05 May 2021 08:51:08.860564 AEST] with [NTLMv2] status [NT_STATUS_NO_SUCH_USER] workstation [FOA-WK7] remote host [ipv4:192.168.1.12:51077] mapped to []\[GUEST]. local host [ipv4:192.168.1.20:445]

Alan.

[MrQuade]

FWIW looking through the samba log files (which grow *really* quickly ), the Mac OS connection seems to the protocol SMB 3_02 whilst the between Wizen (U4 mounting T4) appears to be protocol SMB 2_10.

SMB 2.1 makes sense between the Wiz machines, as that version is explicitly provided as a default option in the Wiz SMB mount definition.

[Altimes]

Seems that I am not quite out of the woods yet

This afternoon the "Socket not connected" resurfaced. After I had put all the Samba stuff back to normal, of course . I went through my dance of the hours again before I twigged that I had the same problem. That is, the Wiz was using the router 192.168.1.1 for DNS. I checked the wiz network interface fields. Lo and behold, what I had set to x.x.x.30 has magically gone back to x.x.x.1 (router). This is despite having DHCP disabled.

I was suspicious of a Wiz reboot, so I changed it and rebooted the Wiz but it stuck (as you would expect). So something else is causing the change.

My current guess is that *something* is causing the overwriting of /etc/resolv.conf. More research for me

Given that this "was all working" up until recently and that the Netgear router has been intermittently playing up recently (randomly not routing between wireless and wired), I am beginning to think that it time to upgrade the router to something more contemporary.

Ah well, at least I know where to look from now on.

Alan.

[Altimes]

OK, so some digging around has revealed that odhcp6c and / or udhcp6c may be the culprits. Looking at /etc/udhcpc.d/default50 suggested that it is a participant in the overwriting of resolv.conf.

Manually executing udhcpc on the command line (questionable tactic, I know) very clearly overwrites resolv.conf with the router address. As to what is triggering it to run or why it is being run when we have DHCP explicitly disabled is another question. I have yet to find where it might be being invoked.

Alan.

[MrQuade]

Very odd.

I had a poke around for reports of udhcpc being improperly called on manually configured interfaces, but didn't come up with anything.
I am guessing, that it is normally called when a network interface state changes, and then checks if the interface needs an IP assigned, but since the DNS is a global setting, it gets fetched anyway. A bit of a problem that.

And on that note, I was poking around on my U4, and ran into a second instance of my network interface clapping out.

No IP address shown in the Interface setting screen, and the Network Browser throws an error when run, yet I am perfectly able to access the U4 over the network.

The only things I changed in my own setup recently were a change of its DHCP assigned address some weeks ago, and switching the U4 over to a PlayTV tuner. I assumed maybe the previous instance of this issue was a one-off and the result of the IP change, and don't really know how the PlayTV would be messing with the network stack.

[Altimes]

OK, to confirm or deny a suspicion, I power cycled the Netgear router and it looked like that was enough to see the resolv.conf to be overwritten. I rebooted the router, checked the resolv.conf and it had gone back to the router address. Gotcha, I thought, then thought, hang on, I did not actually check what it was BEFORE I rebooted the router.

OK, replace 1.1 with 1.30 and reboot the router. Ah, it stays at 1.30, so something else caused the T4's resolv.conf to be overwritten.

From what I can tell this only seems to effecting the T4 (which is always on). The U4 (which is mainly deep sleep mode) is not being affected.

More sleuthing/thinking to do ... (DHCP lease renewal ??? - a "udhcpc renew" would do it.....) I will keep an eye on it having noted the current timestamp as 8:52.

Alan.

[peteru]

Unless you have a specific need to run IPv6 on your network, turn it off at your router(s). As much as I'd love to see wide-scale deployment of IPv6 displacing IPv4, most implementations are not (yet) good enough for use by general public.

In many cases IPv6 is enabled on devices, but is unconfigured and not tested nearly as well as it should be. This is the case not just for Beyonwiz, but also other enigma2 based devices and most consumer electronics in general. In fact, many networking devices have IPv6 related issues.

As far as the need to run IPv6 - most people don't have that need since their Internet connection from their ISP is not IPv6. There's very little benefit to be had from deploying IPv6 for LAN use at home. If you disable IPv6 you avoid potential configuration and security issues.

[Altimes]

I had disabled IP6 in the routers some time ago after I noticed a bunch of sources banging away IP6 at addresses on the router in its log entries. On verifying that today, I did notice that it was still enabled for the disabled guest network, so I have disabled it there as well. Currently the resolv.conf file on the T4 is showing no changes