Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Here's what it gave me:

macintosh:~ niafgana$ mkdir ~/foobar
mkdir: /Users/niafgana/foobar: Operation not permitted
macintosh:~ niafgana$ sudo mkdir ~/.Xcode
mkdir: /Users/niafgana/.Xcode: Operation not permitted

try it this way:

Code:
cd ~
mkdir .Xcode

the terminal should like that a little better
 
try it this way:

Code:
cd ~
mkdir .Xcode

the terminal should like that a little better


Nope, it still gives the same output

macintosh:~ niafgana$ cd ~
macintosh:~ niafgana$ mkdir .Xcode
mkdir: .Xcode: Operation not permitted
macintosh:~ niafgana$ cd ~
macintosh:~ niafgana$ mkdir .Xcode
mkdir: .Xcode: Operation not permitted
 
Try this:
Code:
cd ~; pwd;  id -p; /sbin/mount; /usr/bin/which mkdir

Then try this:
Code:
touch ~/testFile; ls -lde ~/*
 
Try this:
Code:
cd ~; pwd;  id -p; /sbin/mount; /usr/bin/which mkdir

I'd add a

Code:
ls -lde `/usr/bin/which mkdir`
echo $PATH
to that.

However, it looks like no matter what I get "Permission denied" instead of "Operation not permitted" even if I chmod 400 /bin/mkdir.

B
 
Try this:
Code:
cd ~; pwd;  id -p; /sbin/mount; /usr/bin/which mkdir

Then try this:
Code:
touch ~/testFile; ls -lde ~/*

macintosh:~ niafgana$ cd ~; pwd; id -p; /sbin/mount; /usr/bin/which mkdir
/Users/niafgana

uid niafgana
groups staff _developer _lpoperator _lpadmin _appserveradm admin _appserverusr localaccounts everyone com.apple.sharepoint.group.1 com.apple.access_screensharing
/dev/disk0s2 on / (hfs, local, journaled)
devfs on /dev (devfs, local, nobrowse)
map -hosts on /net (autofs, nosuid, automounted, nobrowse)
map auto_home on /home (autofs, automounted, nobrowse)
/bin/mkdir
macintosh:~ niafgana$ touch ~/testFile; ls -lde ~/*
touch: /Users/niafgana/testFile: Operation not permitted
drwx------+ 5 niafgana staff 170 Sep 1 05:29 /Users/niafgana/Desktop
0: group:everyone deny delete
drwx------+ 11 niafgana staff 374 Aug 28 00:07 /Users/niafgana/Documents
0: group:everyone deny delete
drwx------@ 6 niafgana staff 204 Aug 30 02:59 /Users/niafgana/Downloads
0: group:everyone deny delete
drwxr-xr-x 7 niafgana staff 238 May 10 19:36 /Users/niafgana/FrostWire
drwx------+ 50 niafgana staff 1700 Jul 25 23:11 /Users/niafgana/Library
0: group:everyone deny delete
drwx------+ 8 niafgana staff 272 Aug 19 21:53 /Users/niafgana/Movies
0: group:everyone deny delete
drwx------+ 7 niafgana staff 238 Mar 19 23:23 /Users/niafgana/Music
0: group:everyone deny delete
drwx------+ 8 niafgana staff 272 Aug 19 21:53 /Users/niafgana/Pictures
0: group:everyone deny delete
drwxr-xr-x+ 6 niafgana staff 204 Dec 2 2009 /Users/niafgana/Public
0: group:everyone deny delete
drwxr-xr-x+ 6 niafgana staff 204 Oct 16 2009 /Users/niafgana/Sites
0: group:everyone deny delete
drwxr-xr-x 10 niafgana staff 340 Aug 19 21:54 /Users/niafgana/iPhone Stuff
drwxr-xr-x 3 niafgana staff 102 Aug 19 21:54 /Users/niafgana/pwnage
 
/dev/disk0s2 on / (hfs, local, journaled)
devfs on /dev (devfs, local, nobrowse)
map -hosts on /net (autofs, nosuid, automounted, nobrowse)
map auto_home on /home (autofs, automounted, nobrowse)
/bin/mkdir

I don't see anything odd in the output from 'mount', and the location of mkdir is fine.

The fact that 'touch' fails with the same error means that something is preventing the creation of any file or folder in your home folder. I'm not sure what that could be, because both the permissions and the access-control list on the home folder allow writing by the owner.

You could try creating a new folder in your home folder using Finder, and see if that works or fails. I suspect it will fail, but it's worth trying.

The only odd thing I see at all is the 'pwnage' folder in your home folder. However, there could be any number of valid reasons for that, so I don't think it matters here.

When was the last time you rebooted this computer? Or has that already been tried.

To summarize, the problem doesn't seem to be Xcode itself. The problem seems to be an unwritable home folder. Solve that and I suspect Xcode will work fine.


Hmm, just thought of one other thing to try:
Code:
ls -lod ~
Post the output.

Then use Finder to Get Info on your home folder and make sure the Locked checkbox is unchecked.
 
I don't see anything odd in the output from 'mount', and the location of mkdir is fine.

The fact that 'touch' fails with the same error means that something is preventing the creation of any file or folder in your home folder. I'm not sure what that could be, because both the permissions and the access-control list on the home folder allow writing by the owner.

You could try creating a new folder in your home folder using Finder, and see if that works or fails. I suspect it will fail, but it's worth trying.

The only odd thing I see at all is the 'pwnage' folder in your home folder. However, there could be any number of valid reasons for that, so I don't think it matters here.

When was the last time you rebooted this computer? Or has that already been tried.

To summarize, the problem doesn't seem to be Xcode itself. The problem seems to be an unwritable home folder. Solve that and I suspect Xcode will work fine.


Hmm, just thought of one other thing to try:
Code:
ls -lod ~
Post the output.

Then use Finder to Get Info on your home folder and make sure the Locked checkbox is unchecked.

I don't know what to say to you chown33 or any of the other users on here. I really feel like an idiot. The problem was that lock function on my home folder was on and thats whats been causing all the problems, I really feel like an idiot for not looking there, it seems like I'm a caveman who got hold of an Apple computer. Thanks chown33 for pointing that out for me and I can't thank you or any of the other users enough for helping me out. Thanks a Million, guys.
 
Don't worry about it. I feel like a bit of an idiot for not thinking of it sooner.

It's the most accessible write-prevention switch in Mac OS X. Far more so than permissions, or access-control lists, or read-only mounting of file-systems. Yet here we all were, having you run commands that look at the least accessible things.

It's definitely a Homer Simpson "D'oh!" moment.
 
How the heck does that work without showing up as an ACL or unix permissions problem.

The Locked bit is the "uchg" bit in a file's flags word. The system-call to write it is chflags(2). The stat(2) struct member is st_flags to read it.

If the Locked checkbox is checked but dimmed, then it's the "schg" bit.

http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPages/man2/stat.2.html

It's like a lot of things in Unix: it just grew that way, or "It seemed like a good idea at the time".
 
Thanks again and it definitely is a Homer Simpson moment....lol.
 
The Locked bit is the "uchg" bit in a file's flags word. The system-call to write it is chflags(2). The stat(2) struct member is st_flags to read it.

If the Locked checkbox is checked but dimmed, then it's the "schg" bit.

http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPages/man2/stat.2.html

It's like a lot of things in Unix: it just grew that way, or "It seemed like a good idea at the time".

Thanks. You learn something new every day.

The error message leaves a lot to be desired, but at least it doesn't include some long hex string like many Windows errors.

B
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.