Unable to connect to SMB share

Hello everyone!

Downloaded to try and play videos from an SMB share. I don’t understand why its not working. I’m a Linux engineer by profession so I kind of know what I am doing (or so my boss tells me) :smiley: .

The share lives on 192.168.1.10 and is called ‘videos’. From Linux I can access and mount it as smb://192.168.1.10/videos, and from macOS I can access the server, browse and mount it as well. It’s protected with username and password.

The share part in smb.conf is:

[videos]
path = /data/videos
valid users = %U
writable = yes
browsable = yes
inherit acls = yes

The user has been created with smbpasswd (for a long time already since the server is over a dozen years old). Lots of other shares live there and it has also served as a share for Time Machine. Basically, the server works lol.

When I access the share from Infuse from Apple TV I just can’t seem to make it work. Since I can’t see a field for the share name I assume the “Name” field is the share name? In none of the examples or forum posts here do I see suggestions to put the share name on the host line. But I tried, didn’t work.

How does this work? I honestly don’t understand, and few things are so simple as an smb share lol.

The only thing which I need to mention here is that the server is living behind a firewall (opnsense with policy based routing) over a wireguard tunnel. I doubt this would bother the app or AppleTV since macOS and Linux both can access all the shares, access web pages and login to ssh to the server. opnsense isn’t blocking ports, it routes based on source subnet and destination address. But I could be wrong of course, maybe the app or AppleTV does something I am not aware of and this doesn’t work for some reason. Or Im doing something wrong, happens all the time haha.

Any ideas please?

Thanks for the assist!

From the logs on the server I can see that the process terminates with the NT_STATUS_NOT_SUPPORTED error at the protocol negotiation stage (smb2_negprot.c), and then exits with NT_STATUS_CONNECTION_RESET before it ever reaches the authentication stage where a username would be provided.

Basically, its killed during handshake of SMB2 protocol. In my config I have specified min and max version of 2 and 3. In Infuse I tried forcing 2 or 3 and the logs remain the same. 2 should be fine, server supports that.

Neither Linux nor SMB are in my area of expertise, but when connecting to a macOS SMB share, Infuse requires that the server have “Windows File Sharing” turned on. Apple describes this as changing how the password is stored. (Stumped me at first when Infuse couldn’t connect to my share.)

It sounds like your server isn’t macOS, but maybe that’s a helpful clue?

This is mentioned in the docs (with a screenshot of the macOS SMB configuration screen) here (see set 3):

Thanks! Appreciate the tips and clues.

The Server runs Linux which has its own way of storing passwords using the smbpasswd tool.

I tried a few other things to get this to work and decided to try Jellyfin on the server in Docker. That ran within minutes and Infuse connects right away.

I’m on a months’ trial for now. I must say it works very well, more often than not does fast forwarding result in artifacts or crashes, loss of sound, temporary stutters. Its really smooth working.

Haha I just read this back and realized that came out wrong!

What I meant to say was, that with other apps (even official streaming services), more often than not does fast forwarding result in artifacts or crashes, loss of sound, temporary stutters.

With Infuse its really smooth and hasn’t resulted in any problems so far. I also like the controls, like the single clicks for pause and continue (several apps I need to click twice which I find annoying).

I really like it and extended my subscription.

1 Like

Can you try this in the 8.1.2 version of Infuse?

This has changes and improvements for SMB (most notably support for SMB 3.1.1) which may help with issues you were seeing with connecting to this device.

There are also a few changes for SMB coming in the 8.1.3 update to handle some rarer cases where a server may be requesting certain ciphers.