I'm trying to install moodle4mac on Catalina via a .dmg file. The .dmg file mounts okay. However, when I try to drag the MAMP folder to the Applications folder, I get the message "The operation can’t be completed because you don’t have permission to access some of the items."
When install dialog is showing 4 folders;
.DocumentRevisions-V100
.TemporaryItems
.Trashes
.fseventsd
The first three have no go signs on the folders suggesting that these are the problematic ones. I have checked the read/write permissions of the Applications folder, which looks fine. I have also run sudo spctl --master-disable which gives me the opportunity to download apps from anywhere, but this does not make any difference.
Any pointers greatly welcome!
Okay. It turns out the culprit was Sophos Home Antivirus. There was no indication in any of the error messages that Sophos was blocking this, hence I did not put two and two together. However, a warning message about the mounted volume popped up this morning, and I was able to trace this back to Sophos. It would be great if Sophos / MacOS could provide more detailed messages regarding such errors in future.
Related
I'm using Pop OS 20.4 and installed Unity Hub from its store (I think it just downloads the app image from the Unity website and installs it but I don't know).
I set a personal license and want to install the version 2020.1.15f1. As you can see on the next tab there is enough space to install it
Unfortunately I get this error message when trying to install it
at the bottom of the hub this toast message appears
Does someone know what's wrong here? I clearly have enough space on my disk.
I get the same error for other versions too.
Ok here is the solution that worked for me:
Instead of installing it from the Pop OS store I uninstalled this Unity hub version. I restarted my machine and installed the .appimage file from the official website. I copied that file into the root of my home directory. When executing this version there was no error for me.
The reason why it is showing this error is because there is not enough space in your root directory. Typically this happens when there is only a single partition (at least in my case). So a workaround for this is to create a folder in you HOME directory called tmp and running the UnityHub.AppImage file pointing to that tmp folder and the application gets ample amount of space to install. It looks something like this :
TEMP=~/tmp ./UnityHub.AppImage
You can go to this link for further details.
I'm working on a disconnected network, so some options are a bit limited. Also, we have SAs who handle stuff like system updates (so, for instance, it is possible that there was a system update in there that I know nothing about).
However, I had 1.33.1, then 1.34.0, then 1.38 versions of VSCode working on my (Windows 10) machine. One day, for no apparent reason (I hadn't just installed something, for instance), 1.38 stopped working. It wouldn't even start up. Running 'Code --verbose' from the command line produced no output (the mouse cursor turned briefly to a spinner, but nothing even showed up in Task Manager, let alone something like a splash screen).
I did get an error message in the Application log, which included the lines (more or less; remember, no cut-n-paste possible):
Faulting Application Code.exe, version: 1.38.0
Faulting module ntdll.dll, version 10.0.16299.936
Exception code: 0xc0000374
Faulting Application path: c:\Program Files\Microsoft VS Code\Code.exe
Faulting module path: c:\Windows\System32\ntdll.dll
Re-installing VS Code (with or without system restart after uninstall) did nothing.
Removing all extensions (we have a bunch) did nothing
Installing 1.39.2 did nothing
The only good thing is that I can still run 1.34.0, if I reinstall that (did not try 1.33.1, and I don't have any in-between versions from 1.34 to 1.38 to try). So at least I'm not completely shut out.
I also tried deleting basically all of workspaceStorage, to no effect. Nor did renaming my storage.json.
The biggest weirdness, to me, is that the path to ntdll.dll is in System32, rather than in SysWOW64 (is there some way to force usage of the latter?). Second, why did 1.38.0 work just fine for a while, and then stop.
So, I'm curious if anyone else has seen this problem, and/or if anyone has any idea what else could be done to get more insight into what's causing this.
(edit: I plan to file bug for VSCode, but been waiting on confirmation email to finish creating my github acct for some time now. sigh)
I've had exactly the same problem twice. I'd been running the application since June 2019 and then in March of this year, Yep! Exact same problem as you encountered. A simple reinstall fixed that, but I've had the same problem again today and after some investigation, Windows 10 was telling me that I didn't have the right permissions to access the item (this is using the Owner's account!). Attempting to reinstall failed, with errors stating that the file / directory all ready existed and couldn't be overwritten or renamed. Attempting to un-install the application was only partially successful with the executable code.exe still remaining afterwards. The only way I managed fix it this time was to reinstall to a directory with a different name. Surprisingly though, all the existing workspaces, projects and extensions even were intact and the application opened where I had left off as though nothing had happened. This is a little worrying I have to say! But that's how I fixed it this time.
I make sure all of processes of VS Code have exited, but I can’t delete the bin directory.
I tried many tools to find which process is using the directory, but none of them reported.
The problem occurs on all of my Windows devices and I need to manually update each time.
This link suggests a workaround might be to stop Skype for Business:
https://github.com/Microsoft/vscode/issues/60697
Notes:
Different users had to close Skype for Business, SkypeBridge, or even f.lux (?)
Per the link, you can use Windows Process Explorer to determine which apps are holding "bin" open
In my case it was Teams, and found that by searching for Skype in Windows Process Explorer. Killed it and the update went smoothly.
When trying to debug a Metro project from VS, I came across this error:
DEP0700 : Registration of the app failed. Another user has already installed a packaged version of this app. An unpackaged version cannot replace this. The conflicting package is PACKAGENAME and it was published by CN=some Guid. (0x80073cf9)
But I have already uninstalled the app from the Start page, also, I can confirm that there is no entry left in Add/Remove program.
And since the access to the "%PROGRAMFILES%\WindowsApps" folder where the app files reside in is blocked, so I have no way to see if the app is still there.
However, I can still find many 'PACKAGENAME' occurances in the registry.
How to diagnose this? How to get rid of the "packaged version" so I can start debugging from VS?
Try installing the app from the windows store again, and then uninstall it from the start page. It appears that when Visual Studio does the uninstall it doesn't do it right.
1) Go to your Package.appxmanifest file in your solution
2) Go to the identity tag.
<Identity Name="xxxxxxx-yyyy-zzzz-tttt-bbbbbbbbbbbbb"
Publisher="CN=bigbob"
Version="1.0.0.0" />
3) Change the value of the Identity Name (Ex from ...bbbbb to ...bbbbc)
4) Rebuild and run
Source:
http://www.sempf.net/post/MetroUIAnother-user-has-already-installed-an-unpackaged-version-of-this-application.aspx
Are you sure you didn't just unpin the app? Try doing a search for it and see if it is still there.
I find a solution to the problem. It's said it is a "staged package" that does not show up in my start page so I can not uninstall it in normal way. I follow the steps, and successfully get rid of that "un-uninstallable" :) package.
This blog post was helpful, although after an hour or so of troubleshooting it turns out that I had indeed installed the package under another user account. After switching accounts and uninstalling from the start screen it worked fine.
When I create a new window based application, I get:
Failed to launch simulated
application: iOS Simulator failed to
install the application.
I tried to do what this post suggest, but didn't work
Any suggestions? I haven't tried re-installing xcode yet.
Choose Reset Content and Settings in the File menu of the Simulator.
Build Clean in Xcode
Then try again.
I'm not sure why, but rebooting my machine seemed to fix it.
I had the same problem. A reboot also did the trick, but then I realized that the directory
~/Library/Application Support/iPhone Simulator/6.1/
looked "different" after the reboot (Directory "Root" was missing). So I tried to reproduce the error by deleting the directory or parts of it. The simulator each time recreated the directory and worked fine. Maybe the reboot is not really needed just recreating the mentioned directory would also help.
Try to delete project.xcworkspace file and xcuserdata dirctory in your project
It seems that the processes don't get cleaned up properly each time you stop the app with ps aux in Terminal showing a large number of processes representing your app on the simulator.
I expect some kind of upper limit is reached with the number of processes / memory. (Indeed I have found that XCode will fail to build because some posix resource can't be found because there isn't memory to load it)
A machine restart clears all of these dead processes and allows room for new ones. For me, I only have to do this after about 2-3 weeks of not turning my computer off, but I suppose what resources you have and how often you use the Simulator will affect it.
If someone knows how to clear all these dead processes without restarting, that would be useful please, killall ... doesn't seem to have worked for me, but feel free to add to this answer.
Simply go the info.plist file property and set 'Copy to Output Directory' to 'Copy Always' it will resolve your problem.