Denied access to Samba Add-On from Ubuntu machine

I have two instances of Home Assistant running on the same network:

Production server:

  • Home Assistant Supervised (Ubuntu 18.04.4; Intel CPU laptop)
  • Samba service installed in Ubuntu
  • I can connect to its Samba share from either a Windows, MacOS, or Ubuntu machine.

Test server:

  • Home Assistant (HassOS; RPI3B+)
  • Samba Add-On installed
  • I can connect to its Samba share only from Windows and MacOS machines but not from an Ubuntu machine.

In a nutshell, two out of the three operating systems allow me to connect to the Samba Add-On onthe Test server (and all three can connect to the Samba service on the Production server). Only the Ubuntu machine is denied connection to the Samba Add-On.

From the Ubuntu workstation, I am challenged to enter the password twice and then get this refusal:

Screenshot from 2020-05-21 09-03-27

I recall reading a thread where someone else encountered the same problem and their solution was to disable the Samba service on the Ubuntu machine. I haven’t tried it but, for my purposes, that’s an impractical workaround (because I also need to share files located on the Ubuntu machine).

The Samba Add-On’s configuration is straightforward. The only changes from the default is that I’ve supplied a password (it’s required).

workgroup: WORKGROUP
username: homeassistant
password: redacted
interface: ''
allow_hosts:
  - 10.0.0.0/8
  - 172.16.0.0/12
  - 192.168.0.0/16
  - 'fe80::/10'
veto_files:
  - ._*
  - .DS_Store
  - Thumbs.db
  - icon?
  - .Trashes
compatibility_mode: false

I’ve tried using a different workgroup (TEST) but it had no effect.

Can someone explain why connection attempts from the Ubuntu workstation are denied by the Samba Add-On?


EDIT

I overlooked to mention that I’m using the latest published version of Samba Add-On (9.2.0) and, interestingly, the log file shows no record of attempts to connect it from the Ubuntu machine.

The only record in the log is when I attempt to connect by supplying this:

smb://servername

instead of just clicking the server’s name in the Networks list. It still refuses the connection (reports that it could not get a list of shares) and the log indicates a netbios connect attempt but doesn’t report it as an error.

1 Like

I recently installed Ubuntu 20.04 on another machine and its smb client behaves the same was as the one on 18.04. It is denied access to the Samba Add-On (but is able to access the samba service on the Production server).

The question remains, what is different in the Samba Add-On that it refuses access to Ubuntu’s smb client?

Hi, did you somehow handle it? I have the same probleme. I get always this:

mount error(13): Permission denied
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

I typed this into the command line:

sudo mount -t cifs -o username=username,password=password,sec=ntlmv2 //192.168.0.101/config /home/ortin/hass_config

From Windows, ChromeOS and Android I am able to access, but not from an other ubuntu server maschine.

The log of the Samba Add-on shows:
{"timestamp": "2021-06-25T12:25:43.741313+0000", "type": "Authentication", "Authentication": {"version": {"major": 1, "minor": 2}, "eventId": 4625, "logonId": "0", "logonType": 3, "status": "NT_STATUS_NO_SUCH_USER", "localAddress": "ipv4:192.168.0.101:445", "remoteAddress": "ipv4:192.168.0.120:54448", "serviceDescription": "SMB2", "authDescription": null, "clientDomain": "", "clientAccount": "homeasstistant", "workstation": "", "becameAccount": null, "becameDomain": null, "becameSid": null, "mappedAccount": "homeasstistant", "mappedDomain": "", "netlogonComputer": null, "netlogonTrustAccount": null, "netlogonNegotiateFlags": "0x00000000", "netlogonSecureChannelType": 0, "netlogonTrustAccountSid": null, "passwordType": "NTLMv2", "duration": 3058}}

Could this be the reason: NT_STATUS_NO_SUCH_USER?

I am running the version 9.5.1 of the Add-on.

Sorry, it was a year ago and I no longer remember how I resolved it.

No problem, I simply used your post because it fits perfectly to my problem.
Maybe someone else could help, hopefully…

Hopefully in less time than a year from now. :slightly_smiling_face:

I really have no idea why, but I got it to work with following unfency commandline. :thinking:

sudo mount -o username=username,password=password //192.168.0.101/config /home/ortin/hass_config

Its basically the same as before, just without “sec=ntlmv2”

1 Like