A fresh Windows 11 24H2 machine shares a folder over SMB with nothing to install, yet nobody can reach it. Two defaults block it: the network profile is Public, and every File and Printer Sharing firewall rule is off. Fix those, give the share a real account, and a Samba share on Windows 11 works from Linux on the first try, signed and over SMB 3.1.1.
This guide sets up an SMB share on Windows 11 from PowerShell and from File Explorer, then covers share and NTFS permissions and how you reach the share from Linux with smbclient and mount.cifs. It also serves a Samba share from Linux to Windows and explains when SMB1 is worth enabling. Every command below was run in October 2026 on Windows 11 Enterprise 24H2 (build 26100) with an Ubuntu 26.04 client running Samba 4.23, and each error at the end came from that lab.
Set up an SMB share on Windows 11
Four things have to be true before any client can open a Windows 11 share, and the order matters because the first two decide whether port 445 answers at all:
- The network profile is Private
- File and Printer Sharing is allowed on that profile
- A local account exists for the people who connect
- The folder is shared with share permissions for that account
Our lab machine is named WIN11-01 at 10.0.1.50 and the Linux client is client01 at 10.0.1.51. Run the PowerShell steps from an elevated prompt (right-click Terminal, then Run as administrator), because every cmdlet below changes system settings. A normal prompt fails on the first Set- cmdlet with an access error, so you lose nothing by checking that first.
Switch the network profile to Private
Windows treats an unknown network as Public, and our clone came up that way. With the Public profile active, a Linux client gets no answer on port 445, not even a refusal, so smbclient just waits and fails with NT_STATUS_IO_TIMEOUT. Check what Windows decided before you change anything.
Get-NetConnectionProfile | Format-Table Name,InterfaceAlias,NetworkCategory -AutoSize
Ours read Public on the Ethernet adapter, which is the default for a network Windows has never been told to trust. That one word explains the timeout, so if yours says Public too, the next command is the real fix.
Name InterfaceAlias NetworkCategory
---- -------------- ---------------
Network Ethernet Public
Only switch a network you trust, such as your home or office LAN. A laptop that also joins café Wi-Fi keeps that Wi-Fi profile Public, which is exactly what you want. Change the wired adapter to Private.
Set-NetConnectionProfile -InterfaceAlias Ethernet -NetworkCategory Private
The same switch lives in Settings under Network & internet, then Ethernet (or Wi-Fi, then your network’s properties), where Network profile type offers Public and Private. After the change the page reads like this:

We rebooted the machine after this change and the profile stayed Private, so it’s normally a one-time step for a given network. If the share stops answering later, run Get-NetConnectionProfile again before you look anywhere else.
Allow File and Printer Sharing on the Private profile
A Private profile alone still does not open port 445. On our clean 24H2 install all 19 inbound rules in the File and Printer Sharing group were disabled, including File and Printer Sharing (SMB-In) for both the Domain profile and the combined Private, Public rule. Turning the whole group on with Enable-NetFirewallRule would also open SMB on Public networks, so scope the rules to Private while you enable them:
Get-NetFirewallRule -DisplayGroup 'File and Printer Sharing' | Where-Object { $_.Profile -match 'Private' } | Set-NetFirewallRule -Profile Private -Enabled True
List what is now on, because you want to see SMB-In with the Private profile and nothing else. If Public shows up in that column, something changed the rule after the pipeline ran, so run the pipeline again, because it rewrites the profile on every matching rule, and list the rules once more before you share anything.
Get-NetFirewallRule -DisplayGroup 'File and Printer Sharing' -Direction Inbound | Where-Object Enabled -eq True | Sort-Object DisplayName | Format-Table DisplayName,Profile,Enabled -AutoSize
Nine rules came back enabled, and every one of them is Private only.
DisplayName Profile Enabled
----------- ------- -------
File and Printer Sharing (Echo Request - ICMPv4-In) Private True
File and Printer Sharing (Echo Request - ICMPv6-In) Private True
File and Printer Sharing (NB-Datagram-In) Private True
File and Printer Sharing (NB-Name-In) Private True
File and Printer Sharing (NB-Session-In) Private True
File and Printer Sharing (SMB-In) Private True
File and Printer Sharing (Spooler Service - RPC) Private True
File and Printer Sharing (Spooler Service - RPC-EPMAP) Private True
File and Printer Sharing (Spooler Service Worker - RPC) Private True
The echo rules also make the machine answer ping, which helps when you troubleshoot from Linux. If you would rather open one port by hand, the Windows firewall port guide shows New-NetFirewallRule for TCP 445 and the same cmdlets work on Windows 11.
Create local accounts for the share
Give the people who connect their own local Windows accounts instead of handing out your login. We made two: josphat, who edits files, and auditor, who only reads them. Windows asks for each password without echoing it, so it never lands in your PowerShell history.
$pw = Read-Host -AsSecureString -Prompt 'Password'
New-LocalUser -Name josphat -Password $pw -FullName 'Josphat' -PasswordNeverExpires
New-LocalUser -Name auditor -Password $pw -FullName 'Read-only auditor' -PasswordNeverExpires
One password for both is fine for a lab. On a real network you should run Read-Host again before the second account. Neither account needs to be an administrator, and neither ever has to sign in at the Windows desktop for SMB to accept it.
Share the folder with New-SmbShare
PowerShell creates the share and its permissions in one command, which is faster than the dialogs and easy to repeat on the next machine. Create the folder, then share it with full access for one account and read access for the other.
New-Item -ItemType Directory -Path C:\Shares\Projects -Force
New-SmbShare -Name Projects -Path C:\Shares\Projects -FullAccess "$env:COMPUTERNAME\josphat" -ReadAccess "$env:COMPUTERNAME\auditor" -Description 'Team project files'
$env:COMPUTERNAME fills in your computer name, which is WIN11-01 here. The cmdlet prints the new share, and its Path column is the quickest check that you shared the folder you meant to.
Name ScopeName Path Description
---- --------- ---- -----------
Projects * C:\Shares\Projects Team project files
Check the share permissions it applied. This matters more than it looks, because whatever is listed here caps what any account can do over the network.
Get-SmbShareAccess -Name Projects
Only the two accounts are listed, and Everyone is not on it, which is what you get when you name accounts explicitly.
Name ScopeName AccountName AccessControlType AccessRight
---- --------- ----------- ----------------- -----------
Projects * WIN11-01\josphat Allow Full
Projects * WIN11-01\auditor Allow Read
Microsoft documents every parameter of the cmdlet, including -EncryptData and -FolderEnumerationMode, on the New-SmbShare reference page.
Share the folder from File Explorer
The GUI route ends in the same place. Right-click the folder, choose Properties, and open the Sharing tab. Skip the plain Share button, which picks permissions for you, and use the one below it.

- 1Sharing tab
- 2Advanced Sharing button
- Sharing tab
- Advanced Sharing button
The shield on the button means Windows elevates the dialog, so a standard user is asked for an administrator password here. In Advanced Sharing, tick the box, keep or change the share name, then open the share permissions.

- 1Share this folder
- 2Permissions button
- Share this folder
- Permissions button
A new share starts with Everyone set to Read. Remove Everyone, click Add, type the local account names, and tick Allow for the level each one needs. This is the dialog for the share we created in PowerShell, with josphat on Full Control.

