SMB Access From Windows 11 24H2

[ultramode]

Hi all, first post here. Just wanted to say thanks for the great distro.

With the introduction of Window 11 24H2 Microsoft have enforced SMB signing and disabled the use of guest accounts. On Pro it can be overridden by group policy, this isn't available for Home Edition users and is probably best left in it's default mode anyway.

Some details here SMB Signing and Guest Authentication | Microsoft Community Hub

I installed a test copy on to a spare pi and checked as I wasn't able to access my main installs and didn't want to mess them up.

SMB signing seems fine it's the password less access to the guest account that fails. I did create a new user and then add that to samba, the permissions were all messed up so it wasn't like connecting with the guest account as before, but I could connect.

Any work arounds for this or a way to introduce an official way of doing this going forward?

Thanks again for the great distro!

[TheOldPresbyope]

So, I assume you are referring to the SMB service which can be enabled in a moOde player to share its mount points (NAS, NVMe, Playlists, SDCard) with other devices.

I'm inclined to say moOde's configuration options should be expanded to include setting a username/password for these shares just like I can on my NAS.

Nuisance? Sure, but IMHO it beats poking Windows 11 in the eye with a sharp stick.

Truth in advertising: MS Windows hasn't been the primary OS on any of my computers in a decade. I do have legal copies of 10 Pro and 11 Pro available as guests in VirtualBox on a Linux box but these days I only fire them up once in a while just to get updates or to check on some user's problem. Not up to 22H2 (yet).

Regards,
Kent

[ultramode]

Hi TheOldPresbyope,

Yeah, I have the SMB service running then I can either access my music files from a PC or edit any playlists, stuff like that. With the change it just stops that. I had a little look at it but thought it best to ask if there was an official way. Luckily the version of Samba being used automatically detects the signing so no need to add a bunch of stuff in smb.conf. Just the password bit that fails.

It would be nice I guess to define a user and not rely on guest accounts on security grounds as that's one of the first places to look for if you were up to something dodgy on someone's network. Or to just have an account that has the same details as the ssh user if you have it setup maybe.

Thanks for the help.

[philrandal]

Hi TheOldPresbyope,

Yeah, I have the SMB service running then I can either access my music files from a PC or edit any playlists, stuff like that. With the change it just stops that. I had a little look at it but thought it best to ask if there was an official way. Luckily the version of Samba being used automatically detects the signing so no need to add a bunch of stuff in smb.conf. Just the password bit that fails.

It would be nice I guess to define a user and not rely on guest accounts on security grounds as that's one of the first places to look for if you were up to something dodgy on someone's network. Or to just have an account that has the same details as the ssh user if you have it setup maybe.

Thanks for the help.

I had the same issue with with 24H2 when trying to upload to a samba share on libreelec. Unlike my usual self, I didn't write down the fix.

Does this work?

https://windowsreport.com/windows-11-dis...b-signing/

Edit: this looks like a better and fuller solution

https://techcommunity.microsoft.com/blog...il/4154300

[ultramode]

To get it back working here is what I have done. After an update the smb.conf might need the line adding back.

For a direct replacement of the guest account that works on Windows 11 24H2 and going forwards there are a few options you can add your ssh user account or add a new account.

ssh in to your moode install

sudo -s

Create the new guest user.
useradd moodeguest -m -G users

Give the new guest user a password.
passwd moodeguest

Add the guest user to Samba.
smbpasswd -a moodeguest

Give the moodeguest account a password.

Edit the smb.conf file
nano /etc/samba/smb.conf

Under the Global section add the line
admin users = @users

ctrl x to save the file.

Restart Samba
service smbd restart

That will restore the full functionality as it was with just the password less guest account. The existing password less guest account will also still work. You could also just add your ssh user using smbpasswd and skip creating a new account. To disable the password less guest account if you don't want it, just comment out using # the guest ok = Yes lines in smb.conf.

You can go further if you'd like and have an admin account and a read only account. Like if you want an admin mode and a read only mode create two users like moodeguest and admin. In the global section set the admin users variable to admin instead of the @users group. This will give admin read / write access and moodeguest read only access.

If there is a nicer way let me know. Hope this helps. Now I can listen on my machine again.

[Tim Curtis]

I could add a "Password protect" option to the SMB (Samba) file sharing option.

Assuming the SSH userid is used, what changes are needed to the global section of smb.conf?

Here's the default section.

Code:

[global]
server string = Moode SMB Server
multicast dns register = no
security = User
map to guest = Bad User
guest account = root
log level = 0
load printers = No
printcap name = /dev/null
disable spoolss = Yes
printing = bsd
preferred master = No
local master = No
domain master = No
dns proxy = No
create mask = 0775
directory mask = 0775
browseable = Yes
veto files = /._*/.DS_Store/
delete veto files = yes

[TheOldPresbyope]

Perhaps I'm misunderstanding what you intended when you said "Assuming the SSH userid is used" but it sounds like you mean protecting the SMB shares with the credentials of userid 1000. 

Seems to me marginally better from a security standpoint to create a separate password-protected account (perhaps "guest", as suggested by @ultramode) which doesn't have login permissions.

We could go down the same route with NFS mounts for a similar reason.

Regards,
Kent

[Tim Curtis]

Perhaps I'm misunderstanding what you intended when you said "Assuming the SSH userid is used" but it sounds like you mean protecting the SMB shares with the credentials of userid 1000. 

Seems to me marginally better from a security standpoint to create a separate password-protected account (perhaps "guest", as suggested by @ultramode) which doesn't have login permissions.

We could go down the same route with NFS mounts for a similar reason.

Regards,
Kent

Based on @ultramode,  "You could also just add your ssh user using smbpasswd and skip creating a new account."

I don't think its possible to password protect NFS shares.

[TheOldPresbyope]

After a quick review to refresh my aging memory cells, I concede it's devilishly difficult to protect NFS access by more than the usual by-host or by-subnet methods. 

Regards,
Kent

[ultramode]

I look at it from two angles, there is you can use a password protected account i.e new user then disable the guest access by commenting out the guest ok in the conf. Or you can mix and match, this was more a work around for the guest account issue with Windows moving forwards. I think think in terms of security these days any misbehaving / bad app running on a system will go straight for guest account logins so sort of makes sense to move to a more protected option.

In my workaround I added the existing user account (the ssh account) to the samba database. Either way which ever account is used needs to be added to the samba database. Once the user is added it gets the read only. By setting the admin users = @users gives any users of the users group full permissions. Could also be admin users = protecteduseraccount for say a single account. I didn't try but when creating a user before adding it to samba I think you can use that to ssh in, not sure if it's a member of the sudo group however.

Was just scratching an itch and thought I could help some other users after having many years of enjoyment from the project.