If you’re running Windows inside WinBoat on Linux and struggling to access or write to the \\host.lan\Data network share, this comprehensive guide will walk you through the exact steps to fix it.
Quick Fix (TL;DR)
Total time: ~4 minutes
Step 1: Create Secure Shared Directory
# Create dedicated shared folder
mkdir -p ~/shared
chmod 777 ~/shared
# Stop WinBoat
cd ~/.winboat
docker-compose down
# Edit docker-compose.yml
nano docker-compose.yml
Find "${HOME}:/shared" and change it to:
- "${HOME}/shared:/shared"
# Restart WinBoat
docker-compose up -d
Step 2: Stop Conflicting Samba
sudo systemctl stop smb
sudo systemctl disable smb
Step 3: Fix Write Permissions
# Get container ID
CONTAINER_ID=$(docker ps | grep WinBoat | awk '{print $1}')
# Update Samba config
docker exec $CONTAINER_ID sh -c "cat > /etc/samba/smb.conf << 'EOF'
[global]
server string = Dockur
netbios name = host.lan
workgroup = WORKGROUP
interfaces = dockerbridge
bind interfaces only = yes
security = user
guest account = nobody
map to guest = Bad User
server min protocol = NT1
follow symlinks = yes
wide links = yes
unix extensions = no
log level = 3
load printers = no
printing = bsd
printcap name = /dev/null
disable spoolss = yes
[Data]
path = /shared
comment = Shared
writable = yes
browseable = yes
guest ok = yes
public = yes
read only = no
create mask = 0777
directory mask = 0777
force create mode = 0666
force directory mode = 0777
EOF"
# Restart Samba
docker exec $CONTAINER_ID killall smbd
Step 4: Test from Windows
net use \\host.lan /delete
net use \\host.lan
echo test > \\host.lan\Data\test.txt
dir \\host.lan\Data
✅ Done! You should now have full read/write access.
The Problem
When trying to access \\host.lan\Data from Windows inside WinBoat, users encounter:
Windows cannot access \\host.lan\Data
You do not have permission to access \\host.lan\Data.
Even when the share is visible, writing files fails with “Access is denied.”
Root Causes
After extensive investigation, three main issues were identified:
1. Insecure Home Directory Mount
Problem: WinBoat’s default configuration mounts your entire home directory:
This exposes sensitive files (.ssh keys, browser data, etc.) and had permission issues (700 permissions blocking container access).
Solution: Use a dedicated shared directory instead:
- "${HOME}/shared:/shared"
2. Conflicting Samba Servers
Problem: Two Samba servers running simultaneously:
- Host systemd Samba service
- WinBoat’s container Samba
This caused routing confusion and AppArmor security blocks.
Solution: Disable the host Samba service - WinBoat has its own built-in Samba server.
3. Samba Permission Configuration
Problem: The Samba configuration used force user = root + guest only = yes, which failed to properly map guest users to root, blocking write operations.
Solution: Remove forced user mapping and set proper file creation masks to allow the guest (nobody) user to write files.
Network Architecture
Understanding how WinBoat networking works:
Linux Host (192.168.0.186)
↓
Docker Bridge (172.22.0.1) ← WinBoat Container (172.22.0.2)
↓ ↓
↓ Internal Bridge (20.20.20.1) - Samba Server
↓ ↓
└────────[NAT/Routing]─→ Windows Guest (20.20.20.21)
- Windows resolves
host.lan to 20.20.20.1 (WinBoat’s internal bridge)
- Traffic gets NATed through the container to reach your Linux host
- Samba serves files from the
/shared mount point
Key Technical Insights
AppArmor and Docker Containers
Important: AppArmor on the host does NOT apply to processes inside Docker containers. The AppArmor denials observed were from the host Samba service, not WinBoat’s containerized Samba.
Samba Force User Directive
The combination of force user = root, force group = root, and guest only = yes doesn’t work as expected. Samba fails to properly map guest connections to root in this configuration, blocking write operations even though the config claims to allow them.
Better approach: Let the guest user (nobody) write files directly with appropriate create masks:
create mask = 0777 - Files are writable by allforce create mode = 0666 - Forces specific file permissionsdirectory mask = 0777 - Directories are writable by allforce directory mode = 0777 - Forces specific directory permissions
File Creation Masks Matter
Default Samba create mask = 0744 makes files read-only for group/others. For shared storage accessible by Windows guests, use 0777 masks with forced modes to ensure write access.
Security Considerations
Before (Insecure)
volumes:
- "${HOME}:/shared" # Exposes entire home directory!
Risks:
- SSH keys accessible
- Browser history/cookies exposed
- GPG keys accessible
- All personal files readable
After (Secure)
volumes:
- "${HOME}/shared:/shared" # Only exposes ~/shared
Benefits:
- Home directory stays private (700 permissions)
- Only intended files are shared
- Easy to audit what’s exposed
- Follows principle of least privilege
Usage
Share Files from Linux to Windows
# Copy files to shared directory
cp ~/Documents/myfile.pdf ~/shared/
# Create subdirectories
mkdir -p ~/shared/projects
cp -r ~/work/myproject ~/shared/projects/
Files appear instantly in Windows at \\host.lan\Data\
Share Files from Windows to Linux
rem Copy file
copy C:\Users\sjs\Desktop\file.txt \\host.lan\Data\
rem Copy directory
xcopy C:\Documents\project \\host.lan\Data\project\ /E /I
Access from Linux at /home/YOUR_USERNAME/shared/
Map as Network Drive
For convenience, map it as a drive letter in Windows:
net use Z: \\host.lan\Data /persistent:yes
Now accessible as Z: drive in File Explorer.
Troubleshooting
Share Becomes Inaccessible After Reboot
# Restart WinBoat
cd ~/.winboat
docker-compose restart
# Or restart just Samba
docker exec $(docker ps | grep WinBoat | awk '{print $1}') killall smbd
Samba Config Lost After Container Recreate
The Samba configuration changes are lost when the container is recreated. To persist them:
- Save the Samba config to your host:
cat > ~/.winboat/custom-smb.conf << 'EOF'
[global]
# ... (full config here)
EOF
- Mount it in
docker-compose.yml:
volumes:
- "./custom-smb.conf:/etc/samba/smb.conf:ro"
Check Current Samba Configuration
CONTAINER_ID=$(docker ps | grep WinBoat | awk '{print $1}')
docker exec $CONTAINER_ID testparm -s
Verify these settings in the [Data] section:
read only = Nowritable = yescreate mask = 0777directory mask = 0777
For those interested in troubleshooting similar issues:
# Network inspection
docker inspect <container> --format ''
docker exec <container> ip addr show
ss -tlnp | grep 445 # Check SMB ports
# Samba debugging
docker exec <container> testparm -s
docker exec <container> smbstatus
docker logs <container>
# Permission checking
stat /path/to/directory
getfacl /path/to/directory
dmesg | grep apparmor # Check for security blocks
# Container processes
docker exec <container> ps aux | grep smbd
Conclusion
WinBoat provides excellent Windows-in-Docker functionality, but the default file sharing configuration has security and permission issues. By:
- Using a dedicated shared directory instead of mounting your entire home
- Disabling conflicting host Samba services
- Properly configuring Samba file creation masks
You get secure, fully functional bidirectional file sharing between your Linux host and Windows guest.
Total investigation time: ~4 hours
Time to fix once you know the solution: ~4 minutes
Related Issues:
All commands tested on Manjaro Linux (Kernel 6.16.8) with WinBoat 5.03 running Windows 11 Pro.
I’ve put Claude Code to investigate the issue, fix it, and write this detailed blog post. ^__^
]]>