Click OK on each dialog to apply. Whichever route you used, \\WIN11-01\Projects now exists, and the next thing that decides who can write to it is the folder’s own NTFS permissions.
Set share and NTFS permissions
Every SMB request passes two checks, and the stricter one wins. Share permissions apply only to network access, while NTFS permissions on the Security tab apply to everyone, local or remote. Read the table as what each of our two accounts ended up with:
| Account | Share permission | NTFS permission | Result over SMB |
|---|---|---|---|
| josphat | Full | Modify | Read and write |
| auditor | Read | Read & execute (plus Modify from Authenticated Users) | Read only |
| Anyone else | None | Inherited from C:\ | Access denied |
The middle row is the one that surprises people. A folder made directly under C:\ inherits Modify for Authenticated Users from the drive root, so on NTFS alone auditor could write. You should look at the inherited entries before you add anything.
icacls C:\Shares\Projects
The (I) flag marks inherited entries, and Authenticated Users carries (M), which is Modify.
C:\Shares\Projects BUILTIN\Administrators:(I)(OI)(CI)(F)
NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F)
BUILTIN\Users:(I)(OI)(CI)(RX)
NT AUTHORITY\Authenticated Users:(I)(M)
NT AUTHORITY\Authenticated Users:(I)(OI)(CI)(IO)(M)
Successfully processed 1 files; Failed processing 0 files
So the share permission is the only thing keeping auditor read-only here, and we proved it from Linux further down: the upload fails with NT_STATUS_ACCESS_DENIED. That is acceptable on a single-purpose share, but if the folder is also used locally, or you want NTFS to carry the rule on its own, put the share folders on a data drive or break inheritance. Either way, grant the two accounts explicit NTFS rights so the intent is written down on the folder itself:
icacls C:\Shares\Projects /grant 'josphat:(OI)(CI)M' 'auditor:(OI)(CI)RX'
Both accounts now appear at the top of the list without the (I) flag, which means they belong to this folder and its children.
C:\Shares\Projects WIN11-01\auditor:(OI)(CI)(RX)
WIN11-01\josphat:(OI)(CI)(M)
BUILTIN\Administrators:(I)(OI)(CI)(F)
NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F)
BUILTIN\Users:(I)(OI)(CI)(RX)
NT AUTHORITY\Authenticated Users:(I)(M)
NT AUTHORITY\Authenticated Users:(I)(OI)(CI)(IO)(M)
Successfully processed 1 files; Failed processing 0 files
One more default worth knowing: Windows 11 24H2 Enterprise, Pro and Education (not Home) require SMB signing in both directions, and requiring it also turns off guest access to shares, per Microsoft’s SMB signing page. Our machine reported RequireSecuritySignature as True for both Get-SmbServerConfiguration and Get-SmbClientConfiguration. The kernel CIFS client and smbclient on Ubuntu 26.04 signed without any extra option, so you do not have to change anything on the Linux side.
Access the Windows share from Linux
Two packages cover it on Ubuntu and Debian: smbclient for an FTP-like shell and quick tests, and cifs-utils for mounting the share as a directory. Ubuntu 26.04 ships Samba 4.23 and 24.04 ships 4.19, and the package names are the same on both, so you can paste the same command on either release.
sudo apt update
sudo apt install -y smbclient cifs-utils
On Fedora, Rocky Linux and AlmaLinux the packages are samba-client and cifs-utils. List the shares first, because that one command tests the firewall, the account and the password together. smbclient prompts for the password when you leave it off the command line:
smbclient -L //10.0.1.50 -U josphat
Our Projects share shows up next to the hidden administrative shares. Windows listed ADMIN$ and C$ to a non-admin account, so the list proves the firewall and the login work, not that you can open a given share.
Password for [WORKGROUP\josphat]:
Sharename Type Comment
--------- ---- -------
ADMIN$ Disk Remote Admin
C$ Disk Default share
IPC$ IPC Remote IPC
Projects Disk Team project files
SMB1 disabled -- no workgroup available
The last line is not an error. Browsing for a workgroup list needs SMB1, which Windows 11 does not have, so smbclient skips it; the share list above came over SMB2 or later. Also note the prompt says WORKGROUP\josphat even though the account lives on WIN11-01, and Windows accepted the login anyway.
To move a single file without mounting anything, open the share with -c commands. This uploads /etc/hostname and lists the folder.
smbclient //10.0.1.50/Projects -U josphat -c 'put /etc/hostname from-linux.txt; ls'
The new file sits next to the readme.txt we had created on the Windows side.
putting file /etc/hostname as \from-linux.txt (0.9 kB/s) (average 0.9 kB/s)
. D 0 Fri Oct 30 01:12:51 2026
.. D 0 Fri Oct 30 01:12:18 2026
from-linux.txt A 9 Fri Oct 30 01:12:51 2026
readme.txt A 21 Fri Oct 30 01:12:18 2026
16439551 blocks of size 4096. 9201316 blocks available
That round trip proves write access for josphat, so any later write failure points at permissions rather than the connection.
Mount the share with mount.cifs
For day-to-day use you want the share as a directory. Keep the password out of your shell history and out of /etc/fstab by putting it in a root-only credentials file:
sudo vim /root/.smb-win11-01
Add the account, its password and the Windows computer name as the domain. The file uses key=value lines with no quotes, so a password with spaces or a # goes in exactly as typed.
username=josphat
password=Your-Passw0rd
domain=WIN11-01
Lock the file down so only root can read it, then create the mount point. A world-readable credentials file hands the Windows password to every local user, so the chmod is not optional.
sudo chmod 600 /root/.smb-win11-01
sudo mkdir -p /mnt/projects
Mount it. The uid and gid options make the files belong to your Linux user, since Windows ACLs do not map to Linux owners, and the mode options set what ls -l shows:
sudo mount -t cifs //10.0.1.50/Projects /mnt/projects -o credentials=/root/.smb-win11-01,uid=$(id -u),gid=$(id -g),file_mode=0640,dir_mode=0750
We did not pass vers=, and that is deliberate: the kernel client negotiated the newest dialect on its own. Check the mount options to confirm what you got.
findmnt /mnt/projects
The options start with vers=3.1.1, the newest dialect both sides support:
TARGET SOURCE FSTYPE OPTIONS
/mnt/projects //10.0.1.50/Projects cifs rw,relatime,vers=3.1.1,cache=strict,upcall_target=app,username=josphat,domain=WIN11-01,uid=1000,forceuid,gid=1000,forcegid,addr=10.0.1.50,file_mode=0640,dir_mode=0750,soft,nounix,serverino,mapposix,reparse=nfs,nativesocket,symlink=native,rsize=4194304,wsize=4194304,bsize=1048576,echo_interval=60,actimeo=1,closetimeo=1
The whole Linux side fits in one terminal, from the share list to the mounted folder on client01:

