And I keep pushing solution to SMB3 problem in this topic instead of possible workarounds because as far as I could understand @SoulsCollective , he is also not needing a workaround but a working SMB3 implementation.
Oof. I hope I’m not that unintelligible 
As above, I also have a workaround (DLNA or sticking with VLC). Also as above, I don’t want to spin up another daemon on the file server for a variety of reasons. Essentially my feelings on this are the same as yours, to wit, that I have paid for a product which advertises SMB3 support and would like for that to work.
I’m still around, just hasn’t been six months yet. I see it’s still work-around heaven. Dev’s have NOT addressed this issue at all and instead it’s everyone else’s fault. Period. Honestly, I’m moving on now.
Yeah sorry my point was kinda that VLC isn’t a work around, work arounds would be different sharing methods so you can use Infuse.
With respect you wouldn’t be posting here if you didn’t want to use Infuse.
I think I’ve spent probably just enough time before I annoy people suggesting to use other sharing methods.
Peace out 
Hi, first of all i’m probably less competent in the domain than most of you guys but had the exact same problem and you all might have tried this or not but sharing it : in the infuse app instead of trying to connect to the SMB that appears configure a new SMB adding the local ip adress of your PC/MAC/LINUX even onto an other name as long as the logins are good . voila that solved it for me hope it will help someone at least.
Just throwing in my own grief at this situation.
I don’t have a solution, but for the last year I’ve found myself attempting to share over SMB, and each time after several minutes of tinkering just caved and gave up due to lack of time. For the last month, though, I’ve been more serious about figuring out why, pouring several multi-hour sessions into this, and I’m stumped.
I’m also increasingly frustrated because like most people who have graduated beyond Single Male Basement Dweller, I can probably count in minutes per year the amount of time I actually get to myself, so pouring in so many hours into this just to fail every time is such a drain on my morale.
The most frustrating part of this, though, has to be that every other app I’ve used to connect to the SMB share does so flawlessly. I kept chalking up the lack of success to my own incompetence, but once I started testing with other apps, they all just worked.
Sharing to Infuse over SMB just does not work for me. This discussion seems to be the most recent and ongoing one, so at least now I can grieve with the others here.
For reference, this is what I’m using:
- Infuse 7.6.1
- MacOS Sonoma (14.0) with file sharing enabled
Any updates on this? Is the issue being investigated? Am I just going to be forced to start hosting various daemons again, which is the sole reason I moved away from all that complexity and settled on Infuse so many years ago now.
1 Like
Welcome to the club of the unfortunate afflicted
Many updates of both TvOS and Infuse later and situation remains the same for me:
- Literally everything else on our network can see and access the SMB share, across Windows, Android and *nix installs;
- All other media players tested on the AppleTV can see and access the SMB share;
- Infuse alone can see but not access the SMB share, regardless of what settings are used; but
- Infuse can see and access the DLNA share on the same file server without any issue.
There is pretty clearly some specific issue with Infuse and SMB here. While I don’t mean to sound petulant, the fact that Infuse continues to advertise SMB support while providing IMHO pretty limited support to actually get this advertised feature working is somewhat galling.
1 Like
Wanted to move on but my email says otherwise. INFUSE-PLEASE RESPOND to the SMB sharing issue. Not long after purchasing lifetime license, SMB sharing stopped working. It is not on our end, we’ve spent days. This needs to be fixed.
Diagnostic code from an attempt to connect to SMB from Infuse on iOS: GN6PD
I encountered the same problem as you, but I found a solution and hope it can help you: In infuse, you cannot enter smb:// for the smb address. You will not get an error if you just enter the address number, such as 192.168.x.x.
Re: suggestions to specify IP address - at least for me, this does not work.
Attempting to specify a new ‘Other’ server in Infuse, then entering the IP address (either as 192.168.1.154 or smb://192.168.1.154), selecting SMB protocol, ensuring ports etc are correct, fails instantly with the same generic ‘Error’ message. I have again attempted to ensure SMB3 is specified, tried both guest and specific username/password combo, specified workgroup or left blank, all all other permutations I can think of - no luck.
Another thing to note is that there is a bug from Microsoft. If you use a Microsoft account to log in to Windows and later change the account password, SMB will not be updated accordingly, and you must use the old Microsoft account password.
Thank you, but not particularly relevant to this specific thread - the SMB shares here which Infuse cannot access are either on Linux or MacOS machines
I had the same issue. As per my understanding, the problem is that Infuse is not fully compatible with the Samba’s latest version of SMB3.
Try to update your config with this line:
server min protocol = SMB3_02
The Samba has several versions of SMB3 protocol:
SMB3_00: Windows 8 SMB3 version.SMB3_02: Windows 8.1 SMB3 version.SMB3_11: Windows 10 SMB3 version.
By default SMB3 selects the SMB3_11 variant.
In my setup Infuse works normally only with SMB3_00 and SMB3_02 variants.
Did anyone find a solution to this? I just bought the lifetime subscription, after being happy with how Infuse works with Jellyfin. Today I tried to set up local streaming, from one Mac to another via SMB. Nothing. every time I try and make a new connection it just immediately jumps to the “An error occurred. Sorry, Infuse encountered an error while trying to connect.”
now reading through this thread, I worry I just wasted a LOT of money
Nope.
Over a year later now, several updates of Infuse and TvOS, rebuilt file server, got two new devices (wife’s iPhone 15, new dual-boot Debian/Win11 laptop), and still in exactly the same scenario: Infuse installed on our AppleTV remains the only client which is unable to connect to the SMB share.
I decided to check whether I can connect from the ATV’s Infuse to the macOS SMB share on my Macbook, and I pretty much succeeded with that by playing a video file.
The only option that required enabling was in macOS’ file sharing, and it was named “Windows File Sharing” where I selected my local account and entered a password for it:
Without it, I was unable to connect. All other settings, including on the Infuse side, are by default.
@SoulsCollective Have you checked my solution for Linux Samba that helped me? I posted it a year ago and a couple of messages above.
As per my understanding, Infuse is using some SMB library that is not fully compatible with the latest Linux Samba server, which is enforcing SMB3_11 version. I did look into Samba code, and in a couple of places I found that SMB3_11 subversion requires clients to use signing and encryption, which Infuse seemingly doesn’t support.
If you don’t want to edit your server configs, you can try to select SMB2 option instead of Auto in Infuse when you add a new SMB connection. This should help you avoid an incompatible SMB3 version of protocol.
Hopefully Infuse 8 will have it fixed? Please… this is ridiculous, one of the few paid apps I have and really the only one that still can’t support SMBv3 properly. You can’t say it’s the fault of samba or users’ configuration if every other app works fine.
I didn’t read the entire thread, so I’m not sure why you need exactly SMB3, as almost all SMB servers have backward compatibility and can work with SMB2 clients (if not disabled by admins explicitly). Infuse has a setting to connect as a SMB2 client, so it should just work.
Read some of my thoughts on the issue if you are interested.
As a developer with 25+ years experience, I can tell you: all software is buggy crap as bloody hell. No exceptions. Some more, some less. All systems and software are so complex nowadays, so it’s a miracle they are still somehow interoperating. Often they have myriad compatibility problems caused by bugs and nonstandard implementations, while bugs are caused by the overall complexity of modern systems. ALL software (without exceptions) is abnormally complex due to dependencies on a dozen abstractions and other components developed by thousands and thousands of people around the world. Infuse is not an exception.
SMB is quite a complex file transfer protocol, which includes different authentication methods, encryption, and myriad other features. Infuse devs have absolutely no resources to implement by themselves, even 30% of the SMB protocol. Also, consider that there are many proprietary SMB servers with their own quirks, and SMB clients should implement support for them. Thus, I am 100% sure the SMB client used by the Infuse app was developed by an external team absolutely not related to the Infuse.
Given by that… Why does SMB3 not work? Perhaps developers of the SMB client haven’t implemented it in full yet. When are they going to implement it? Who knows. Perhaps they abandoned their client, and it’s not going to get this. If they didn’t abandon it, then perhaps they have other priorities to work on. Perhaps everything is implemented, but there is a bug. If that’s the case, then devs of the SMB client should be plugged in, as bugs in such a complex protocol cannot be fixed without deep knowledge of it. Perhaps SMB devs already were plugged in but cannot reproduce it in their environment. You are saying “switch to another SMB client implementation”? Well, it’s highly likely not possible due to huge efforts or just the absence of the alternative. Even if there are alternatives, they are probably even worse. And so on, and so on.
Yes, Infuse developers should at least take a look at the problem to understand what’s going on. Perhaps they already did that and ended up with one of the above cases, and that’s why we don’t have a fix yet. I doubt they don’t want to fix it, and I’m pretty sure they simply can’t do that at the moment for the aforementioned reasons.
In such a situation, the fix may be awaited for years. I witnessed how engineers of a network service deployed on millions of Linux machines were discussing for years how to fix their own service, which sporadically stops working. They are still discussing it, and they have no clue how to catch a bug because they don’t know what in users’ networks causes it, so they simply can’t reproduce it. It’s all about complexity.
We as users are forced to configure all that absurd diversity to make it work somehow. Here’s my humble advice as from an experienced developer: if you have ANY working (even legacy) solution in hand, it’s better to go with it without waiting for a fix that will make all modern/latest features work as expected.
Sorry for the long read.