OBIEE Permissions to particular SubjectAreas

Hi All,
We are using OBIEE10.1.3.4 version.Actually our requriment is we have lot of users are there in this some of users are belongs to particulat subject areas we need to give access to particular "Subject Areas" to the users .In My project we have around 12 sublect areas are there.
Could you anyone suggest me how to give Permissions to Subject Ares
Thanks,
Vijay.

Hi Vijay,
You can set the permissions on the subject area's in the presentation layer on the groups. In order to set permissions on a presentation folder, Double click on the folder name / Right click on the folder name and click on properties. Once you see the properties window open, you will see an option called permissions. Click on permissions and permissions window opens. You can set permissions on the groups based on your requirements there.
Hope this helps.
Thanks,
-Amith.

Similar Messages

How to check whether a file got read permissions for perticular user

Problem: Let JRE is running with some x as effective user in LINUX then while checking file permission it is checking permission on that file for that x user.
File f = new File(�file name�)
if(f.exists())
System.out.println(�exists�);
Else
System.out.println(�does not exists�);
The above code prints exists only when x user have permissions on that file
Requirement: I would like to check whether a file got read permissions for particular user i.e. whether y user got permissions on that file.
Any help is appreciated

In Linux a user has to have read permission on a file to even see that it exists. As a result, if a user (or a group to which they belong) doesn't have read access to the file File.exists() will return false. Windows which doesn't have as tightly controlled access to files will admit that a file exists whether it can be read or not.
PS.
This is proof that I should never answer a question off the top of my head when I haven't had my red bull yet. This is wrong. You will be able to see it if you have read and execute on the directory.
thumps self in head
Message was edited by:
puckstopper31

Problems with UAC and NTFS File Permissions on a File Server.

LarryG. wrote:
It looks to me like your account doesn't have the proper permissions on all of the sub folders. Can you verify that? Once you have the proper permissions this issue should go away.
This is a feature, not a bug. You do not have permissions.

Hello Everyone,I'm curious about your experience with UAC and NTFS permissions--in particular on a file server. In my case, I'm running Server 2012 R2.I have a very large company shared folder. I right click on it and go to properties to check the size. The size is only 5GB or so and should be over 300GB. How is this possible? I'm finding that some of its subfolders are tied into UAC and some folders are not. UAC-related subfolder:Non-UAC related subfolder:In the pictures above, both folders are department-related folders. They are not system folders. The folders have the same owner. The folders are located on the same folder level. When I try to view the permissions of the UAC-related folder, I get this:I'm a domain admin, so when I go through the prompts, I can see the permissions.But this is a total pain because I now require third...
This topic first appeared in the Spiceworks Community

Why does "repair permissions" actually creates more repairs when again.

When I use Disk Utility repair permissions, I run it a second time and there were more instances than noted in the initial run. 13 the first time and 22 the second. To double check, I rebooted my MBP to make sure it wasn't an issue with a running program. The same thing happened, I got 13 instances the first time and when I hit it again, I got 22. I find it hard to believe that by running "repair", more instances are created.
Also, why are some things just not repaired?
Thanks so much for any guidance.
Sincerely,
Skip

Specifically, what "repair permissions" does is look at a bunch of files called "BOM files" or "Bill of Materials files", which is simply a list of what files where installed where and with what permissions. They are created by the Mac software package make that vendors use to build installation packages (if you've ever installed software that required you to run an installation program rather than just copy it to /Applications, that's what you have).
When you run "repair permissions", it compares the file's permissions with what's in the BOM. If they aren't the same, it changes the file's permissions to whatever the BOM says they originally were. The idea being that something might have altered the permissions on a file file making it impossible for you to access and thereby messing up anything that requires access to the file. In practice, that doesn't happen too often.
What does happen pretty often is that the software installer copies files and then changes permissions on them. Even the application may change permissions on the files. That's pretty common, and often necessary to the operation of a piece of software. So, despite doing a "repair permissions", some files and directories are going to simply defy having their permissions modified (particularly things like directories where log files are stored).

Disk versus Volume permissions repair

I'm confused. What is the difference between, in my case, DISK, i.e. 232.9 GB WDC..., verify and/or repair disk permissions and VOLUME, i.e. Macintosh HD, verify and/or repair disk permissions? The two seem to be used interchangeably. Thanks for any info. Jerry

