File Remote Share - CIFS Mount Failed - But actually is connected

[briodan]

What version of Music Assistant has the issue?

2.6.1

How is the MA server installed?

Home Assistant OS Addon

Carefully read the Troubleshooting FAQ and confirm that

• I have examined the logs and tried to resolve this issue
• I have fixed any errors in the logs that relate to tags
• I am not running MA across a VPN, VLAN, subnet, behind a firewall, or using local SSL or have any other complex network setup
• I have disabled tool such as AdGuard, Pi-hole or pfSense and retested
• I have checked my network setup to ensure mDNS/multicast is not being blocked
• If using HA, I have confirmed the internal URL is set correctly
• I have tried a wired connection for issues related to interrupted or poor playback quality
• If the problem relates to a device then I have checked the device settings
• If it is a frontend issue, I have tried a different widely used browser
• I have reviewed the applicable player or music provider documentation
• For voice problems, I have sought help elsewhere before returning here
• For playback problems, I have recycled power to the physical device
• I have tried restarting MA and rebooting the host

Have you reviewed the Open and Closed Issues and Discussions to resolve this yourself?

• Yes

The problem

I'm having the exact same problem as #4253

error logs show up in the HA console

in the HA host logs

the logs correlate with the MA logs attempting to mount that same share

The share mounts and media is accessible.

How to reproduce

add a network share to MA

Music Providers

file system

Player Providers

none

Full log output

music-assistant.log

Additional information

none

What version of Home Assistant Core (if used) are your running

2025.10.4

What type of installation are you running?

Home Assistant OS

On what type of hardware are you running?

Linux

Have you included ALL of the information specified in the Troubleshooting FAQ or explained why you cannot

• Yes

[OzGav]

Why do you believe this is a MA problem? Has this ever worked? The points in the issue you linked are all still valid.

[briodan]

Why do you believe this is a MA problem?

Because MA is the only thing that mounts //10.10.10.201/music and every time i see the mount in MA i can correlate it back to an error in the console and host log, if you see the timestamps MA log is first.

Has this ever worked?

Has what ever worked? The issue i'm reporting and the other person reported is that MA is able to access the share however these errors keep getting generated.

Do i agree that this is something that should not take place, as the mount should be in docker and error messages not propagate to the host, yes i do, does it still happen also yes. This is why i'm reporting this and looks like i'm not the only one with the issue strange as it is.

[OzGav]

They are operating system errors. We can only help with MA problems. If it otherwise is working fine the I would ignore them.

[briodan]

They are operating system errors. We can only help with MA problems. If it otherwise is working fine the I would ignore them.

sure they are but the root cause is with MA, if i shut down MA those errors don't generate.

Something in MA is causing issues that are throwing operating system errors, that to me is an issue for MA to solve because it looks like MA is behaving outside its bounds.

[briodan]

so interesting piece, deployed MA on another server via docker compose and setup the same share access.
MA can see the contents however when i check /var/log/syslog i get the following

this allowed me to probe a bit more through logs on both ends dockerhost and SMB server

Below log from the SMB server showing the auth steps.

