Sonos SMB share Permissions Error with OMV4

    • OMV 4.x

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • 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?

      Reference:
      en.community.sonos.com/trouble…ort-for-smb2-smb3-6791120
      en.community.sonos.com/trouble…ing-music-library-6765736

      The post was edited 1 time, last by Aussie3d ().

    • 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 on what has changed lately to need this Addition

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

      Source Code

      1. min protocol = NT1
      2. ntlm auth = yes
      Reference:
      SMB1 & Zappiti.
    • (Well, until "someone wiser" chimes in. :) )

      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?
      Good backup takes the "drama" out of computing
      ____________________________________
      Primary: OMV 3.0.99, ThinkServer TS140, 12GB ECC, 32GB USB boot, 4TB+4TB zmirror, 3TB client backup.
      Backup: OMV 4.1.9, Acer RC-111, 4GB, 32GB USB boot, 3TB+3TB zmirror, 4TB Rsync'ed disk
      2nd Data Backup: OMV 3.0.99, R-PI 2B, 16GB boot, 4TB WD USB MyPassport - direct connect (no hub)
    • 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

      1. 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.

      Thanks for the reply
    • 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.
      Good backup takes the "drama" out of computing
      ____________________________________
      Primary: OMV 3.0.99, ThinkServer TS140, 12GB ECC, 32GB USB boot, 4TB+4TB zmirror, 3TB client backup.
      Backup: OMV 4.1.9, Acer RC-111, 4GB, 32GB USB boot, 3TB+3TB zmirror, 4TB Rsync'ed disk
      2nd Data Backup: OMV 3.0.99, R-PI 2B, 16GB boot, 4TB WD USB MyPassport - direct connect (no hub)

      The post was edited 3 times, last by flmaxey: edits ().

    • Fair point, about ransomware and unfortunately all to valid...

      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 :huh:
    • It's the lure of easy money, it has a very strong appeal.

      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.
      Good backup takes the "drama" out of computing
      ____________________________________
      Primary: OMV 3.0.99, ThinkServer TS140, 12GB ECC, 32GB USB boot, 4TB+4TB zmirror, 3TB client backup.
      Backup: OMV 4.1.9, Acer RC-111, 4GB, 32GB USB boot, 3TB+3TB zmirror, 4TB Rsync'ed disk
      2nd Data Backup: OMV 3.0.99, R-PI 2B, 16GB boot, 4TB WD USB MyPassport - direct connect (no hub)

      The post was edited 1 time, last by flmaxey: edit ().