If you need to repair a volume, click on it, it appears as a subsidiary to the main hard drive. They cannot "both" be subdivided, only the hard drive can be divided into "partitions"(volumes). When you want to repair permissions for particular software, select the volume (partition) in which it is installed to repair. The permissions that are to be repaired are particular to the volume in which the application resides, there would be no need to repair permissions for another volume or the entire hard drive.
It's sort of like the nesting Russian dolls, the biggest is the hard drive, the nested ones are the volumes.

Accessing web application JAR files from applet

I've got an applet which is part of a web application.
All the web application JARs are in the webapps/myappl/WEB-INF/lib directory, and I
can't seem to place anything in that directory on the archive attribute of <OBJECT> tag.
I'm running into trouble because I'm sending objects from the servlet to the applet and keep getting classnot found during deserialization because I've missed some jar file on the archive attribute. I've had to copy lots of jar files up to where the codebase in the HTML file is to make this run. My question is this.
Is it better to just change the tomcat security policy file (catalina.policy in tomcat conf directory) so that the JARs are directly accessible and I don't have to copy them from WEB-INF/lib???? Has anyone done this before? What would the line look like?
I'm assuming that I have to follow the instructions (THAT I DON'T UNDERSTAND)
at the bottom of the policy file. Can someone help me out here????
should I have something like
grant codeBase "file:${catalina.home}/webapps/myappl/WEB-INF/classes/-"
{ permission java.security.AllPermission; };
grant codeBase "file:${catalina.home}/webapps/myappl/WEB-INF/lib/-"
{ permission java.security.AllPermission; };
Will this allow me to place references to jar files (and the classes directory) in the archive attribute, such as
<OBJECT ..... >
    <param name="archive" value="../WEB-INF/lib/applet.jar,../WEB-INF/lib/someapp.jar,../WEB-INF/classes" />trailer for catalina.policy is
// You can assign additional permissions to particular web applications by
// adding additional "grant" entries here, based on the code base for that
// application, /WEB-INF/classes/, or /WEB-INF/lib/ jar files.
// Different permissions can be granted to JSP pages, classes loaded from
// the /WEB-INF/classes/ directory, all jar files in the /WEB-INF/lib/
// directory, or even to individual jar files in the /WEB-INF/lib/ directory.
// For instance, assume that the standard "examples" application
// included a JDBC driver that needed to establish a network connection to the
// corresponding database and used the scrape taglib to get the weather from
// the NOAA web server. You might create a "grant" entries like this:
// The permissions granted to the context root directory apply to JSP pages.
// grant codeBase "file:${catalina.home}/webapps/examples/-" {
//   permission java.net.SocketPermission "dbhost.mycompany.com:5432", "connect";
//   permission java.net.SocketPermission "*.noaa.gov:80", "connect";
// The permissions granted to the context WEB-INF/classes directory
// grant codeBase "file:${catalina.home}/webapps/examples/WEB-INF/classes/-" {
// The permission granted to your JDBC driver
// grant codeBase "file:${catalina.home}/webapps/examples/WEB-INF/lib/driver.jar" {
//   permission java.net.SocketPermission "dbhost.mycompany.com:5432", "connect";
// The permission granted to the scrape taglib
// grant codeBase "file:${catalina.home}/webapps/examples/WEB-INF/lib/scrape.jar" {
//   permission java.net.SocketPermission "*.noaa.gov:80", "connect";
// };

Thank you for your reply.
As I mentioned in my first post I had seen a couple of posts mentioning ServletContext before, but dismissed them as I am not using any servlets of my own. However, since you showed me exactly how it was used I realised I could probably just use a dummy servlet to get this information.
The following page suggests a couple of techniques for doing just this.
http://www.jguru.com/forums/view.jsp?EID=1087411
So I think that's me sorted, cheers.

Cast to DATETIME Function?

Please someone correct me if I'm wrong, but it seems you can use the cast function to convert correctly formatted data to date, timestamp, etc, but it is not possible to cast to datetime?
OBIEE 11.1.1.6.2
Thanks,
Geo

My date is like '30/04/1990 15:30:00' I want to keep the time after the date... which is why I want to convert to datetime. If I convert to date then I lose the time - i.e. the output becomes 30/04/1990 00:00:00. So I thought the solution was to cast to datetime instead in OBIEE.
However, CAST("subjectarea"."table"."columnname" AS DATETIME) throws an error. Hence, I'm wondering if it is not possible to cast to datetime......
Can anyone advise?
Thanks,
George

