Access Denied error on Windows 10

[SMUsamaShah]

I downloaded cosmos-3.0.1.zip and extracted to C:\

If I try to run bash using either Powershell or CMD it opens a dialog asking which application do I want to run it with.

This is what I see if I rename bash to bash.exe

From powershell:

PS C:\bin> ./bash.exe
Program 'bash.exe' failed to run: Access is deniedAt line:1 char:1
+ ./bash.exe
+ ~~~~~~~~~~.
At line:1 char:1
+ ./bash.exe
+ ~~~~~~~~~~
    + CategoryInfo          : ResourceUnavailable: (:) [], ApplicationFailedException
    + FullyQualifiedErrorId : NativeCommandFailed

From CMD:

C:\bin>bash.exe
Access is denied.

Also tried

PS C:\WINDOWS\system32> $ACL = Get-ACL -Path C:\Users\myname
PS C:\WINDOWS\system32> $ACL | Set-ACL -Path C:\bin

but this did not change anything.

(I have not tried on personal machine yet. I suspect these executables need some special permissions to run which are disabled by system admins.)

EDIT:

Windows Terminal (and Terminal Preview) throws this error

[error 2147942405 (0x80070005) when launching `C:\bin\bash -l']

[dflock]

I have something that looks very similar to this. I'm running Windows 10 on my work machine.

• I downloaded cosmos-3.0.1.zip and extracted to C:\Users\DuncanLock\cosmos-3.0.1.
• I created a new profile in Windows Terminal called Bash (Cosmos 3.0.1) and set the Command Line to C:\Users\DuncanLock\cosmos-3.0.1\bin\bash -l
• When I open a new tab using this profile, I get the following error:

shell-init: error retrieving current directory: getcwd: cannot access parent directories: ENOENT/2/No such file or directory/18/There are no more files
bash-5.2$

It doesn't seem to matter what I set the "Starting Directory" to.

If I open a regular PowerShell tab and run Get-ACL in those folders, I get this:

~\cosmos-3.0.1
❯ Get-ACl

    Directory: C:\Users\DuncanLock

Path         Owner              Access
----         -----              ------
cosmos-3.0.1 AzureAD\DuncanLock NT AUTHORITY\SYSTEM Allow  FullControl…


~\cosmos-3.0.1\bin
❯ Get-ACl

    Directory: C:\Users\DuncanLock\cosmos-3.0.1

Path Owner              Access
---- -----              ------
bin  AzureAD\DuncanLock NT AUTHORITY\SYSTEM Allow  FullControl…

which indicates that I own those folders, I think?

[jart]

@dflock can you try adding "startingDirectory": "C:\\" there?

[dflock]

That worked, thanks!!

Once bash started correctly, it couldn't find any commands, so I:

• created an NTFS symlink from C:\Users\DuncanLock\cosmos-3.0.1 -> C:\Users\DuncanLock\cosmos
• added C:\Users\DuncanLock\cosmos\bin to my PATH, using Windows shitty 'Environment Variables for your Account' thing.

Now it works and can find all its commands!!!

bash-5.2$ pwd
/
bash-5.2$ ls
'$WinREAgent'   Intel   OneDriveTemp  'Program Files'  'Program Files (x86)'   ProgramData   SWTOOLS   Users   Windows   index
bash-5.2$ ls -halp
total 52K
drwx------ 1 DuncanL 25848    0 Oct 17 22:02 '$WinREAgent'/
drwx------ 1 DuncanL 25848    0 Oct 29 09:32  Intel/
drwx------ 1 DuncanL 25848    0 Apr 26  2023  OneDriveTemp/
drwx------ 1 DuncanL 25848  12K Apr 28  2023 'Program Files'/
dr-x------ 1 DuncanL 25848 8.0K Apr 28  2023 'Program Files (x86)'/
drwx------ 1 DuncanL 25848 8.0K Nov  2 15:59  ProgramData/
drwx------ 1 DuncanL 25848    0 Jun  2  2022  SWTOOLS/
dr-x------ 1 DuncanL 25848 4.0K Oct  9 18:34  Users/
drwx------ 1 DuncanL 25848  20K Oct 27 20:00  Windows/
drwx------ 1 DuncanL 25848    0 Jun 19 23:52  index/
bash-5.2$

[avih]

• When I open a new tab using this profile, I get the following error:

shell-init: error retrieving current directory: getcwd: cannot access parent directories: ENOENT/2/No such file or directory/18/There are no more files
bash-5.2$

First thing which happens for me after I run bash -l from cmd.exe prompt is that it seems hanged, with 0% CPU usage. Pressing ENTER few times does not bring it out. Pressing ^C does interrupt whatever was hanging, and it gets to the prompt.

EDIT: the hang above seem to be related to failure to create tmp file for a here document at my existing ~/.profile. Ignore this for now.

Then, as far as I can tell, this directory error can be solved by setting $PWD correctly (to the current working dir) before running bash. If launched from a cmd.exe shell, then that can be:

set "PWD=%cd%"

(%cd% seem to be a virtual env var. It does not appear at the output of set)

I extracted it to a non-C dir, specifically, to d:\run\cosmos (which has bin and libexec subdirs), and I noticed that I also had to set $HOME correctly, or else it remains unset inside the bash prompt, and some apps misbehave (like vim).

I also had to prefix the bin dir to $PATH before running bash so that it can find the utils at bin (in cmd.exe syntax if executed at the bin dir: set "PATH=%cd%;%PATH%).

I don't know which of those ($HOME, $PATH, $PWD) are related to the fact that it's not extracted at the root of C:\, but if that's due to the extraction dir, then it would be nice to be able to extract it in places other than C:\, though it's still nice that it seems solvable even otherwise.

It also seems that the git commands in libexec do work, e.g. git pull does work in a git repo dir, but doesn't work if renaming libexec to something else (with error git: 'remote-https' is not a git command). Not sure how it knows to find the libexec dir. Maybe "$(dirname -- "$(which git)")"/../libexec/whatever ?

There also appears to be some virtual paths which are not enumerated as far as I can tell, e.g. /<drive-letter>, or /tmp (which maps to $TEMP). But once used explicitly, they do work in ls. E.g. ls / does the windows logic and shows nothing but the files at the root of the current drive, but ls /d or ls /tmp do show the content of the virtual paths.

Also, when using vim, setting TERM=xterm-256color seems to help with using more colors and possibly nicer behavior by default. Also, xterm mouse wheel does work when configured in ~/.vimrc. W00t! FWIW, I don't think mouse wheel can be enabled in the native windows (terminal) vim.

However, mouse events seem to be enabled/translated even without requesting (xterm) mouse events, which leads to mouse wheel at the bash prompt scrolling commands history rather the terminal backlog (if wheel is translated to keys on its own, a good common practice is to only do that at the alt screen).

Otherall, this is pretty amazing.

[avih]

Then, as far as I can tell, this directory error can be solved by setting $PWD correctly (to the current working dir) before running bash.

This is no longer required with 3.0.2: $PWD is now set correctly in bash even without setting it before starting bash, and pwd works too (previously $PWD was otherwise unset and pwd didn't work). Thanks.

However, setting $HOME is still required in advance even after the cwd fix. Otherwise, $HOME remains unset in bash, but it seems to be considered CWD when bash was launched, e.g. ls ~/ lists files at the pre-launch CWD, and .bash_history is created at this dir as well.

Similarly, prefixing the bin path to $PATH is also still required.

[SMUsamaShah]

I tested this on personal laptop and it works there. Tried cosmos.3.1.3 again on work machine which still produces same access denied error.

Bash works just fine on personal laptop. There is some other issue with utils though. I was doing rsync from usb to hdd (thousands of files) and it was failing every now and then with broken pipe error. Ended up installing WSL and rsync completed successfully in one go.