Sonos SMB share Permissions Error with OMV4

I'm pulling my hair out over this one, a really frustrating error with a fresh OMV4 as a NAS for SONOS, that was't occurring with my previous OMV4 setup.

This is a Fresh OMV4 install (I though it was quicker to go for a new install.... arrrrr) including latest upgrades running on a RasberryPi2.

Shared Folder: MyMusic
Owner = root
Group = users
Others = none

User: sonos
member of the "users" group

SMB share & AFP share both visible / functional from finder

Question:
SONOS is unable to connect to SMB share, not sure if this is just a name problem with the share or a permissions problem with the "sonos" user

The most frustrating part was this worked perfectly yesterday.
I'm sure it is something small I have missed but I can't for the life of me find it.

Some Attempted solutions:

//ipAddress/SMBshare

\\raspberrypi\SMBshare

Different users names

change permissions via ACL

Change owner via ACL to "sonos"

allow guest users

restart OMV

Many more

Any ideas would be greatly appreciated.

_______
EDIT1:
SONOS looks only to support SMB V1.

Still unclear if this is the problem and not sure what has changed from the previous install to the new install but maybe a possible cause.
If so is it possible to use SMB V1 with OMV????
Is SMBV1 disabled on OMV?

Ok well this seems to overcome the problem for the moment but I think there are some problems with this approach.
Notably security....Perhaps someone wiser could advise on the security more? (blogs.technet.microsoft.com/fi…16/09/16/stop-using-smb1/)Perhaps someone wiser could advise onwhat has changed lately to need this Addition

I solved the problem by adding this line in the "extra options" field:

Source Code

SMB1 has a weakness in it that allowed the Wcry (WannaCry) virus to exploit Windows machines globally. Patches stopped it and the virus was completely neutered when the domain it reported back to was bought. "But", weaknesses in SMB1 still exist, so a rewritten virus or other malware could, potentially, take advantage of them.

Some time ago, MS disabled SMB1 with security patches which prevented currently supported and patched Windows machines from hosting SMB1 shares. In addition, Windows 10 wouldn't negotiate with a server that started the SMB negotiation process at SMB1. (Win7, 8, etc. would still use SMB1 in the client role) SMB2 shares worked fine for all.

(I didn't research the following in depth - it's based on the observed outcomes of a few tests.)
The last change was noticed, a month or two ago. This last change stops currently supported and patched Windows machines, in the role of SMB client, from connecting to existing SMB1 shares regardless. In essence, anything prior to Windows server 2008 and Vista, won't mix with later versions of Windows on a network that are fully patched and up-to-date.
____________________________________________________________________________

In the bottom line, currently, using SMB1 with Windows could only be done with reasonable safety, in standalone networks. Running SMB1 on any Windows box, connected to the Internet, adds risk.

(But I have to admit, I don't know if a Linux server, hosting an SMB1 share, could be compromised. It's an interesting question.)

I looked over "Sonos". Is the share you're setting up for a older Sonos hardware player?

Yeah,
Its a bit of an interesting one with respect to SONOS, the reason for SMB shares with sonos is all about connecting to NAS storage of personal music collections.
Unfortunately Sonos don't seem to think looking after people whom want to own their music collection is the future and they are more focused on supporting streaming services. They appear not to support SMB2 or SMB3 (and don't seem in a rush to fix this).

I did discover that the extra code needed seem only to be the following: (which I think doesn't open up the SMB1 flaw but I'm really not sure???? )

Source Code

ntlm auth = yes

In my personal setup, its just a simple home share / storage system within a basic fire-walled network. I'm not sure anyone could gleam anything of great value from my personal archive data or music collection but even so its nicer to think things are better locked down.

Hacks might not learn anything about you, but note that Wcry was ransomware. It encrypted user data. The original virus asked for payment, in exchange for a key, or user data was lost to permanent encryption.

NTLM equates to NTLM ver1. To get an idea of the levels, the age of protocols and all that, take a look here.

There are ways to secure your media files, like making the SMB music share read only, with other enhancements like a one way Rsync job that updates your SMB shared media folder, from another secured folder that's not on the network. (The down side is, storage doubles.)

In any case, even with older security; if your router is tight and with the share being hosted on a Linux server (not Windows), which is accessed by a Sonos hardware device, you'll probably be OK.

But I can help feel sad for the future of humanity if I need to implement commercial grade firewalls and backup my backups to protect my music library from highly sophisticated malicious hacks designed to squeeze me for $100 worth of bitcoins...
I wish people with the level of skill required for this would put their skills to better use

If you have more than one user, your music share should be read only in any case. Just make sure your router is not forwarding ports into your LAN. If you're not exposing servers to the net, setting up VPN's (incorrectly), etc., you should be fine.