Flash content no longer playable??

I've noticed all of a sudden that QuickTime no longer plays Flash content. It did until not so long ago.
I know there was an option to activate Flash support, according to the Quicktime Help files, this is supposed to be found in System Preferences\Quicktime\Advanced. I'm quite confident it was there (I had to go and activate the switch when playback became optional, was it in QT6 or QT7?).
It's gone.
It's as if Flash playback never existed...
The weird thing is that I'm still at 7.3.1 . I've seen enough problems with 7.4 that I decided to wait out at least 7.4.1 . I seem to recall that 7.3.1 was still quite young when 7.4 came out, is it possible that the Flash issue was introduced in 7.3.1 and I just didn't notice it before?

My apologies - I overlooked that IS your thread!
As for permissions:
What are permissions?
Every file and folder on a Mac OS X hard drive has a set of permissions—settings that determine which user(s) have access to each item, and exactly what that access is. For example, permissions dictate whether or not a particular user can open and edit a particular file. But permissions also determine which items the operating system—or specific parts of it—can access and modify, and which files are accessible by applications.
What does repairing permissions do?
The Repair Disk Permissions function—the process that actually performs the task of repairing permissions—examines certain files and folders on your Mac’s hard drive to see if their current permissions settings are what Mac OS X expects them to be; if discrepancies are found, the offending permissions are changed to match the expected settings.
(In Mac OS X 10.3 and later, repairing permissions also performs one other, unrelated, task: If the invisible /tmp symbolic link—which is linked to the /private/tmp directory—is missing, the link will be recreated.)
Why is it necessary to repair permissions?
If permissions on particular files are “incorrect”—i.e., not what Mac OS X expects them to be or not what they need to be for your Mac’s normal operation—you can experience problems when the operating system tries to access or modify those files. For example, you may have trouble logging in to your account, printing, launching applications, or even starting up your Mac. Similarly, if an application—from Apple or a third-party developer—needs access to a particular file or folder to function, and the permissions on that item have changed in a way that prevents such access, the application may not function properly (or at all). The Repair Disk Permissions function can fix such problems by ensuring that certain files have the correct permissions.
There’s also a security element here: Many system-level files have permissions set a particular way so that applications or users that shouldn’t be meddling with those files can’t. If the permissions on certain system-level files somehow get changed so that access to those files is no longer restricted, you’ve got the potential for a major security issue. Repairing permissions can resolve such issues by resetting permissions on those files to prevent unauthorized access.
How do I repair permissions?
The Repair Disk Permissions function is part of Apple’s Disk Utility (in /Applications/Utilities). After launching Disk Utility, select the desired disk—generally your startup disk—in the list to the left, then click the First Aid tab. At the bottom of the First Aid panel, click the Repair Disk Permissions button. (You could instead use the Verify Disk Permissions option to preview any potential repairs before performing them, but for most users there’s little benefit from this extra step.)
Permissions can also be repaired via the shell (Terminal) by using the command sudo diskutil repairPermissions /. However, it’s unlikely that the typical user will ever need to perform the task in this manner. It’s useful if for some reason Disk Utility itself won’t launch, or for repairing permissions on a remote Mac when connected via Remote Login (SSH), but otherwise you’re just as well served using Disk Utility.
How does the Repair Disk Permissions function know what the “correct” permissions are?
When you use Apple’s Installer utility to install software (such as Mac OS X itself or an OS X update), the installation package (the .pkg file you double-click to begin installation, or that Software Update downloads in the background for an automatic installation) generally leaves behind a receipt—a smaller Mac OS X package that includes information about every file installed, including the permissions each file should have. This receipt is placed in /Library/Receipts. When you run the Repair Disk Permissions function, it examines the receipts in the /Library/Receipts directory of the disk being repaired—which means the feature works only on volumes with Mac OS X installed—and compares the information in the receipt with the actual files on your drive. If the Repair Disk Permissions function finds a file with permissions that differ from what a receipt claims they should be, that file’s permissions are reset to their receipt-specified values. (If you’re curious about the information contained in a receipt, the easiest way to view it is to use the utility Pacifist; simply drag and drop the appropriate receipt into the Pacifist window and you’ll be presented with a list of all files installed by the similarly-named installation package, along with each file’s original permissions.)
It’s worth noting here that although the function is called “Repair Disk Permissions,” what is actually happening is that files’ permissions are being reset or restored to a particular state. It’s possible—though not common—for a particular file’s permissions to differ from what a receipt claims they should be without those permissions actually being “broken.”
Are all files affected by Repair Disk Permissions?
No. As you may have inferred from the above description, only those files installed using OS X’s Installer utility and whose installation packages leave behind a proper receipt in /Library/Receipts are affected by the Repair Disk Permissions function. This means that most of the files affected by the Repair Disk Permissions function are system-level files, application files, or system add-ons—not applications installed by drag-and-drop, and not your documents or other user-level files.
If repairing permissions is useful in general, why doesn’t Apple recommend it as routine maintenance?
Apple does, quite explicitly:
It’s a good idea to repair disk permissions as a regular maintenance task after upgrading or installing new software.
That’s taken from Mac Help—in both Panther and Tiger—right on your Mac. Similar statements can be found in other Support articles, one of which is:
http://docs.info.apple.com/article.html?artnum=25751

