I am currently trying to create a root account from Single User Mode on OSX Yosemite
/sbin/mount -uw /
launchctl load /System/Library/LaunchDaemons/com.apple.opendirectoryd.plist
passwd
The first 2 lines appear to work fine, but after I type 'passwd' nothing comes up. Not even a propmpt to keep typing commands. I don't believe it is setting the password because anything I type is visible and even if I type the same text twice nothing happens.
When I try to run this command after the computer boots and I have logged into my account 'passwd' works as expected, it prompts me for the old password and for the new password twice.
I had exactly the same issue, earlier today. However, there is another way:
Reboot your Mac then press & hold Command + R when it's booting up until you see a loading bar. You'll then be taken into recovery mode.
Recovery mode has a UI, so use your mouse and select Terminal from the Utilities section of the menu bar.
Type resetpassword in the terminal and hit Enter. This will load the password reset utility, where you can pick a user and give them a new password.
Related
im running a Snow Leopard 10.6.8 and today i tried running Terminal when i got an error which said.
"You are authorised to run this applicationThe Administrator has set your shell to and illegal value."I checked older posts and so far i have tried changing Terminals File Permissions,Changed /private/etc/shells to default and repaired permissions with disk utility. Does anyone know how to fix this.
It sounds like your user shell got set to an illegal value. To fix this:
Open System Preferences, and go to the Users and groups pane
Click the padlock and authenticate as an administrator
Right-click (or Control-click) on your user account in the sidebar, then choose Advanced Options from the shortcut menu that appears.
In the Advanced dialog, change your Login shell to "/bin/bash". DO NOT CHANGE ANYTHING ELSE.
Click OK to save the change, log out & back in, and try using Terminal again.
The default shell for your user will be set in /private/etc/passwd at the end of the line starting with your username. It should be set to /bin/bash
Wanting to give byobu a looksee as a screen 'update' of sorts. I start it with
byobu
and instead of the status line sitting at the bottom of the screen, everytime it updates it pushes to an additional line underneath the previous one. before long, the screen (putty) is filled with status line echoes.
How do I stop this?
running puttytray v0.62 on win7 to ubuntu 12.04
Putty defaults to a translation encoding of ISO-8859-1 where as Ubuntu sends out UTF-8 encoding.
Click on your server in the Load, save or delete a stored session window. Then click on the Load button.
Next, in the Category panel on the left click on:
Window -> Translation
Change the drop down under "Received data assumed to be in which character set" to UTF-8.
Once you do that then click on Session in the top of the Category panel and then click on save in the stored sessions area.
I am not saying this is the correct fix. I am just telling you all what fixed it for me without having to do any crazy stuff to the server.
Cheers!
This seems to be an issue with the default byobu backend. By default, byobu in Ubuntu 12.04 uses tmux as the backend. You can change this by running byobu-select-backend and selecting screen (option 2).
While not a solution as to why tmux is doing this on PuTTY sessions, it fixes your issue for the screen scrolling.
The UTF-8 setting works wonders. I usually set this together with Terminal => Keyboard => "Function keys and kepad" from "ESC[n~" to "Xterm R6" and save it as default configuration in Putty. That last option enables the use of the F key functions in Byobu. It's pretty much useless without.
I had a similar issue on a debian Testing/SID server, and it was an issue with several detached screen sessions loose on the system. ps aufx |grep -i screen should find orphaned screen sessions.
I tried sudo byobu-select-backend and tmux is the default on Debian Testing as well, I chose 'screen' but when I tried $ byobu the same scrolling behaviour ensued.
So I ran $ byobu-select-backend as my regular user and selected 'screen' again.
This time, running byobu showed me the detached screen sessions, so I could select them and shut them down gently.
#phanku's answer, namely that the terminal's encoding should be set to UTF-8, allowed me to fix the same problem that the OP described when accessing a byobu session (on Ubuntu 12.04) from a Mac OS X iterm with the help of Michael Hendrick's post that describes setting iTerm to UTF-8:
menu: View -> Show Session Info
Session tab: change Encoding from "Western (ASCII)" to "Unicode (UTF-8)".
for me the problem was related to how compatibility was set:
in the terminal, go to:
right-click, choose 'profiles' > 'profile preference'
choose the 'compatibility' tab
change 'ambiguous-width characters' to 'Narrow'
or
just click on the 'reset' button
it worked for me ...
I use iTerm2 in macOS and run into the same problem. The encoding is already set to UTF-8 but no help. Here's the solution that works for me:
Open Preferences > Profiles
Choose the profile with the problem
Go to Text tab on the right
Uncheck the Treat ambiguous-width characters as double width option
Done.
Is it possible to write a script to see which processes/programs are sending/receiving data over the internet in Windows XP? I have full administrator rights and I want to find a way to monitor data exchange on my machine without installing any additional software.
Step One: Windows XP
Open up the Run box by pressing the Windows key and R at the same time.
Put in CMD and press OK. The command prompt window will open up:
Step Two
In your open Command Prompt window, enter the following:
netstat -b 5 > activity.txt
and hit enter. (Note: to paste something into Command Prompt, you'll need to right click and click paste.)
If you forgot to run the prompt as an administrator (like I did in the screenshots above), just redo step one You can tell when it's running as administrator because instead of saying C:\Users\Username it says C:\Windows\system32.
If you've pasted the code right, a blinking cursor will... blink.
After a few minutes, press Ctrl+C. That'll stop the command.
Now type in command prompt activity.txt to open the log:
When you press Enter, your default text editor-probably Notepad-will open:
Now, scroll through the lists. You'll see that it's mostly your browser-but some times, there are programs like Google Talk's webcam program installed that call home even when you aren't using them.
Now that you've found any and all culprits that are programs accessing the internet (with and without your knowledge), you can either close them from the Task Manager or even uninstall them.
I want to use the mac in single user mode. I want to use ctags and cscope in that mode. Could anyone help me with the setups required for this. Thank you. All i know is how to go to the single user mode so please tell me in a simple and easy to understand method. My mac is version 10.6(snow leopard)
There is actually a full screen mode you can use (as others have said, you really don't want to run in single user mode).
Reboot your Mac and at the login screen, instead of your username type >console and leave the password empty. This will then take you to a full screen text mode.
[Note that for this to work you need to be able to type in the username rather than pick it from a list - to enable this go to System Preferences => Accounts => Login Options and select Name and password.]
I use a standard user account for my daily tasks on Mac OS. Since upgrading to Snow Leopard I am asked to do the following when a program is run from within Xcode:
"Type the name and password of a user in the 'Developer Tools' group to allow Developer Tools Access to make changes"
While I know the admin username/password, this is annoying (though only required once per login).
The developer tools access is asking for rights to "system.privilege.taskport.debug" from application gdb-i386-apple-darwin.
What is the best way around this?
You need to add your macOS user name to the _developer group. See the posts in this thread for more information. The following command should do the trick:
sudo dscl . append /Groups/_developer GroupMembership <username>
Finally, I was able to get rid of it using DevToolsSecurity -enable on Terminal.
Thanks to #joar_at_work!
FYI: I'm on Xcode 4.3, and pressed the disable button when it launched for the first time, don't ask why, just assume my dog made me do it :)
$ dseditgroup -o edit -u <adminusername> -t user -a <developerusername> _developer
You should add yourself to the Developer Tools group. The general syntax for adding a user to a group in OS X is as follows:
sudo dscl . append /Groups/<group> GroupMembership <username>
I believe the name for the DevTools group is _developer.
Ned Deily's solution works perfectly fine, provided your user is allowed to sudo.
If he's not, you can su to an admin account, then use his dscl . append /Groups/_developer GroupMembership $user, where $user is the username.
However, I mistakenly thought it did not because I wrongly typed in the user's name in the command and it silently fails.
Therefore, after entering this command, you should proof-check it.
This will check if $user is in $group, where the variables represent respectively the user name and the group name.
dsmemberutil checkmembership -U $user -G $group
This command will either print the message user is not a member of the group or user is a member of the group.
Answer suggested by #Stacy Simpson:
We are struggling with the issue described in these threads and none of the resolutions seem to work:
Stop "developer tools access needs to take control of another process for debugging to continue" alert
Authorize a non-admin developer in Xcode / Mac OS
As I'm new to SO, I cannot post in either thread. (The first one is actually closed and I disagree with the localization reasoning...)
Anyway, we created a work-around using AppleScript that folks may be interested in. The script below should be executed asynchronously prior to launching your automated test:
osascript <script name> <password> &
Here is the script:
on run argv
# Delay for 10 seconds as this script runs asynchronously to the automation process and is kicked off first.
delay 10
# Inspect all running processes
tell application "System Events"
set ProcessList to name of every process
# Determine if authentication is being requested
if "SecurityAgent" is in ProcessList then
# Bring this dialogue to the front
tell application "SecurityAgent" to activate
# Enter provided password
keystroke item 1 of argv
keystroke return
end if
end tell
end run
Probably not very secure, but it's the best work-around we've come up with to allow tests to run without requiring user intervention.
Hopefully, I can get enough points to post the answer; or, someone can unprotect this question. Regards.
For me, I found the suggestion in the following thread helped:
Stop "developer tools access needs to take control of another process for debugging to continue" alert
It suggested running the following command in the Terminal application:
sudo /usr/sbin/DevToolsSecurity --enable
Here is a better solution from
Mac OS X wants to use system keychain when compiling the project
Open Keychain Access.
In the top-left corner, unlock the keychain (if it is locked).
Choose the System keychain from the top-left corner.
Find your distribution certificate and click the disclosure triangle.
Double-click ‘Private key’ under your distribution certificate.
In the popup, go to the Access Control tab.
Select ‘Allow all applications to access this item’.
Save the changes.
Close all windows.
Run the application.
I am on Snow Leopard and this one didn't quite work for me. But the following procedure worked:
First added another account with admin privileges by ticking "Allow user to administer this computer" under Accounts, for example an account with username test
Logged into the test account
Launched Xcode, compiled and ran my iPhone project. All ok, no errors were thrown related to permissions
Logged out of the test account
Logged in with the another account having admin privileges
Took away the admin priviliges from the test account by removing the tick from "Allow user to administer this computer" under Accounts
Logged back into the test account
Deleted the iPhone project directory and again checked out from the repository (in my case svn)
Launched Xcode, compiled and ran the project. I didn't get any errors and the App ran well in the iPhone Simulator.
After you run:
sudo dscl . append /Groups/_developer GroupMembership <username>
per the answer above, you may still get prompted to enter in your own password:
We need authorization from an admin user to run the debugger.
This will only happen once per login session.
What it really means is any _developer groupmember user so just your non-admin user/password will work here but to get rid of it completely (no prompts after a reboot) you'll also need to run:
sudo DevToolsSecurity -enable
(running it with sudo as an admin user/as root will make it so you can do it remotely without a gui password prompt)