[Bug] Permission denied on Network\host.lan
What version of WinBoat are you running?
WinBoat Beta v0.8.3 Prod
Your Environment
Manjaro linux XFCE FreeRDP 2:3.17.0-1 from Arch Linux repository
Steps to Reproduce / Context
I get "permission denied" when I try to access my shared Home folder. I have the sharing enabled under Configuration. I open File Explorer, click on host.lan under Network, and see one folder called Data. Attempting to open this folder gives permission denied. Perhaps I need to grant permission on the linux side or something, but I could find no documentation on this.
Logs
Expected Behavior
I should be able to see my linux home directory when I open Network/host.lan
Current Behavior
Permission is denied
Possible Solution
No response
Quality Notice
- [x] I have checked the issue tracker and verified that this bug is a unique case.
Can confirm the bug on Nobara 42
Problem persists with 0.8.5 on Ubuntu 24.04.3
Same here with Linux Mint 22.2
Same here on OpenSuse tumbleweed
Can confirm the bug on Zorin Core 18 (Base Ubuntu 24.04.3)
Same on opensuse tumbleweed
I can confirm the same bug on openSUSE Tumbleweed.
I am on Nobura Linux 42 and the same issue is happening on my end.
Small update: On another Nobara 42 system, first it was not working but then it was working. I don't know what I did. I can only say, the VM was running for several minutes.
Same issue on Nobara 42 with BTRFS
I have the same issue with winboat 0.8.7, win 11 on manjaro. Any (temporary) fix available?
I have permission denied on host.lan\Data, is it the same issue ?
One more for openSUSE Tumbleweed, no matter whether from rpm or AppImage. Also tried after adding Admin privs to a 2nd Windows user account (which is accessible via logout from the initial user, in webpage only it seems), same error.
Are you guys experiencing this error with windows 11 or 10?
Windows 11 Pro, on Nobara 42.
Are you guys experiencing this error with windows 11 or 10?
10 and 11.
Windows 11
Windows 11 from a recent ISO used as installation source
This is currently a showstopper for me:-(
I have 2 arch PCs, on one it works, on the other it does not
Same on Arch - with Win11
Same issue using nobara 42 an Windows 11 Pro with the appimage. Currently using localsend to transfer files.
Tested on OpenSuse Tumbleweed. First i had no internet access at all from Windows but after joining the bridge network (via Portainer) internet access and shared folders are working fine.
Maybe also interesting, I installed docker only for winboat. Before I used only podman on my Nobara 42 systems. So winboat is also the only container which created a network interface for docker.
I didn't know about Portainer, installed it and joined the bridge network, without any change. Although for me it's just host.lan - accessing internet works, I installed Firefox via Edge and it works perfectly fine so far.
The internet access is not the issue here. The issue is access to a directiry on the host sytsem. @SimeonEhrig and @edogawa23 please do not start discussing other issues here.
well I thought it is after reading @DoerrSt 's remark, but OK... I'm somewhat lost where to start or what to look for, being mostly unfamiliar with docker.
I'm having the same issue with Win11Pro. Unfortunately, it's a show-stopper. I'll check back after a while to see if the problem has been resolved. Otherwise, the usefulness is unfortunately too limited. But it is a beta, so this is not a complaint.
Another Nobara 42 confirmation here.
I fully believe the issue is with the permissions of the folder and the mount. Looking at the docker compose (/home/<USER>/.winboat) it's pointing to ${HOME} which by default should be a 700, that only gives the owner permissions so the SMB user doesn't have permission. The better way to handle this would be to setup a shared folder if you want to move files across the system. It may be cumbersome but this is how I've done it with VM's for a long while now. That's better than exposing your entire home directory if you are considering security. I'm going to modify the docker yml file to account for this and start a rebuild of the container (bummer because I already debloated the instance, might use a mini 11 image instead). I might build a cleanup script as well to wipeout anything related to Winboat for something fresh.
Same issue on Nobara 42