Software updates - in what order?

My brand new iMac was running 10.6.6 when I got it last week, I need to do a lot of software updates.
For years, on all our Macs, I've done software updates by checking with SU to see what needed to be updated and then doing the downloads from the Apple site and installing them manually. This was easier in Tiger where there was a menu item, download update. Now in SL I've had to find the updates myself at Apple since I don't see the option download update as a menu item and in help it indicates that the way to do this is to go to Apple and download.
I've done all the necessary downloads. Now I don't know what order to do the installs.
I assume it makes sense to do the combo update to 10.6.8 first. After that does it matter in what order I install the other updates. I think the order listed here is arbitrary - or not? Do you notice if anything relies on something else being updated first before the next item is installed??
Thanks,
Mrs H

And I get tired of posters stating that nonsense. What on earth has Permissions to do with viruses??
For those who prefer facts to opinions:
What are permissions?
Every file and folder on a Mac OS X hard drive has a set of permissions—settings that determine which user(s) have access to each item, and exactly what that access is. For example, permissions dictate whether or not a particular user can open and edit a particular file. But permissions also determine which items the operating system—or specific parts of it—can access and modify, and which files are accessible by applications.
What does repairing permissions do?
The Repair Disk Permissions function—the process that actually performs the task of repairing permissions—examines certain files and folders on your Mac’s hard drive to see if their current permissions settings are what Mac OS X expects them to be; if discrepancies are found, the offending permissions are changed to match the expected settings.
(In Mac OS X 10.3 and later, repairing permissions also performs one other, unrelated, task: If the invisible /tmp symbolic link—which is linked to the /private/tmp directory—is missing, the link will be recreated.)
Why is it necessary to repair permissions?
If permissions on particular files are “incorrect”—i.e., not what Mac OS X expects them to be or not what they need to be for your Mac’s normal operation—you can experience problems when the operating system tries to access or modify those files. For example, you may have trouble logging in to your account, printing, launching applications, or even starting up your Mac. Similarly, if an application—from Apple or a third-party developer—needs access to a particular file or folder to function, and the permissions on that item have changed in a way that prevents such access, the application may not function properly (or at all). The Repair Disk Permissions function can fix such problems by ensuring that certain files have the correct permissions.
There’s also a security element here: Many system-level files have permissions set a particular way so that applications or users that shouldn’t be meddling with those files can’t. If the permissions on certain system-level files somehow get changed so that access to those files is no longer restricted, you’ve got the potential for a major security issue. Repairing permissions can resolve such issues by resetting permissions on those files to prevent unauthorized access.
How do I repair permissions?
The Repair Disk Permissions function is part of Apple’s Disk Utility (in /Applications/Utilities). After launching Disk Utility, select the desired disk—generally your startup disk—in the list to the left, then click the First Aid tab. At the bottom of the First Aid panel, click the Repair Disk Permissions button. (You could instead use the Verify Disk Permissions option to preview any potential repairs before performing them, but for most users there’s little benefit from this extra step.)
Permissions can also be repaired via the shell (Terminal) by using the command sudo diskutil repairPermissions /. However, it’s unlikely that the typical user will ever need to perform the task in this manner. It’s useful if for some reason Disk Utility itself won’t launch, or for repairing permissions on a remote Mac when connected via Remote Login (SSH), but otherwise you’re just as well served using Disk Utility.
How does the Repair Disk Permissions function know what the “correct” permissions are?
When you use Apple’s Installer utility to install software (such as Mac OS X itself or an OS X update), the installation package (the .pkg file you double-click to begin installation, or that Software Update downloads in the background for an automatic installation) generally leaves behind a receipt—a smaller Mac OS X package that includes information about every file installed, including the permissions each file should have. This receipt is placed in /Library/Receipts. When you run the Repair Disk Permissions function, it examines the receipts in the /Library/Receipts directory of the disk being repaired—which means the feature works only on volumes with Mac OS X installed—and compares the information in the receipt with the actual files on your drive. If the Repair Disk Permissions function finds a file with permissions that differ from what a receipt claims they should be, that file’s permissions are reset to their receipt-specified values. (If you’re curious about the information contained in a receipt, the easiest way to view it is to use the utility Pacifist; simply drag and drop the appropriate receipt into the Pacifist window and you’ll be presented with a list of all files installed by the similarly-named installation package, along with each file’s original permissions.)
It’s worth noting here that although the function is called “Repair Disk Permissions,” what is actually happening is that files’ permissions are being reset or restored to a particular state. It’s possible—though not common—for a particular file’s permissions to differ from what a receipt claims they should be without those permissions actually being “broken.”
Are all files affected by Repair Disk Permissions?
No. As you may have inferred from the above description, only those files installed using OS X’s Installer utility and whose installation packages leave behind a proper receipt in /Library/Receipts are affected by the Repair Disk Permissions function. This means that most of the files affected by the Repair Disk Permissions function are system-level files, application files, or system add-ons—not applications installed by drag-and-drop, and not your documents or other user-level files.
If repairing permissions is useful in general, why doesn’t Apple recommend it as routine maintenance?
Apple does, quite explicitly:
It’s a good idea to repair disk permissions as a regular maintenance task after upgrading or installing new software.
That’s taken from Mac Help—in both Panther and Tiger—right on your Mac., and also applies to Leopard and Snow Leopard. Similar statements can be found in other Support articles, one of which is:
http://docs.info.apple.com/article.html?artnum=25751
which applies to all versions of OS X up to 10.6, but note the comments at the end of the article relating to Snow Leopard.

