This is the quick fix from the video, graded honestly. It is a real, Microsoft-documented setting - and its name contains the word insecure for a reason. Here is exactly what it changes, when that trade is defensible, and when it is not.
Let us be straight about this page. The command below works, it is the method the video demonstrates, and it is not a hack - Microsoft documents this setting in its own support pages for exactly the situation where a third-party device cannot do usernames and passwords. It also needs no softening: AllowInsecureGuestAuth tells Windows to trust shares that ask for no login, and that trust is the thing attackers abuse. So here is the whole truth in one place - the command, byte for byte; the equivalent Group Policy and PowerShell routes; the second setting Windows 11 24H2 may demand; the situations where using it is reasonable; the ones where it is not; and how to switch it back off.
One value, machine-wide effect. There is no per-share version of this switch - allowing guest for your NAS allows it for any device your PC ever meets.
reg add "HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters" /v AllowInsecureGuestAuth /t REG_DWORD /d 1 /f
Two equivalent documented routes exist. Group Policy (Pro and above): run gpedit.msc, go to Computer Configuration, Administrative Templates, Network, Lanman Workstation, and set Enable insecure guest logons to Enabled. PowerShell (administrator): Set-SmbClientConfiguration -EnableInsecureGuestLogons $true -Force. All three land on the same policy; the registry line is simply the fastest and works on Home edition too.
If you run the command on Windows 11 24H2 and the share still refuses, you have met the newer change: SMB signing is required by default, and a guest logon cannot sign. Microsoft's own guidance notes that signing and encryption policies must be off for guest logons to work at all. The command that removes the requirement is Set-SmbClientConfiguration -RequireSecuritySignature $false -Force in administrator PowerShell. Understand what stacking the two means: your PC now accepts unsigned, unauthenticated file traffic - both of the protections that stop fake-server and relay attacks, gone together. At that point the honest question stops being which command to run, and becomes why a device in 2026 cannot manage a username and password. A firmware update or a replacement device is usually the better spend.
The fix should be treated as a temporary bridge, and bridges get dismantled. When the NAS is updated or replaced - or once you set up a proper account on the share - restore the protection:
reg add "HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters" /v AllowInsecureGuestAuth /t REG_DWORD /d 0 /fSet-SmbClientConfiguration -RequireSecuritySignature $true -ForceWatch the video to see the command run live; keep this guide open for the risk notes and the undo steps the quick version skips.
▶️ Watch Full VideoOfficial. Microsoft publishes a support page on enabling insecure guest logons in SMB2 and SMB3, covering the Group Policy and PowerShell routes, aimed at connecting to third-party devices that only support guest authentication. The registry value is the same policy written directly. Official does not mean harmless - Microsoft's page itself warns it can leave users open to credential theft and relay attacks.
Out of it. This is a client setting: it governs shares your PC connects to. It does not open your own PC's shares to guests. That direction has been blocked in Windows for far longer, and this command does not change it.
Work through the order: restart so the policy applies; check whether 24H2's signing requirement is the second wall (this page covers it); clear the cached failed session with net use and Credential Manager; and confirm the device truly is refusing at the login stage rather than showing error 0x80070035, which is a reachability problem this setting cannot cure.