/var/log/samba/log.smbd:../../auth/ntlmssp/ntlmssp_server.c:512: [2025/11/24 04:48:04.660284, auth 3, pid=30291] ntlmssp_server_preauth
/var/log/samba/log.smbd:../../source3/auth/auth.c:212: [2025/11/24 04:48:04.660342, auth 3, pid=30291] auth_check_ntlm_password
/var/log/samba/log.smbd:  check_ntlm_password:  Checking password for unmapped user []\[testuser]@[] with the new password interface
/var/log/samba/log.smbd:../../source3/auth/auth.c:215: [2025/11/24 04:48:04.660361, auth 3, pid=30291] auth_check_ntlm_password
/var/log/samba/log.smbd:  check_ntlm_password:  mapped user is: []\[testuser]@[]
/var/log/samba/log.smbd:../../libcli/auth/ntlm_check.c:450: [2025/11/24 04:48:04.660692, all 3, pid=30291] ntlm_password_check
/var/log/samba/log.smbd:  ntlm_password_check: NTLMv2 password check failed
/var/log/samba/log.smbd:../../libcli/auth/ntlm_check.c:483: [2025/11/24 04:48:04.660711, all 3, pid=30291] ntlm_password_check
/var/log/samba/log.smbd:  ntlm_password_check: NEITHER LanMan nor NT password supplied for user testuser
/var/log/samba/log.smbd:../../source3/auth/auth.c:386: [2025/11/24 04:48:04.660828, auth 2, pid=30291] auth_check_ntlm_password
/var/log/samba/log.smbd:  check_ntlm_password:  Authentication for user [testuser] -> [testuser] FAILED with error NT_STATUS_WRONG_PASSWORD, authoritative=1
/var/log/samba/log.smbd:../../auth/auth_log.c:814: [2025/11/24 04:48:04.660890, auth_audit 2, pid=30291] log_authentication_event_human_readable
/var/log/samba/log.smbd:  Auth: [SMB2,(null)] user []\[testuser] at [Mon, 24 Nov 2025 04:48:04.660876 MST] with [NTLMv2] status [NT_STATUS_WRONG_PASSWORD] workstation [] remote host [ipv4:10.10.10.214:50480] mapped to []\[testuser]. local host [ipv4:10.10.10.201:445]
/var/log/samba/log.smbd:  {"timestamp":"2025-11-24T04:48:04.661000-0700","type":"Authentication","Authentication":{"version":{"major":1,"minor":2},"eventId":4625,"logonId":"0","logonType":3,"status":"NT_STATUS_WRONG_PASSWORD","localAddress":"ipv4:10.10.10.201:445","remoteAddress":"ipv4:10.10.10.214:50480","serviceDescription":"SMB2","authDescription":null,"clientDomain":"","clientAccount":"testuser","workstation":"","becameAccount":null,"becameDomain":null,"becameSid":null,"mappedAccount":"testuser","mappedDomain":"","netlogonComputer":null,"netlogonTrustAccount":null,"netlogonNegotiateFlags":"0x00000000","netlogonSecureChannelType":0,"netlogonTrustAccountSid":null,"passwordType":"NTLMv2","duration":2372}}
/var/log/samba/log.smbd:  smbd_smb2_request_error_ex: smbd_smb2_request_error_ex: idx[1] status[NT_STATUS_LOGON_FAILURE] || at ../../source3/smbd/smb2_sesssetup.c:156
/var/log/samba/log.smbd:../../source3/auth/auth_generic.c:325: [2025/11/24 04:48:04.666560, syno 3, pid=30291] auth_generic_prepare
/var/log/samba/log.smbd:  make_auth_context_subsystem [NT_STATUS_OK]
/var/log/samba/log.smbd:../../source3/auth/auth_generic.c:457: [2025/11/24 04:48:04.666654, syno 3, pid=30291] auth_generic_prepare
/var/log/samba/log.smbd:  auth_generic_prepare [NT_STATUS_OK]
/var/log/samba/log.smbd:../../auth/ntlmssp/ntlmssp_util.c:72: [2025/11/24 04:48:04.666747, auth 3, pid=30291] debug_ntlmssp_flags
/var/log/samba/log.smbd:  Got NTLMSSP neg_flags=0xe0080225
/var/log/samba/log.smbd:../../auth/ntlmssp/ntlmssp_server.c:512: [2025/11/24 04:48:04.667620, auth 3, pid=30291] ntlmssp_server_preauth
/var/log/samba/log.smbd:../../source3/auth/auth.c:212: [2025/11/24 04:48:04.667661, auth 3, pid=30291] auth_check_ntlm_password
/var/log/samba/log.smbd:  check_ntlm_password:  Checking password for unmapped user []\[testuser]@[] with the new password interface
/var/log/samba/log.smbd:../../source3/auth/auth.c:215: [2025/11/24 04:48:04.667679, auth 3, pid=30291] auth_check_ntlm_password
/var/log/samba/log.smbd:  check_ntlm_password:  mapped user is: []\[testuser]@[]
/var/log/samba/log.smbd:../../source3/auth/auth.c:309: [2025/11/24 04:48:04.668285, auth 3, pid=30291] auth_check_ntlm_password
/var/log/samba/log.smbd:  auth_check_ntlm_password: sam authentication for user [testuser] succeeded
/var/log/samba/log.smbd:../../source3/auth/auth.c:365: [2025/11/24 04:48:04.668318, auth 2, pid=30291] auth_check_ntlm_password
/var/log/samba/log.smbd:  check_ntlm_password:  authentication for user [testuser] -> [testuser] -> [testuser] succeeded

looks like when MA sends the mount command to mount.cifs on the OS it first sends a blank password (NEITHER LanMan nor NT password supplied for user testuser) then a correct password, the first failed login is what gets logged on the host (both this server and HA).
Not too familair with the code base but wondering if maybe there is a race condition somewhere in the mount initialization code due to it running async.

At the end of the day this would explain the behaviour, share is accessible even though the auth failed message gets logged. And its probably not a big issue other then generating error logs that can confuse people. Even though those might be in the minority as HA is usually run headless and those logs are not in your face on a regular linux VM with docker.