Allow unix account user to execute sqlplus in 10g

we have created a user with default groups and we required allow him to execute sqlplus command but it is giving errors. ( on same system we have db and oracle account). we do not want him to login into sysdba but as normal user so that he could enter sqlplus user/passwd@dbname. what should be done when a new unix account is created and how allow him to execute sqlplus command?
OS: openSUSE 11.1 - 32 bi
DB : 10.2.0.1.0 - 32 bit
do we need to install instant client ? to allow other than oracle user to access oracle db on same system?
please help me out. thanks in advance.

user612078 wrote:
we have created a user with default groups and we required allow him to execute sqlplus command but it is giving errors. ( on same system we have db and oracle account). we do not want him to login into sysdba but as normal user so that he could enter sqlplus user/passwd@dbname. what should be done when a new unix account is created and how allow him to execute sqlplus command?
OS: openSUSE 11.1 - 32 bi
DB : 10.2.0.1.0 - 32 bit
do we need to install instant client ? to allow other than oracle user to access oracle db on same system?
please help me out. thanks in advance.If this is on the same box as the db, you definately don't need to install any other client, as the full client was installed with the db. The client you are using has nothing to do with what permissions a particular user may or may not have, either at the OS or DB level.
You say it is giving errors, but you didn't think giving the acutal specific error message might be needed to help you diagnose the problem? My crystal ball is out for repair.

Custom Objects

Hi,
I have created a custom object and dragged it to the Custom Object Library. When I am on my disconnected designer, am able to use it.
But, I want let other use it.
Please tell me how do I export the custom object from the designer and import the custom object into the Livecycle workbench ES2 resources.
Thanks and Regards,
Sonika

