Build with preset LibreELEC settings?

  • Help needed please:

    I’d like to build LibreELEC with preconfigured settings to allow users to access their device via SMB. They could then immediately copy a backup file and restore LE/Kodi completely configured with required add-ons, skin configuration, custom menu nodes etc.

    Currently LE does not have SMB password authentication enabled on initial install and recent Windows 11 refuse to connect.

    Is that possible? If so, how?

    If I could do this, a user would just have set their network access and setup library Sources. Far simpler for non technical users and first time LE users.

    Thanks

    Garry

  • It's not possible to force SMB auth on via buildsystem options or Kodi advancedsettings.xml controls but we should probably change the defaults (within the LE settings add-on code) to do that as Windows has required auth for a while now.

  • Thank you!!

    I'll take a look at that now and do so for my build


    The samba_secure setting is enabled by default in the LE Settings add-on.

    But its not enabled after an install...

    Edited once, last by HomerJau: Merged a post created by HomerJau into this post. (March 1, 2026 at 4:03 AM).

  • Does the system being tested with have a /storage/.cache/services/samba.conf or a samba.disabled file? If one is present, its settings will be taken before the addon's default.

  • It’s a LE 12.2 build from current 12.2 branch. Only changes: updated Python 3.11 latest 3.11 point release, Kodi package and a label change to identify the Kodi build. Nothing that affects LE settings.

    I will check and confirm .cache/services contents when I get on my dev PC and do a fresh NUC install (early morning here)

  • New install from USB. Immediately SSH in and there is a samba.conf in .cache/services with SMB password authentication disabled:

    SAMBA_WORKGROUP=WORKGROUP
    SAMBA_SECURE=false
    SAMBA_AUTOSHARE=true
    SAMBA_MINPROTOCOL=SMB2
    SAMBA_MAXPROTOCOL=SMB3
    SAMBA_USERNAME=\l\i\b\r\e\e\l\e\c
    SAMBA_PASSWORD=\l\i\b\r\e\e\l\e\c

  • Quote

    I'll take a look at that now and do so for my build

    Quote

    Nothing that affects LE settings.

    You need to clarify what was done to change the addon's default settings as these statements are in conflict.

  • I have not changed the settings add-on. My build uses LE's current 12.2 branch.

    I have found a workaround by using scp from the command line for Win 11 users:

    scp -P 22 QQKodiRestore.tar root@libreelec:/storage/backup/QQKodiRestore.tar

    Once the backup is restored in LE, all the settings are good (of course).

  • Change the default SAMBA_SECURE="false" in packages/network/samba/default.d/samba.conf to true, then create a clean install to test and I think auth will be enabled.

  • I’d like to build LibreELEC with preconfigured settings to allow users to access their device via SMB. They could then immediately copy a backup file and restore LE/Kodi completely configured with required add-ons, skin configuration, custom menu nodes etc.

    Hi, I'm just wondering, why need to be used the SMB? An SFTP connection with FileZilla, wouldn't do the same job, without the complication of enabling the SMB?

  • It’s for non technical users. Asking them to install a program and how to use it is an added complication.

    We built a customised Kodi specifically for a spatial/surround music forum I’ve been involved with for over 10 years now. I offered to provide members with a pre-built/configured media player (second hand Intel NUC with LE) thinking there may be a dozen or so interested. We ended up building over 80 NUCs. All sold at cost. $140 USD with new 500GB NVME SSD and Bluetooth remote.

    Most these users don’t know anything about PCs, networks, Linux or Kodi. They have been using disc players, some still have 70s quad LPs and multitrack reel to reel tape players. Others have 90s DVD-Audio players. I’ve been sharing how they can convert all their discs to files to play.

    There’s now a huge number of albums being releases in Atmos. That’s another challenge for users. (I’m adding Matroska tagging support to Kodi 22 now). Kodi music needs tags. The QQKodi custom code will eventually get into Kodi mainline I hope too.

    Its been rewarding to hear about our member’s successes with their NUCs and their love for LibreElec/Kodi. It’s a true game changer to move from discs to a centralised file based system as we all know.

    Everyone involved with LE and Kodi should be very proud of what’s been they’ve achieved over these years. I know I couldn’t live without it! I take the opportunity to than you all!

    Edited once, last by HomerJau (March 2, 2026 at 8:59 AM).

  • It’s for non technical users. Asking them to install a program and how to use it is an added complication.

    The samba connection, with the latest security updates, user and password, isn't that was years ago. For "non technical users", an option would be to keep the backup file in an USB-stick. Then you could include in the image an autostart.sh file with something like if exist at the mounted USB-stick a specific folder with the backup inside, to start the restore process... I mean once somebody to start the LE with the "backup-stick" connected, and will do the restoring without any remote connection.

    BTW, the Filezilla have "removable" package, just unzip and run. Almost the same as a simple file browser.

  • Good idea to include the backup on the usb stick.

    When we did the roll out most of the builds were done in the US (I’m in AU). I built an image that was burnt to the NVME drives with Rufus there. I could do the same, include the backup and try and workout his to get the autostart.sh to restore. I haven’t looked at how LE does that.

    Thanks.

  • There's some simple runtime logic for "if this doesn't exist on /storage, create dirs and copy from SYSTEM" so there's always the option to stash the QQ customisations inside the image and if e.g. /storage/.kodi/addons/skin.custom doesn't exist, unpack and create them without the user ever needing to transfer things over SMB. It would be quite simple to maintain customisations in a GitHub repo and add them to the image with a custom buildsystem package under packages/oem which works the same as the packages/virtual location. Also not complicated to check versions of things on /storage and use the same mechanism to update items statically instead of using an online 'repo' for things. In some ways LE is difficult because it's different. In others (and once you understand the mechanisms) is really rather flexible and simple.