How do I use Terminal to do what Mac OSX Disk Utility does to permissions, since DU fails.
EHLO.
Trying to migrate user from older Macbook to newer Macbook Pro. We have a history of being hacked and the Macbook's Disk Utility showed many permission repairs needed for mostly iTiunes and iPhoto related files and folders. DU cannot repair them. Says repaired, then verify shows still there. Even though I don't really go along with ignoring errors, I checked anyway, and these errors are not listed in the "errors you can ignore" from Apple. I think maybe all are of the type shown here in these two examples where DU says it should be a directory and it is showing as a file or whatever a "-" means.
Permissions differ on “Applications/iTunes.app/C
Permissions differ on “Applications/iTunes.app/C
I'm trying to learn Terminal and changed hidden files to visible and the iTunes.app folder listed in the error still does not show in Finder. Alright so big deal I'll keep using Terminal. I figure it must be xattr or something I don't understand yet. I can navigate to iTunes.app folder in Terminal and it shows files. I can see the xattr's for the folders and files like "@" or "+" but don't know what to do yet. Thought I'd find easy way to change "d" to "-" and it's a little busier than I'd hoped. Trying to learn by doing it this way, rather than wipe and reinstall OSX.
Background:
This came up because we were planning to upgrade the older Macbook to Yosemite and had errors during update from App Store app. After searching, it said one update had about 8 or so updates bundled into the update. The simple update button failed with error 102.
Looked it up and it said permissions problem. Then ran DU and ended up finding the permissions problems with many iTunes files and folders that cannot repair. Meanwhile, back at the ranch, went to the bottom of the main screen in App Store app and clicked the little blue "More" link and the 8 or so bundled updates expand downward into individual updates for each one. A few hours later with three required restarts, I updated all except for the one shown above.
In case this mess is from a hack, like an ongoing monitoring kind, I want to mention one other error found by DU. DU said the file: "<path>/ARDAgent" has been modified and will not be repaired." Because of past hacks, and because it is ARD, I renamed the file and DU no longer shows an error for it. Simply cannot use ARD for now I'd guess. Some threads I read said ignore ARDAgent error described, and they were contradicted by people saying that error was a serious proven security opening.
So now trying to change "d" to "-" . Also noted I cannot put iTunes in the trash because I get an error saying it is required by the OS, but I found an Apple site that would allow me to download and install iTunes. What gives? So I haven't tried installing iTunes over the current ITunes yet. I found I could drag iPhoto to the trash without an error.
An Apple a day, keeps the Disk Doctor away.
But think of the cost of getting a new machine everyday. Besides, Apples are usually pretty darn good. Anyone here ever try Disk Doctor from FIPLAB? I thought Disk Doctor name was the original Apple utility. Name change?
Thanks for listening.
Trying to migrate user from older Macbook to newer Macbook Pro. We have a history of being hacked and the Macbook's Disk Utility showed many permission repairs needed for mostly iTiunes and iPhoto related files and folders. DU cannot repair them. Says repaired, then verify shows still there. Even though I don't really go along with ignoring errors, I checked anyway, and these errors are not listed in the "errors you can ignore" from Apple. I think maybe all are of the type shown here in these two examples where DU says it should be a directory and it is showing as a file or whatever a "-" means.
Permissions differ on “Applications/iTunes.app/C
Permissions differ on “Applications/iTunes.app/C
I'm trying to learn Terminal and changed hidden files to visible and the iTunes.app folder listed in the error still does not show in Finder. Alright so big deal I'll keep using Terminal. I figure it must be xattr or something I don't understand yet. I can navigate to iTunes.app folder in Terminal and it shows files. I can see the xattr's for the folders and files like "@" or "+" but don't know what to do yet. Thought I'd find easy way to change "d" to "-" and it's a little busier than I'd hoped. Trying to learn by doing it this way, rather than wipe and reinstall OSX.
Background:
This came up because we were planning to upgrade the older Macbook to Yosemite and had errors during update from App Store app. After searching, it said one update had about 8 or so updates bundled into the update. The simple update button failed with error 102.
Looked it up and it said permissions problem. Then ran DU and ended up finding the permissions problems with many iTunes files and folders that cannot repair. Meanwhile, back at the ranch, went to the bottom of the main screen in App Store app and clicked the little blue "More" link and the 8 or so bundled updates expand downward into individual updates for each one. A few hours later with three required restarts, I updated all except for the one shown above.In case this mess is from a hack, like an ongoing monitoring kind, I want to mention one other error found by DU. DU said the file: "<path>/ARDAgent" has been modified and will not be repaired." Because of past hacks, and because it is ARD, I renamed the file and DU no longer shows an error for it. Simply cannot use ARD for now I'd guess. Some threads I read said ignore ARDAgent error described, and they were contradicted by people saying that error was a serious proven security opening.
So now trying to change "d" to "-" . Also noted I cannot put iTunes in the trash because I get an error saying it is required by the OS, but I found an Apple site that would allow me to download and install iTunes. What gives? So I haven't tried installing iTunes over the current ITunes yet. I found I could drag iPhoto to the trash without an error.
An Apple a day, keeps the Disk Doctor away.
But think of the cost of getting a new machine everyday. Besides, Apples are usually pretty darn good. Anyone here ever try Disk Doctor from FIPLAB? I thought Disk Doctor name was the original Apple utility. Name change?
Thanks for listening.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
No. Didn't know it was there until two days ago when I quit working on it. Then I wanted to learn more of what's really going on so Terminal sounded pretty good. At this point all the data is backed up and ready to go for when the user gets time to sort out what they want on the new MBP.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Yes, thank you. I see that. An error I made is I said I checked, but I only checked for the "d" versus "-" errors, not for the ARDAgent. The reason was my thinking.
Because,
-I found a post that contradicted the ignore posts about ARDAgent,
-and the post said it was a, I think they used the word "proven," security risk,
-and I noted DU showed no errors at all when I installed the current OSX last spring,
-and the hacking history here,
I thought I would try really hard to not ignore this error. So renamed for now. At the beginning of the day, if I must ignore it I will. At some point if I get through this Terminal method for "d" and "-", I want to also use other method of create OSX install disk, wipe and start fresh and see if ARDAgent error goes away. I believe the user has no knowledge of permissions and is not able to alter any permissions. At the bottom of your link, Apple says this can happen if you change your permissions. So I suppose an install or something could have done it. but I'm trying to prove out as many things as I can.
On the "d" versus "-" found with " ls -l ", there were too many to look at on the MB. So I scanned through the Apple ignore post quickly and If I didn't make an error, there were no posts from Apple about a "-" that was supposed to be a "d" so I figured that was enough. Plus I want to see if Terminal will do it. If I get good enough, I may eventually try to look into what it takes to modify the BOM file to make the ARDAgent error go away too. That's way down the road.
Because,
-I found a post that contradicted the ignore posts about ARDAgent,
-and the post said it was a, I think they used the word "proven," security risk,
-and I noted DU showed no errors at all when I installed the current OSX last spring,
-and the hacking history here,
I thought I would try really hard to not ignore this error. So renamed for now. At the beginning of the day, if I must ignore it I will. At some point if I get through this Terminal method for "d" and "-", I want to also use other method of create OSX install disk, wipe and start fresh and see if ARDAgent error goes away. I believe the user has no knowledge of permissions and is not able to alter any permissions. At the bottom of your link, Apple says this can happen if you change your permissions. So I suppose an install or something could have done it. but I'm trying to prove out as many things as I can.
On the "d" versus "-" found with " ls -l ", there were too many to look at on the MB. So I scanned through the Apple ignore post quickly and If I didn't make an error, there were no posts from Apple about a "-" that was supposed to be a "d" so I figured that was enough. Plus I want to see if Terminal will do it. If I get good enough, I may eventually try to look into what it takes to modify the BOM file to make the ARDAgent error go away too. That's way down the road.
While looking for the post about "proven" security risk, I came across this thread from apple discussions that reflects how I feel about DU errors if you jump down to Joseph Kriz post regarding no errors.
https://discussions.apple.com/thread/3880430?start=0&tstart=0
I'll keep looking for the post about "proven" security risk.
https://discussions.apple.com/thread/3880430?start=0&tstart=0
I'll keep looking for the post about "proven" security risk.
Here is a similar link that I think is older, but describes an ARDAgent security issue.
http://www.macworld.com/article/1134165/ardagent.html
and here is another discussion at Apple discussing old (2008) specifics of what the problem is, and what can be done.
https://discussions.apple.com/message/7421503#7421503
Maybe when I have time in a few days I can try some of that, but I'm more interested in the "d" and "-" for now.
http://www.macworld.com/article/1134165/ardagent.html
and here is another discussion at Apple discussing old (2008) specifics of what the problem is, and what can be done.
https://discussions.apple.com/message/7421503#7421503
Maybe when I have time in a few days I can try some of that, but I'm more interested in the "d" and "-" for now.
Those discussions are all 7 years old or so. Any vulnerabilities would long since have been patched by Apple. Apple says the permissions error is normal and should be ignored.
The d means directory and the - means a normal file. No amount of Disk Utility repairs should be able to convert that. The only way to "fix" or convert that is to delete the file or directory and create it as the correct corresponding file or directory. If you're not that familiar with OS X, please don't mess with it that way on the command line. The disk utility checks may not have caught up with the changes made by Apple with the recent patches.
To do what you want with disk utility on the command line, you run the command line diskutil.
You'll have to find your disk device name first. A simple way is to run df to show your device in the form of /dev/disk# when you look up the free disk space on your system. You should see your file system on the left side. Look for the / (root directory) in the Mounted On section. The filesystem for your root disk will be on that line.
If your disk device was /dev/disk1, you would run the following
diskutil -verifyPermissions /dev/disk1
diskutil -repairPermissions /dev/disk1
diskutil -verifyDisk /dev/disk1
diskutil -repairDisk /dev/disk1
If you want your permissions and files fixed, reinstall that Macbook. Go to recovery mode, install the OS without deleting the partition. That should fix all OS permissions issues by placing new files and directories in the path. This should not delete any Applications or User files, but you should backup your data before you start this process.
To do what you want with disk utility on the command line, you run the command line diskutil.
You'll have to find your disk device name first. A simple way is to run df to show your device in the form of /dev/disk# when you look up the free disk space on your system. You should see your file system on the left side. Look for the / (root directory) in the Mounted On section. The filesystem for your root disk will be on that line.
If your disk device was /dev/disk1, you would run the following
diskutil -verifyPermissions /dev/disk1
diskutil -repairPermissions /dev/disk1
diskutil -verifyDisk /dev/disk1
diskutil -repairDisk /dev/disk1
If you want your permissions and files fixed, reinstall that Macbook. Go to recovery mode, install the OS without deleting the partition. That should fix all OS permissions issues by placing new files and directories in the path. This should not delete any Applications or User files, but you should backup your data before you start this process.
Hi Experts.
My apologies for being away so long. Been doing too much.
Thank you for your replies. I appreciate very much your thoughts about protecting my data and HDD, however, it is all backed up now and as I was trying to say in my first post, I'm hoping to learn enough about Terminal and OSX to get it mastered at some point. It'll take me a long time, but I might as well start and keep at it.
Now have the older MacBook updated with fresh install of OSX 10.10.5 with no errors reported by DU.
Also have even older MacBook that is now updated as far as it will go to 10.6.8 with no errors reported by DU.
Will practice on these older Macs with disk editor and then repair the new MacBook Pro which is in full use with DU errors remaining.
I'll keep you posted, but it will probably take two to three days.
My thinking originally was that maybe there was a way to do this with Terminal and make use of wildcards for files as is done with permissions, but I have not seen references to this. Currently looking at using an old favorite of mine, R-Studio. Others are also in mind.
My apologies for being away so long. Been doing too much.
Thank you for your replies. I appreciate very much your thoughts about protecting my data and HDD, however, it is all backed up now and as I was trying to say in my first post, I'm hoping to learn enough about Terminal and OSX to get it mastered at some point. It'll take me a long time, but I might as well start and keep at it.
Now have the older MacBook updated with fresh install of OSX 10.10.5 with no errors reported by DU.
Also have even older MacBook that is now updated as far as it will go to 10.6.8 with no errors reported by DU.
Will practice on these older Macs with disk editor and then repair the new MacBook Pro which is in full use with DU errors remaining.
I'll keep you posted, but it will probably take two to three days.
My thinking originally was that maybe there was a way to do this with Terminal and make use of wildcards for files as is done with permissions, but I have not seen references to this. Currently looking at using an old favorite of mine, R-Studio. Others are also in mind.
Hi people.
Still no verified solution that will allow me to manually edit file type to directory, or standard file, or pipe, etc. Been to lots of places. Sent some emails. No response yet.
I think this may be possible with xxd via Terminal. Similar to using R-Studio. Still trying to figure out the xxd man page and examples. May still need the Unix logical file format specification which should define the layout of a file header, to locate these settings. Haven't found that spec yet. I've been playing with the xxd command and maybe these bits I'm trying to change will show up in ASCII but I have my skepticism. I pretty sure it isn't cynicism.
Still no verified solution that will allow me to manually edit file type to directory, or standard file, or pipe, etc. Been to lots of places. Sent some emails. No response yet.
I think this may be possible with xxd via Terminal. Similar to using R-Studio. Still trying to figure out the xxd man page and examples. May still need the Unix logical file format specification which should define the layout of a file header, to locate these settings. Haven't found that spec yet. I've been playing with the xxd command and maybe these bits I'm trying to change will show up in ASCII but I have my skepticism. I pretty sure it isn't cynicism.
As a normal user, you're not supposed to be able to edit the filesystem to convert a file to a directory and vice versa. You should delete the file then create a directory with the same name or delete the directory and create a file with the same name. It's not really meant to be edited that way. Write a script to change it.
Hi Serialband. I hear what you're saying but it just isn't me, as I've outlined in my previous posts like the one about Joseph Kriz. I don't always want to be a normal user. I guess it's like a person who wants to turbo charge their car. Most people might say you shouldn't alter the factory stock parts. But then the person doesn't have what they want and the person isn't exercising their freedom to legally modify their car they way they like. The very reason we have hex editors is to have the freedom to change whatever bit we want on our hard disk even if it wrecks everything. Sometimes it is the only way to fix things and it's beautiful.
The directory that was in question remained a functioning directory as nearly as I could tell. So I was never wanting to convert a file to a directory or such. What a mess that would be. But the directory was reporting itself as a standard file. I could navigate to it in Terminal and list the files, but it erroneously reported itself as a file. So changing the data to say it is a directory simply corrects a corruption, or leads me further into my education. :-)
I'm hoping to move toward technical answers about where this data is stored in the file header layout, and how to change it. Who are we to decide what a normal user does anyway.
All the best.
The directory that was in question remained a functioning directory as nearly as I could tell. So I was never wanting to convert a file to a directory or such. What a mess that would be. But the directory was reporting itself as a standard file. I could navigate to it in Terminal and list the files, but it erroneously reported itself as a file. So changing the data to say it is a directory simply corrects a corruption, or leads me further into my education. :-)
I'm hoping to move toward technical answers about where this data is stored in the file header layout, and how to change it. Who are we to decide what a normal user does anyway.
All the best.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
The reason for accepting my own solution was it had direct reference point to begin researching the flag I'm trying to change.
ASKER
Also forgot to mention the DU failure on "ARDAgent has been modified and will not be repaired" also occurs on the two week old MBP with OSX 10.10.5.