We are working to create a portlet that will integrate with the Crystal Enterprise reporting engine from Business Objects. The difficultly here is the authentication and authorization. Crystal can tie into Active Directory for authentication and authorization, but not the plumtree portal. We need the integration to work properly for all users in plumtree, whether they come from AD or not. As such, we need to build some type of custom authentication and authorization capabilities into our portlet.
Nonetheless, we plan to make as much use as possible with what is already provided. So our plan is to create a set of SQL tables that will tie together a crystal report with a list of groups in plumtree and define what rights those particular plumtree groups have on the report.
The reason I was interested in creating custom objects is as follows: If I could create a "crystal report" object in our plumtree portal, I would then have to do NO coding to allow administrators in plumtree to assign permissions for particular groups to those "crystal report" objects. My portlet would do a simple query of what "crystal report" objects the current user has access to and display them, and allow the user to interact with them. As it is, we are planning to create interfaces for adding and removing groups to a report, and giving those groups various levels of access to the reports.
Thanks for asking.

Answers on factless facts

Hi,
How does OBIEE, Answers in particular, cope with factless fact tables? The related dimensions would be linked to that factless fact in the pysical and BMM tier, but the factless fact would not be shown in the subject area.
When an user selects two or more dimensions linked through this factless fact, how would BI Server generate the query?
Is it recommended to have a least a dummy measure in that fact?
Thank you!

