starred/wsl-windows-toolbar-launcher
1
0
Fork 0
mirror of https://github.com/cascadium/wsl-windows-toolbar-launcher.git synced 2026-04-27 05:25:50 +03:00
Code Issues 4 Projects Releases 5 Packages Wiki Activity

[GH-ISSUE #31] Permission Error #29

New issue
Closed
opened 2026-03-04 12:24:03 +03:00 by kerem · 6 comments
kerem commented 2026-03-04 12:24:03 +03:00
Owner
Copy link

Originally created by @mfreeman-xtivia on GitHub (Dec 30, 2020).
Original GitHub issue: https://github.com/cascadium/wsl-windows-toolbar-launcher/issues/31

I have successfully installed this tool before but in a new instance of Ubuntu i am now receiving the error below:

2020-12-29 21:14:29,691[INFO]: distribution = Ubuntu
2020-12-29 21:14:29,692[INFO]: user = dev
2020-12-29 21:14:29,692[INFO]: confirm_yes = False
2020-12-29 21:14:29,692[INFO]: menu_file = /etc/xdg/menus/gnome-applications.menu
2020-12-29 21:14:29,692[INFO]: wsl_executable = C:\Windows\System32\wsl.exe
2020-12-29 21:14:29,692[INFO]: target_name = WSL
2020-12-29 21:14:29,692[INFO]: preferred_theme = Adwaita
2020-12-29 21:14:29,692[INFO]: alternative_theme = ('Papirus', 'Humanity', 'elementary-xfce')
2020-12-29 21:14:29,693[INFO]: jinja_template_batch = None
2020-12-29 21:14:29,693[INFO]: jinja_template_shell = None
2020-12-29 21:14:29,693[INFO]: rc_file = /home/dev/.bashrc
2020-12-29 21:14:29,693[INFO]: has_imagemagick = True
2020-12-29 21:14:29,693[INFO]: has_cairosvg = True
2020-12-29 21:14:29,693[INFO]: launch_directory = /home/dev
2020-12-29 21:14:29,693[INFO]: batch_encoding = None
2020-12-29 21:14:29,693[INFO]: use_batch_newline_crlf = False
2020-12-29 21:14:29,694[INFO]: install_directory = /mnt/c/Users/mfreeman/.config/wsl-windows-toolbar-launcher/menus/WSL
2020-12-29 21:14:29,694[INFO]: metadata_directory = /mnt/c/Users/mfreeman/.config/wsl-windows-toolbar-launcher/metadata/WSL
2020-12-29 21:14:29,694[INFO]: For full list of options available, call script again with --help
2020-12-29 21:14:29,694[INFO]: This script will write to the above locations if it can, but giving final chance to chicken out.
Press to continue or ctrl+c to abort.
2020-12-29 21:15:00,037[INFO]: Creating menu item for: Accessories/Byobu Terminal
Traceback (most recent call last):
File "/home/dev/.local/bin/wsl-windows-toolbar", line 8, in
sys.exit(cli())
File "/usr/lib/python3/dist-packages/click/core.py", line 764, in call
return self.main(*args, **kwargs)
File "/usr/lib/python3/dist-packages/click/core.py", line 717, in main
rv = self.invoke(ctx)
File "/usr/lib/python3/dist-packages/click/core.py", line 956, in invoke
return ctx.invoke(self.callback, **ctx.params)
File "/usr/lib/python3/dist-packages/click/core.py", line 555, in invoke
return callback(*args, **kwargs)
File "/home/dev/.local/lib/python3.8/site-packages/wsl_windows_toolbar/wsl_windows_toolbar.py", line 370, in cli
os.chmod(shell_launcher_path, 509)
PermissionError: [Errno 1] Operation not permitted: '/mnt/c/Users/mfreeman/.config/wsl-windows-toolbar-launcher/metadata/WSL/Accessories/Byobu Terminal.sh'

Originally created by @mfreeman-xtivia on GitHub (Dec 30, 2020). Original GitHub issue: https://github.com/cascadium/wsl-windows-toolbar-launcher/issues/31 I have successfully installed this tool before but in a new instance of Ubuntu i am now receiving the error below: 2020-12-29 21:14:29,691[INFO]: distribution = Ubuntu 2020-12-29 21:14:29,692[INFO]: user = dev 2020-12-29 21:14:29,692[INFO]: confirm_yes = False 2020-12-29 21:14:29,692[INFO]: menu_file = /etc/xdg/menus/gnome-applications.menu 2020-12-29 21:14:29,692[INFO]: wsl_executable = C:\Windows\System32\wsl.exe 2020-12-29 21:14:29,692[INFO]: target_name = WSL 2020-12-29 21:14:29,692[INFO]: preferred_theme = Adwaita 2020-12-29 21:14:29,692[INFO]: alternative_theme = ('Papirus', 'Humanity', 'elementary-xfce') 2020-12-29 21:14:29,693[INFO]: jinja_template_batch = None 2020-12-29 21:14:29,693[INFO]: jinja_template_shell = None 2020-12-29 21:14:29,693[INFO]: rc_file = /home/dev/.bashrc 2020-12-29 21:14:29,693[INFO]: has_imagemagick = True 2020-12-29 21:14:29,693[INFO]: has_cairosvg = True 2020-12-29 21:14:29,693[INFO]: launch_directory = /home/dev 2020-12-29 21:14:29,693[INFO]: batch_encoding = None 2020-12-29 21:14:29,693[INFO]: use_batch_newline_crlf = False 2020-12-29 21:14:29,694[INFO]: install_directory = /mnt/c/Users/mfreeman/.config/wsl-windows-toolbar-launcher/menus/WSL 2020-12-29 21:14:29,694[INFO]: metadata_directory = /mnt/c/Users/mfreeman/.config/wsl-windows-toolbar-launcher/metadata/WSL 2020-12-29 21:14:29,694[INFO]: For full list of options available, call script again with --help 2020-12-29 21:14:29,694[INFO]: This script will write to the above locations if it can, but giving final chance to chicken out. Press <enter> to continue or ctrl+c to abort. 2020-12-29 21:15:00,037[INFO]: Creating menu item for: Accessories/Byobu Terminal Traceback (most recent call last): File "/home/dev/.local/bin/wsl-windows-toolbar", line 8, in <module> sys.exit(cli()) File "/usr/lib/python3/dist-packages/click/core.py", line 764, in __call__ return self.main(*args, **kwargs) File "/usr/lib/python3/dist-packages/click/core.py", line 717, in main rv = self.invoke(ctx) File "/usr/lib/python3/dist-packages/click/core.py", line 956, in invoke return ctx.invoke(self.callback, **ctx.params) File "/usr/lib/python3/dist-packages/click/core.py", line 555, in invoke return callback(*args, **kwargs) File "/home/dev/.local/lib/python3.8/site-packages/wsl_windows_toolbar/wsl_windows_toolbar.py", line 370, in cli os.chmod(shell_launcher_path, 509) PermissionError: [Errno 1] Operation not permitted: '/mnt/c/Users/mfreeman/.config/wsl-windows-toolbar-launcher/metadata/WSL/Accessories/Byobu Terminal.sh'
kerem closed this issue 2026-03-04 12:24:04 +03:00
kerem commented 2026-03-04 12:24:05 +03:00
Author
Owner
Copy link

@fquinner commented on GitHub (Dec 30, 2020):

Possibly a different uid for the user on the new instance or something? What does the output from this look like:

ls -l /mnt/c/Users/mfreeman/.config/wsl-windows-toolbar-launcher/metadata/WSL/Accessories/Byobu Terminal.sh

You could also try deleting all of /mnt/c/Users/mfreeman/.config/wsl-windows-toolbar-launcher and let the script rebuild it.

If you want to run both instances alongside each other, you can use the -n OTHER which will create shortcuts in /mnt/c/Users/mfreeman/.config/wsl-windows-toolbar-launcher/menus/OTHER` instead.

<!-- gh-comment-id:752392315 --> @fquinner commented on GitHub (Dec 30, 2020): Possibly a different uid for the user on the new instance or something? What does the output from this look like: ls -l /mnt/c/Users/mfreeman/.config/wsl-windows-toolbar-launcher/metadata/WSL/Accessories/Byobu Terminal.sh You could also try deleting all of `/mnt/c/Users/mfreeman/.config/wsl-windows-toolbar-launcher` and let the script rebuild it. If you want to run both instances alongside each other, you can use the `-n OTHER` which will create shortcuts in /mnt/c/Users/mfreeman/.config/wsl-windows-toolbar-launcher/menus/OTHER` instead.
kerem commented 2026-03-04 12:24:05 +03:00
Author
Owner
Copy link

@mfreeman-xtivia commented on GitHub (Dec 30, 2020):

Yes i have nuked the entire /mnt/c/Users/mfreeman/.config/wsl-windows-toolbar-launcher folder now a couple of times now with no success.

dev@mhfwin:~$ ls -l /mnt/c/Users/mfreeman/.config/wsl-windows-toolbar-launcher/metadata/WSL/Accessories
total 124
-rwxrwxrwx 1 root root 88757 Dec 29 21:34 'Byobu Terminal.ico'
-rwxrwxrwx 1 root root 36541 Dec 29 21:34 'Byobu Terminal.png'
-rwxrwxrwx 1 root root    95 Dec 29 21:34 'Byobu Terminal.sh'
dev@mhfwin:~$
<!-- gh-comment-id:752587124 --> @mfreeman-xtivia commented on GitHub (Dec 30, 2020): Yes i have nuked the entire /mnt/c/Users/mfreeman/.config/wsl-windows-toolbar-launcher folder now a couple of times now with no success. ``` dev@mhfwin:~$ ls -l /mnt/c/Users/mfreeman/.config/wsl-windows-toolbar-launcher/metadata/WSL/Accessories total 124 -rwxrwxrwx 1 root root 88757 Dec 29 21:34 'Byobu Terminal.ico' -rwxrwxrwx 1 root root 36541 Dec 29 21:34 'Byobu Terminal.png' -rwxrwxrwx 1 root root 95 Dec 29 21:34 'Byobu Terminal.sh' dev@mhfwin:~$ ```
kerem commented 2026-03-04 12:24:05 +03:00
Author
Owner
Copy link

@fquinner commented on GitHub (Jan 1, 2021):

What distro you running? And what user are you running the script as? Can you also provide the output from the env command please? Also if you create a file on the windows mount what permissions does it have?

<!-- gh-comment-id:753343583 --> @fquinner commented on GitHub (Jan 1, 2021): What distro you running? And what user are you running the script as? Can you also provide the output from the `env` command please? Also if you create a file on the windows mount what permissions does it have?
kerem commented 2026-03-04 12:24:05 +03:00
Author
Owner
Copy link

@ccc-dvansevenant commented on GitHub (Jan 12, 2021):

I am experiencing a similar issue, with the additional note that my initial WSL2 creation was in a different user account on my computer (my personal account).

Now I am trying to set up WSL2 in a second account (my work account) on the same computer.

wsl-windows-toolbar runs fine in the Ubuntu-20.04 instance in my personal account.

wsl-windows-toolbar throws an error in the Ubuntu-20.04 instance in my work account.

Biggest difference I've noticed is that in my personal account, the drives in the Ubuntu instance are mounted as the instance user. In the work account, the drives are mounted as root.

There is some hint in the WSL community that additional accounts using WSL on the same system will not honour permissions properly.

I am trying to confirm this.

<!-- gh-comment-id:758632540 --> @ccc-dvansevenant commented on GitHub (Jan 12, 2021): I am experiencing a similar issue, with the additional note that my initial WSL2 creation was in a different user account on my computer (my personal account). Now I am trying to set up WSL2 in a second account (my work account) on the same computer. wsl-windows-toolbar runs fine in the Ubuntu-20.04 instance in my personal account. wsl-windows-toolbar throws an error in the Ubuntu-20.04 instance in my work account. Biggest difference I've noticed is that in my personal account, the drives in the Ubuntu instance are mounted as the instance user. In the work account, the drives are mounted as root. There is some hint in the WSL community that additional accounts using WSL on the same system will not honour permissions properly. I am trying to confirm this.
kerem commented 2026-03-04 12:24:05 +03:00
Author
Owner
Copy link

@ccc-dvansevenant commented on GitHub (Jan 21, 2021):

Just as an update, adding an /etc/wsl.conf to my Ubuntu 20.04 instance to set the permissions seems to have done the trick.

# Enable extra metadata options by default
[automount]
enabled = true
root = /mnt/
options = "metadata,umask=22,fmask=11"
mountFsTab = false

This appears to successfully mount available drives as my user, instead of root. My toolbars can be updated again.

Hopefully this helps.

<!-- gh-comment-id:764819709 --> @ccc-dvansevenant commented on GitHub (Jan 21, 2021): Just as an update, adding an /etc/wsl.conf to my Ubuntu 20.04 instance to set the permissions seems to have done the trick. ``` # Enable extra metadata options by default [automount] enabled = true root = /mnt/ options = "metadata,umask=22,fmask=11" mountFsTab = false ``` This appears to successfully mount available drives as my user, instead of root. My toolbars can be updated again. Hopefully this helps.
kerem commented 2026-03-04 12:24:05 +03:00
Author
Owner
Copy link

@fquinner commented on GitHub (Feb 18, 2021):

I happened to stumble across this after getting a wsl image that is --export'ed then --import'ed.

You can see something like this in mount -l:

C:\ on /mnt/c type 9p (rw,noatime,dirsync,aname=drvfs;path=C:\;uid=0;gid=0;symlinkroot=/mnt/,mmap,access=client,msize=65536,trans=fd,rfd=8,wfd=8)
D:\ on /mnt/d type 9p (rw,noatime,dirsync,aname=drvfs;path=D:\;uid=0;gid=0;symlinkroot=/mnt/,mmap,access=client,msize=65536,trans=fd,rfd=8,wfd=8)
E:\ on /mnt/e type 9p (rw,noatime,dirsync,aname=drvfs;path=E:\;uid=0;gid=0;symlinkroot=/mnt/,mmap,access=client,msize=65536,trans=fd,rfd=8,wfd=8)

Note the uid and gid are set to 0 (root user). When I updated wsl.conf to the above, it was very close, but the script would fail when run as non-root users because they couldn't execute cmd.exe (required). Plus it doesn't match what the original pre-export'd system reported with a non-root user set up which looks like this:

C:\ on /mnt/c type 9p (rw,noatime,dirsync,aname=drvfs;path=C:\;uid=1000;gid=1000;symlinkroot=/mnt/,mmap,access=client,msize=65536,trans=fd,rfd=8,wfd=8)
D:\ on /mnt/d type 9p (rw,noatime,dirsync,aname=drvfs;path=D:\;uid=1000;gid=1000;symlinkroot=/mnt/,mmap,access=client,msize=65536,trans=fd,rfd=8,wfd=8)
E:\ on /mnt/e type 9p (rw,noatime,dirsync,aname=drvfs;path=E:\;uid=1000;gid=1000;symlinkroot=/mnt/,mmap,access=client,msize=65536,trans=fd,rfd=8,wfd=8)

Note the uid and gid values are not set to 0 here. So I think for my use case at least the easiest thing is to put this in /etc/wsl.conf:

[automount]
options = "uid=1000,gid=1000"

Then run wsl --shutdown and restart the LxssManager windows service for the changes to take effect.

This creates a mount entry which has both 0 and 1000 in the line, but because 1000 comes later, it takes precedence.

Note the uid and gid values of 1000 may need to vary depending on what the id command retrieves inside the WSL execution environment.

<!-- gh-comment-id:781303208 --> @fquinner commented on GitHub (Feb 18, 2021): I happened to stumble across this after getting a wsl image that is --export'ed then --import'ed. You can see something like this in mount -l: ``` C:\ on /mnt/c type 9p (rw,noatime,dirsync,aname=drvfs;path=C:\;uid=0;gid=0;symlinkroot=/mnt/,mmap,access=client,msize=65536,trans=fd,rfd=8,wfd=8) D:\ on /mnt/d type 9p (rw,noatime,dirsync,aname=drvfs;path=D:\;uid=0;gid=0;symlinkroot=/mnt/,mmap,access=client,msize=65536,trans=fd,rfd=8,wfd=8) E:\ on /mnt/e type 9p (rw,noatime,dirsync,aname=drvfs;path=E:\;uid=0;gid=0;symlinkroot=/mnt/,mmap,access=client,msize=65536,trans=fd,rfd=8,wfd=8) ``` Note the `uid` and `gid` are set to `0` (`root` user). When I updated `wsl.conf` to the above, it was **very** close, but the script would fail when run as non-root users because they couldn't execute cmd.exe (required). Plus it doesn't match what the original pre-export'd system reported with a non-root user set up which looks like this: ``` C:\ on /mnt/c type 9p (rw,noatime,dirsync,aname=drvfs;path=C:\;uid=1000;gid=1000;symlinkroot=/mnt/,mmap,access=client,msize=65536,trans=fd,rfd=8,wfd=8) D:\ on /mnt/d type 9p (rw,noatime,dirsync,aname=drvfs;path=D:\;uid=1000;gid=1000;symlinkroot=/mnt/,mmap,access=client,msize=65536,trans=fd,rfd=8,wfd=8) E:\ on /mnt/e type 9p (rw,noatime,dirsync,aname=drvfs;path=E:\;uid=1000;gid=1000;symlinkroot=/mnt/,mmap,access=client,msize=65536,trans=fd,rfd=8,wfd=8) ``` Note the `uid` and `gid` values are not set to 0 here. So I think for my use case at least the easiest thing is to put this in `/etc/wsl.conf`: ``` [automount] options = "uid=1000,gid=1000" ``` Then run `wsl --shutdown` and restart the `LxssManager` windows service for the changes to take effect. This creates a mount entry which has both 0 and 1000 in the line, but because 1000 comes later, it takes precedence. Note the `uid` and `gid` values of `1000` may need to vary depending on what the `id` command retrieves inside the WSL execution environment.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
master
dependabot/pip/jinja2-3.1.3
feature/usability-fixes
feature/vm-support
feature/template-script
v0.6.3
v0.6.1
v0.6.0
v0.5.5
v0.5.4
v0.5.3
v0.5.2
v0.5.0
Labels
Clear labels   
duplicate

   
pull-request

Mirrored from GitHub Pull Request

No labels
duplicate
pull-request
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/wsl-windows-toolbar-launcher#29
No description provided.