Not sure if i'm correct of the cause of the initial failed auth but would probably be good if someone can look at the code and see if they can identify why MA sends a blank password before the real password.

[OzGav]

This is normal behaviour for the NTLMSSP (NT LAN Manager Security Support Provider).

If you look closely at the logs, the "Failure" and "Success" occur on the same process ID (pid=30291) less than 8 milliseconds apart, which confirms this is the standard, low-level protocol handshake, not a software bug.

Here are the exact log lines showing the sequence:
/var/log/samba/log.smbd:../../source3/auth/auth.c:386: [2025/11/24 04:48:04.660828, auth 2, pid=30291] auth_check_ntlm_password
/var/log/samba/log.smbd: check_ntlm_password: Authentication for user [testuser] -> [testuser] FAILED with error NT_STATUS_WRONG_PASSWORD, authoritative=1

/var/log/samba/log.smbd:../../source3/auth/auth.c:365: [2025/11/24 04:48:04.668318, auth 2, pid=30291] auth_check_ntlm_password
/var/log/samba/log.smbd: check_ntlm_password: authentication for user [testuser] -> [testuser] -> [testuser] succeeded

The difference is 0.00749 seconds, or about 8 milliseconds.Based on what I see in your log this speed proves that Music Assistant is not at fault. No Python script or application retry logic can detect a network error, re-establish a command, and attempt a new connection in 8 milliseconds. The logs are simply showing the internal network negotiation where the client sends one packet without a password (the failure) and the next packet with the password (the success).

If you dont want to see these you should raise the log level above debug.

[briodan]

its not behaviour of the underlying code its how MA handles that code, here is how i can tell

if i go and update the following file
/app/venv/lib/python3.13/site-packages/music_assistant/providers/filesystem_smb/init.py

from

        elif platform.system() == "Linux":
            options = ["rw"]
            if mount_options := str(self.config.get_value(CONF_MOUNT_OPTIONS)):
                options += mount_options.split(",")
            options_str = ",".join(options)

            # pass the username+password using (scoped) env variables
            # to prevent leaking in the process list and special chars supported
            if password:
                env_vars["PASSWD"] = str(password)

            mount_cmd = [
                "mount",
                "-t",
                "cifs",
                "-o",
                options_str,
                f"//{server}/{share}{subfolder}",
                self.base_path,

to

        elif platform.system() == "Linux":
            options = ["rw"]
            if mount_options := str(self.config.get_value(CONF_MOUNT_OPTIONS)):
                options += mount_options.split(",")

            if username:
                options.append(f"username={username}")
            if password:
                options.append(f"password={password}")

            options_str = ",".join(options)

            # pass the username+password using (scoped) env variables
            # to prevent leaking in the process list and special chars supported
            #if password:
            #    env_vars["PASSWD"] = str(password)

            mount_cmd = [
                "mount",
                "-t",
                "cifs",
                "-o",
                options_str,
                f"//{server}/{share}{subfolder}",
                self.base_path,

the error goes away and the logs on the docker host go from

Nov 24 04:48:04 dockerhost kernel: CIFS: Attempting to mount //10.10.10.201/music
Nov 24 04:48:04 dockerhost kernel: CIFS: Status code returned 0xc000006d STATUS_LOGON_FAILURE
Nov 24 04:48:04 dockerhost kernel: CIFS: VFS: \\10.10.10.201 Send error in SessSetup = -13
Nov 24 04:48:04 dockerhost kernel: CIFS: Attempting to mount //10.10.10.201/music
Nov 24 04:54:38 dockerhost kernel: CIFS: Attempting to mount //10.10.10.201/music
Nov 24 04:54:38 dockerhost kernel: CIFS: VFS: No username specified
Nov 24 04:54:38 dockerhost kernel: CIFS: Attempting to mount //10.10.10.201/music

to

Nov 24 15:51:47 dockerhost kernel: CIFS: Attempting to mount //10.10.10.201/music
Nov 24 15:52:37 dockerhost kernel: CIFS: Attempting to mount //10.10.10.201/music
Nov 24 15:53:36 dockerhost kernel: CIFS: Attempting to mount //10.10.10.201/music

the above was done as a rough POC but it stops NTLM probes from falling back to guest auth (which caused the error). probably better ways to handle it but this goes to prove MA code impacts NTLM behaviour and caused the error messages.

[OzGav]

This code has been completely changed in the beta. You need to try that.

edit: I think you will find this has been resolved. Thanks for reporting.