On the Windows side, Get-SmbSession confirms which account connected and which dialect it used:
Get-SmbSession | Format-Table ClientComputerName,ClientUserName,Dialect,NumOpens -AutoSize
You should see one session from the Linux client, signed in as the local account.
ClientComputerName ClientUserName Dialect NumOpens
------------------ -------------- ------- --------
10.0.1.51 WIN11-01\josphat 3.1.1 1
If the user column shows a different name, the client used other credentials than you think, and that is the first thing to check when permissions look wrong.
Mount the share at boot
A plain fstab entry stalls the boot when the Windows machine is asleep. The systemd automount options avoid that: nofail lets boot continue without the share, and x-systemd.automount mounts it the first time something opens the directory. Open fstab.
sudo vim /etc/fstab
Add one line, using your own uid and gid from id. Get those numbers wrong and the mount still works, but every file shows up owned by someone else, so your editor refuses to save.
//10.0.1.50/Projects /mnt/projects cifs credentials=/root/.smb-win11-01,uid=1000,gid=1000,file_mode=0640,dir_mode=0750,_netdev,nofail,x-systemd.automount 0 0
Reload systemd so it generates the automount unit, then mount everything in fstab.
sudo systemctl daemon-reload
sudo mount -a
We rebooted the client to prove it. Right after boot the automount unit was waiting, and listing the directory triggered the real CIFS mount on top of the autofs placeholder:
mnt-projects.automount loaded active waiting mnt-projects.automount
TARGET SOURCE FSTYPE
/mnt/projects systemd-1 autofs
/mnt/projects //10.0.1.50/Projects cifs
The same approach suits any network filesystem; our NFS client guide for Rocky and AlmaLinux uses it for NFS exports. If you dual-boot instead of running two machines, the Fedora and Windows 11 dual-boot guide covers sharing files between the two installs on one disk.
Share a Linux folder with Windows 11 using Samba
The reverse direction is where Samba itself runs: the Linux box serves the folder and Windows 11 connects to it. The trap is guest access. Ubuntu’s stock smb.conf sets map to guest = bad user, which turns an unknown user into a guest. Windows 11 Pro, Enterprise and Education refuse guest sessions, so the result looks like a password problem. Give Windows a real Samba account and the share works. Install the server on the Linux machine.
sudo apt install -y samba
Create a group-owned folder for the share. The setgid bit (the 2 in 2770) makes new files inherit the smbteam group, so everyone in the group can edit each other’s files. The commands use $USER, your own Linux login, which is josphat on our box:
sudo groupadd -f smbteam
sudo usermod -aG smbteam $USER
sudo mkdir -p /srv/samba/team
sudo chgrp smbteam /srv/samba/team
sudo chmod 2770 /srv/samba/team
Back up the stock config, then open it. The backup gives you a clean copy to diff against when a share stops working months later, so it is worth the extra second.
sudo cp /etc/samba/smb.conf /etc/samba/smb.conf.orig
sudo vim /etc/samba/smb.conf
Ubuntu’s defaults already fit a standalone server (workgroup = WORKGROUP, server role = standalone server), so leave [global] alone and append the share at the end of the file:
[team]
comment = Team files on client01
path = /srv/samba/team
valid users = @smbteam
read only = no
create mask = 0660
directory mask = 2770
Samba keeps its own password database, separate from /etc/shadow, so the Linux user needs a Samba password before Windows can log in. smbpasswd asks for it twice:
sudo smbpasswd -a $USER
Validate the file with testparm before the restart, because a typo there stops smbd from serving any share.
testparm -s && sudo systemctl restart smbd
testparm should print Loaded services file OK. and the [team] section back to you. Ubuntu 26.04’s default config also sets disable netbios = Yes, which is why nmbd stayed inactive on our box and the Linux server did not show up under Network in File Explorer. You do not need browsing, though, because you can type the path.
If ufw is active on your server, allow the Samba application profile with sudo ufw allow Samba (the name is case-sensitive); ours was inactive, and the rule was added for when it comes on. From Windows 11, map the share to a drive letter with the Samba account:
net use T: \\10.0.1.51\team * /user:client01\josphat
The * makes net use prompt for the password; it then maps T: and answers with The command completed successfully. In File Explorer, select This PC, open the See more (…) menu and choose Map network drive, then tick Connect using different credentials. Check what Windows negotiated.
Get-SmbConnection | Format-Table ServerName,ShareName,Dialect,Signed,Encrypted -AutoSize
Signed reads True. Windows 11 demands signing, and Samba 4.23 signed with AES-128-GMAC without any server signing line in the config:
ServerName ShareName Dialect Signed Encrypted
---------- --------- ------- ------ ---------
10.0.1.51 IPC$ 3.1.1 True False
10.0.1.51 team 3.1.1 True False
We also added a [public] share with guest ok = yes to see what Windows 11 does with it. From a Windows user that had no Samba account, net use answered with a password error, and the SMBClient Security event log recorded why:
The password is invalid for \\10.0.1.51\public.
Event 31017: Rejected an insecure guest logon.
This event indicates that the server attempted to log the user on as an
unauthenticated guest and was denied by the client.
Windows 11 Home does not require signing, per Microsoft, so a Home client may behave differently; we tested Enterprise only. Microsoft’s fix is a Group Policy setting, Enable insecure guest logons, and the same page says SMB signing must be turned off as well for guest logons to work. We did not do that, and we do not recommend it: one Samba account per person costs a minute and keeps signing on. For more on the server side, including SELinux contexts on RHEL-family systems, see the Samba file share guide for Fedora.
Enable SMB1 on Windows 11 only for old devices
SMB1 is not installed on Windows 11, and you only need it for hardware that can’t speak anything newer: an old NAS, a scanner that saves to a share, a media player from the SMB1 era. Microsoft states on its SMBv1 detect and enable page that it is not installed by default in any edition of Windows 11, and our machine agreed. Check the feature first.
Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol | Format-List FeatureName,State
It reported State : Disabled. A Linux client forced onto SMB1 against that machine fails with mount error(112): Host is down, shown in the error section below. Enabling it takes one command and a restart.
Enable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol -NoRestart
Restart-Computer
The cmdlet answered RestartNeeded : True. After the reboot, mount -t cifs ... -o vers=1.0 from the Linux client mounted the share, and the kernel logged its warning that vers=1.0 is the less secure dialect. Turning SMB1 on does not lift the signing requirement, so a device that can’t sign may still fail. When the old device is gone, remove the feature and restart again.
Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol -NoRestart
Restart-Computer
We ran that on the lab machine and the state went back to Disabled, with the vers=1.0 mount failing again. If the device in question is a VM rather than old hardware, update its drivers or OS instead; the VirtIO driver guide covers the storage and network side for Windows guests on KVM and Proxmox.
Fix common SMB errors from Linux
Each of these came from the lab while building this guide, with the cause we confirmed, so you can match your message to ours. Most of them are about the account or the network profile, not about Samba itself.
Connection to 10.0.1.50 failed (Error NT_STATUS_IO_TIMEOUT)
The Windows firewall is dropping port 445. On our fresh install that meant the Public profile plus the disabled SMB-In rules. Run Get-NetConnectionProfile on Windows; if it says Public, switch it to Private and enable the File and Printer Sharing rules as shown earlier. A timeout is never a password problem, because the request never reached the SMB server.
session setup failed: NT_STATUS_LOGON_FAILURE
The connection worked but the user name or password didn’t. mount.cifs reports the same failure as mount error(13): Permission denied, and dmesg shows Status code returned 0xc000006d STATUS_LOGON_FAILURE. Check the credentials file for a trailing space and confirm the account with Get-LocalUser on Windows.
NT_STATUS_ACCESS_DENIED opening remote file
Login succeeded but the write didn’t. Our auditor account hit this on put while get worked, which is the Read share permission doing its job. If the account should write, raise its share permission and check its NTFS rights with icacls.
NT_STATUS_ACCESS_DENIED or NT_STATUS_ACCOUNT_DISABLED without a user
An anonymous smbclient -N got NT_STATUS_ACCESS_DENIED and -U guest% got NT_STATUS_ACCOUNT_DISABLED, because the built-in Guest account is disabled on Windows 11. That is the intended behaviour, so connect with a named account rather than trying to turn Guest on.
mount error(112): Host is down
We got this by forcing vers=1.0 against a Windows 11 machine without SMB1. The full message also says Server abruptly closed the connection, and the hint underneath it to try vers=1.0 is misleading here, because 1.0 is the cause. Drop the vers= option so the client negotiates SMB 3.1.1, and only install SMB1 if the server really is an SMB1-only device.
The password is invalid for \\server\share
Windows 11 sees this when a Samba server hands it a guest session. Look for event ID 31017 in Event Viewer under Applications and Services Logs, Microsoft, Windows, SMBClient, Security; if it says Rejected an insecure guest logon, create a Samba user with smbpasswd -a and connect with net use and /user:. Once you have a working share, the Ubuntu 26.04 feature overview is a good next read if the Linux side is a fresh install.