Hy,
I have an example here :
http://gerardnico.com/wiki/dat/obiee/bi_server/design/obiee_densification_design_preservation_dimension
I don't use a factless fact table but a densification process.
The techniques used are the same as it's based on the fact vertical partitioning.
http://gerardnico.com/wiki/dat/obiee/bi_server/design/fact_table/obiee_fact-based_partitioning_outer_joins
And you can see the two queries and the full outer join issued.
Success
Nico
And thanks Stijn (I didn't know the implict fact)

Report Performmance

Hi,
I'm observing an Issue on OBIEE server,a particular query for a particular report is taking around 14secs if we execute it directly on the database the report itself is taking around 1:00 -2:00 mins to display.
Has any one observed the same issue.
This is happening for many reports.
Thanks
Prakash

Hi Prakash,
do you have these response time just in Answers or when you run the report on a dashboard?
When it's on a dashboard it's possible that other reports are running at the same time.
What you can do to do some first checks, is putting your loglevel to 7 and see where your query is taking so much time...
Kr,
A

Opening files crashes Applications and closes Finder

As I've been unofficial Apple "IT" for our graphics team in a biased world of PC and our IT haven't the knowhow or inclination to help I need REAL support!
After the last security etc update my iTunes crashed every time I tried to open it (Dock or Folder).
Re-installed from the Apple web download.
It now works.
Now when I open a job folder through Finder on the desktop then select the file to open Finder closes.
When I have an application open - say Photoshop CS2 - and go > File > Open, once I select the file to open Photoshop "unexpectedly quits".
This goes for ANY application!
BUT...If I drag a file to the application on the dock all is well?
If I want to place images /graphics etc from one application to whatever is open I now can't
I hold hands high as not being the most in-depth technical Mac man but have a general feel for most niggles having grown with Classic onwards!
This something new and hopefully someone can shine a light?

You should do it from Disk Utility on your start-up disk.
What are permissions?
Every file and folder on a Mac OS X hard drive has a set of permissions—settings that determine which user(s) have access to each item, and exactly what that access is. For example, permissions dictate whether or not a particular user can open and edit a particular file. But permissions also determine which items the operating system—or specific parts of it—can access and modify, and which files are accessible by applications.
What does repairing permissions do?
The Repair Disk Permissions function—the process that actually performs the task of repairing permissions—examines certain files and folders on your Mac’s hard drive to see if their current permissions settings are what Mac OS X expects them to be; if discrepancies are found, the offending permissions are changed to match the expected settings.
(In Mac OS X 10.3 and later, repairing permissions also performs one other, unrelated, task: If the invisible /tmp symbolic link—which is linked to the /private/tmp directory—is missing, the link will be recreated.)
Why is it necessary to repair permissions?
If permissions on particular files are “incorrect”—i.e., not what Mac OS X expects them to be or not what they need to be for your Mac’s normal operation—you can experience problems when the operating system tries to access or modify those files. For example, you may have trouble logging in to your account, printing, launching applications, or even starting up your Mac. Similarly, if an application—from Apple or a third-party developer—needs access to a particular file or folder to function, and the permissions on that item have changed in a way that prevents such access, the application may not function properly (or at all). The Repair Disk Permissions function can fix such problems by ensuring that certain files have the correct permissions.
There’s also a security element here: Many system-level files have permissions set a particular way so that applications or users that shouldn’t be meddling with those files can’t. If the permissions on certain system-level files somehow get changed so that access to those files is no longer restricted, you’ve got the potential for a major security issue. Repairing permissions can resolve such issues by resetting permissions on those files to prevent unauthorized access.
How do I repair permissions?
The Repair Disk Permissions function is part of Apple’s Disk Utility (in /Applications/Utilities). After launching Disk Utility, select the desired disk—generally your startup disk—in the list to the left, then click the First Aid tab. At the bottom of the First Aid panel, click the Repair Disk Permissions button. (You could instead use the Verify Disk Permissions option to preview any potential repairs before performing them, but for most users there’s little benefit from this extra step.)
Permissions can also be repaired via the shell (Terminal) by using the command sudo diskutil repairPermissions /. However, it’s unlikely that the typical user will ever need to perform the task in this manner. It’s useful if for some reason Disk Utility itself won’t launch, or for repairing permissions on a remote Mac when connected via Remote Login (SSH), but otherwise you’re just as well served using Disk Utility.
How does the Repair Disk Permissions function know what the “correct” permissions are?
When you use Apple’s Installer utility to install software (such as Mac OS X itself or an OS X update), the installation package (the .pkg file you double-click to begin installation, or that Software Update downloads in the background for an automatic installation) generally leaves behind a receipt—a smaller Mac OS X package that includes information about every file installed, including the permissions each file should have. This receipt is placed in /Library/Receipts. When you run the Repair Disk Permissions function, it examines the receipts in the /Library/Receipts directory of the disk being repaired—which means the feature works only on volumes with Mac OS X installed—and compares the information in the receipt with the actual files on your drive. If the Repair Disk Permissions function finds a file with permissions that differ from what a receipt claims they should be, that file’s permissions are reset to their receipt-specified values. (If you’re curious about the information contained in a receipt, the easiest way to view it is to use the utility Pacifist; simply drag and drop the appropriate receipt into the Pacifist window and you’ll be presented with a list of all files installed by the similarly-named installation package, along with each file’s original permissions.)
It’s worth noting here that although the function is called “Repair Disk Permissions,” what is actually happening is that files’ permissions are being reset or restored to a particular state. It’s possible—though not common—for a particular file’s permissions to differ from what a receipt claims they should be without those permissions actually being “broken.”
Are all files affected by Repair Disk Permissions?
No. As you may have inferred from the above description, only those files installed using OS X’s Installer utility and whose installation packages leave behind a proper receipt in /Library/Receipts are affected by the Repair Disk Permissions function. This means that most of the files affected by the Repair Disk Permissions function are system-level files, application files, or system add-ons—not applications installed by drag-and-drop, and not your documents or other user-level files.
If repairing permissions is useful in general, why doesn’t Apple recommend it as routine maintenance?
Apple does, quite explicitly:
It’s a good idea to repair disk permissions as a regular maintenance task after upgrading or installing new software.
That’s taken from Mac Help—in both Panther and Tiger—right on your Mac. Similar statements can be found in other Support articles.
(With thanks to another user who posted this here)

Can anyone here at the forum please explain what is"maintenance sripts".

What is the difference between -daily, weekly, monthly, maintenance scripts and should this procedure be done on Macbook Pro's?

More about Maintenance Scripts (and how to run them) here:
http://www.thexlab.com/faqs/maintscripts.html
Yes, you allow them to run periodically. You can also use the free utility Onyx to do this:
http://www.apple.com/downloads/macosx/systemdiskutilities/onyx.html
as well as the alternatives mentioned in the first link.
Repairing permissions is also an important part of regular maintenance, and should always be carried out both before and after any software installation or update.
Go to Disk Utility (this is in your Utilities Folder in your Application folder) and click on the icon of your hard disk (not the one with all the numbers).
In First Aid, click on Repair Permissions.
This only takes a minute or two.
And so save you asking:
What are permissions?
Every file and folder on a Mac OS X hard drive has a set of permissions—settings that determine which user(s) have access to each item, and exactly what that access is. For example, permissions dictate whether or not a particular user can open and edit a particular file. But permissions also determine which items the operating system—or specific parts of it—can access and modify, and which files are accessible by applications.
What does repairing permissions do?
The Repair Disk Permissions function—the process that actually performs the task of repairing permissions—examines certain files and folders on your Mac’s hard drive to see if their current permissions settings are what Mac OS X expects them to be; if discrepancies are found, the offending permissions are changed to match the expected settings.
(In Mac OS X 10.3 and later, repairing permissions also performs one other, unrelated, task: If the invisible /tmp symbolic link—which is linked to the /private/tmp directory—is missing, the link will be recreated.)
Why is it necessary to repair permissions?
If permissions on particular files are “incorrect”—i.e., not what Mac OS X expects them to be or not what they need to be for your Mac’s normal operation—you can experience problems when the operating system tries to access or modify those files. For example, you may have trouble logging in to your account, printing, launching applications, or even starting up your Mac. Similarly, if an application—from Apple or a third-party developer—needs access to a particular file or folder to function, and the permissions on that item have changed in a way that prevents such access, the application may not function properly (or at all). The Repair Disk Permissions function can fix such problems by ensuring that certain files have the correct permissions.
There’s also a security element here: Many system-level files have permissions set a particular way so that applications or users that shouldn’t be meddling with those files can’t. If the permissions on certain system-level files somehow get changed so that access to those files is no longer restricted, you’ve got the potential for a major security issue. Repairing permissions can resolve such issues by resetting permissions on those files to prevent unauthorized access.
How do I repair permissions?
The Repair Disk Permissions function is part of Apple’s Disk Utility (in /Applications/Utilities). After launching Disk Utility, select the desired disk—generally your startup disk—in the list to the left, then click the First Aid tab. At the bottom of the First Aid panel, click the Repair Disk Permissions button. (You could instead use the Verify Disk Permissions option to preview any potential repairs before performing them, but for most users there’s little benefit from this extra step.)
Permissions can also be repaired via the shell (Terminal) by using the command sudo diskutil repairPermissions /. However, it’s unlikely that the typical user will ever need to perform the task in this manner. It’s useful if for some reason Disk Utility itself won’t launch, or for repairing permissions on a remote Mac when connected via Remote Login (SSH), but otherwise you’re just as well served using Disk Utility.
How does the Repair Disk Permissions function know what the “correct” permissions are?
When you use Apple’s Installer utility to install software (such as Mac OS X itself or an OS X update), the installation package (the .pkg file you double-click to begin installation, or that Software Update downloads in the background for an automatic installation) generally leaves behind a receipt—a smaller Mac OS X package that includes information about every file installed, including the permissions each file should have. This receipt is placed in /Library/Receipts. When you run the Repair Disk Permissions function, it examines the receipts in the /Library/Receipts directory of the disk being repaired—which means the feature works only on volumes with Mac OS X installed—and compares the information in the receipt with the actual files on your drive. If the Repair Disk Permissions function finds a file with permissions that differ from what a receipt claims they should be, that file’s permissions are reset to their receipt-specified values. (If you’re curious about the information contained in a receipt, the easiest way to view it is to use the utility Pacifist; simply drag and drop the appropriate receipt into the Pacifist window and you’ll be presented with a list of all files installed by the similarly-named installation package, along with each file’s original permissions.)
It’s worth noting here that although the function is called “Repair Disk Permissions,” what is actually happening is that files’ permissions are being reset or restored to a particular state. It’s possible—though not common—for a particular file’s permissions to differ from what a receipt claims they should be without those permissions actually being “broken.”
Are all files affected by Repair Disk Permissions?
No. As you may have inferred from the above description, only those files installed using OS X’s Installer utility and whose installation packages leave behind a proper receipt in /Library/Receipts are affected by the Repair Disk Permissions function. This means that most of the files affected by the Repair Disk Permissions function are system-level files, application files, or system add-ons—not applications installed by drag-and-drop, and not your documents or other user-level files.
If repairing permissions is useful in general, why doesn’t Apple recommend it as routine maintenance?
Apple does, quite explicitly:
It’s a good idea to repair disk permissions as a regular maintenance task after upgrading or installing new software.
That’s taken from Mac Help—in both Panther and Tiger—right on your Mac. Similar statements can be found in other Support articles, one of which is:
http://docs.info.apple.com/article.html?artnum=25751

OBIEE Permissions to particular SubjectAreas

Similar Messages

Maybe you are looking for