Pacman root file permissions.

I am wondering if I did something wrong in the initial Arch Linux install.
Just about every time I use pacman to install a package I have to go track down and fix file permissions so I can run the program as a user. Is this normally how things are done? Or am I doing something wrong?
I use pacman with sudo, because it will not work otherwise. So I use sudo pacman -S <package> OR sudo pacman -U <aur package> after using makepkg.
Thanks.

babakott wrote:I use pacman with sudo, because it will not work otherwise.
pacman isn't supposed to work otherwise.
but the installed packages shouldn't need sudo.

Similar Messages

[SOLVED] Incorrect File Permissions

I did something very stupid involving a recursive chmod in the wrong directory. I realized my mistake right away and stopped the execution, but I don't know how many files got hit. I at least know /usr/bin got changed since I get the wonderful "sudo: must be setuid root".
Is it practical to try and fix some of the file permissions in single user mode or should I just wipe and reinstall Arch? It's a relatively clean/recent installation.
Last edited by mdschechtman (2011-08-05 17:12:11)

mdschechtman wrote:I did "# chown -R root:root .*", or at least I thought I did.
So you did `chown', not `chmod' as you initially stated. If you did run that command, with ".*" as argument, it should have only changed the hidden files and directories recursively. But you seem unsure about the actual command you ran? Try `history | grep chown' maybe...
mdschechtman wrote:In my panic, I forgot to check which directory I ran the command from.
OK. My script should be able to fix the system files, provided you adjust $min accordingly.
On the other hand, since you don't have an idea which directory is affected, `find' needs to do a lot of work on the whole /, you might as well just reinstall all of your packages... i.e. `pacman -S $(pacman -Qq)'. (Edit: Note though, pacman will not fix permissions or ownership of directories, but will, AFAIK, print a warning when they differ).
Next time... Remember, don't panic!!!1
Last edited by lolilolicon (2011-08-05 17:09:31)

[SOLVED] Pacman "config file could not be read" error during Arch ins

I've been attempting to get Arch setup for a while now, and after having some trouble with partitions, my wireless connecting, and setting up repos and mirrors, which the Wiki helped me solve, I've hit a bigger bump. While updating the system using pacman as the Beginners Guide says to do, I get errors when I try to continue the update process as follows :
btw: I'm typing this on a laptop next to my computer
[root@McArch~]# pacman -Syu
error: config file /etc/pacman.d/core could not be read
error: config file /etc/pacman.d/extra could not be read
error: config file /etc/pacman.d/community could not be read
:: Synchronizing package databases . . .
error: failed to updated core (unexpected error)
error: failed to updated extra (unexpected error)
error: failed to updated community (unexpected error)
error: failed to synchronize any databases
Any tips as to whats going on? I've tried to created said files, and even insert mirrors into the file, like in the /etc/pacman.d/mirrorlist file but this doesn't seem to help
Last edited by Windfinder (2008-09-29 20:43:29)

Glad you got it working.
I'm not sure what happened in your install but I just finished using an old 2007.08 iso and pacman first starts out with /etc/pacman.d/core, etc/pacman.d/extra, /etc/pacman.d/community ... etc., but I never had your problem when I did the #pacman -Syu after initial install reboot. The pacman update removes the above mentioned repos and replaces them with a single /etc/pacman.d/mirrorlist. You must have messed up an initial config file somehow as I couldn't get the same errors you got. It looks like you had your /etc/pacman.conf file messed up somehow and when you pointed it to the mirrorlist it could finally work properly. I'll just include my /etc/pacman.conf file and /etc/pacman.d/mirrorlist so you can compare. NB* these are from my x86_64 so for 32 bit machines i686 would replace x86_64 in the files.
# /etc/pacman.conf
# See the pacman.conf(5) manpage for option and repository directives
# GENERAL OPTIONS
[options]
# The following paths are commented out with their default values listed.
# If you wish to use different paths, uncomment and update the paths.
#RootDir = /
#DBPath = /var/lib/pacman/
#CacheDir = /var/cache/pacman/pkg/
#LogFile = /var/log/pacman.log
HoldPkg = pacman glibc
# If upgrades are available for these packages they will be asked for first
SyncFirst = pacman
#XferCommand = /usr/bin/wget --passive-ftp -c -O %o %u
#XferCommand = /usr/bin/curl %u > %o
# Pacman won't upgrade packages listed in IgnorePkg and members of IgnoreGroup
#IgnorePkg =
#IgnoreGroup =
#NoUpgrade =
#NoExtract =
# Misc options (all disabled by default)
#NoPassiveFtp
#UseSyslog
#ShowSize
#UseDelta
#TotalDownload
# REPOSITORIES
# - can be defined here or included from another file
# - pacman will search repositories in the order defined here
# - local/custom mirrors can be added here or in separate files
# - repositories listed first will take precedence when packages
# have identical names, regardless of version number
# - URLs will have $repo replaced by the name of the current repo
# Repository entries are of the format:
# [repo-name]
# Server = ServerName
# Include = IncludePath
# The header [repo-name] is crucial - it must be present and
# uncommented to enable the repo.
# Testing is disabled by default. To enable, uncomment the following
# two lines. You can add preferred servers immediately after the header,
# and they will be used before the default mirrors.
#[testing]
#Include = /etc/pacman.d/mirrorlist
[core]
# Add your preferred servers here, they will be used first
Include = /etc/pacman.d/mirrorlist
[extra]
# Add your preferred servers here, they will be used first
Include = /etc/pacman.d/mirrorlist
[community]
# Add your preferred servers here, they will be used first
Include = /etc/pacman.d/mirrorlist
# An example of a custom package repository. See the pacman manpage for
# tips on creating your own repositories.
#[custom]
#Server = file:///home/custompkgs
/etc/pacman.d/mirrorlist
# Arch Linux repository mirrorlist
# North America
# - United States
Server = http://mirror.neotuli.net/arch/$repo/os/x86_64
Server = http://holmes.umflint.edu/archlinux/$repo/os/x86_64
Server = http://archlinux.unixheads.org/$repo/os/x86_64
Server = ftp://ftp.archlinux.org/$repo/os/x86_64
Server = ftp://locke.suu.edu/linux/dist/archlinux/$repo/os/x86_64
Server = ftp://ftp.gtlib.gatech.edu/pub/linux/distributions/archlinux/$repo/os/x86_64
Server = ftp://mirror.cs.vt.edu/pub/ArchLinux/$repo/os/x86_64
Server = http://mirrors.easynews.com/linux/archlinux/$repo/os/x86_64
Server = ftp://ftp.ibiblio.org/pub/linux/distributions/archlinux/$repo/os/x86_64
Server = http://mirror.rit.edu/archlinux/$repo/os/x86_64
Server = http://mirror.umoss.org/archlinux/$repo/os/x86_64
# - Canada
Server = ftp://mirror.csclub.uwaterloo.ca/archlinux/$repo/os/@carch
Well it was an interesting way to kill 30+ minutes.

Installed Photoshop cc 2014 asks for serial # - corrupted Windows file permissions

More of a warning / heads up to all than a question - installing Photoshop cc 2014 [via the CC manager app] caused some Windows file (security) permissions to become corrupt corrupt on my system. Symptoms include cc2014 asking for serial number validation on startup (when, as a cloud version, it should not do so), then being unable to connect to the internet when you press the 'validate serial' button so getting that window into infinite loops, and - a real pain in the *** when trying to fix the above - causing abends of some windows shell functions that in turn cause windows explorer to crash and restart.
Anyhow, digging into this (fortunately, I am a long time Windows SysProg) I discovered that for reasons unknown, either the CC master app or the actual Photoshop cc2014 installer (or both) are changing file access control permissions on a number of files, mostly DLL's. Most of the files affected are in the (normally hidden) Program Data directory on the windows root disk, Some of them are in the Adobe subdirectory - so fair enough if they want to fool around with their own program - but others being changed are in the Common Files and Microsoft subdirectories. I cannot for the life of me figure out why this is necessary nor why Adobe feel the need to touch files that 'do not belong' to them - something dangerous in the extreme as an external app such as Windows Update might replace or 'repair' the files so touched, and if Adobe / CC are relying on file permissions on non-Adobe files, such changes could result in all manner of random and spurious problems / error messages occurring.
Anyhow, if, fellow Photoshop cc 2014 user, you get this happen to you then you can fix the file permissions by opening a console window [also called a "DOS box", or "command prompt" depending on your age and knowledge... 8-) ] and run the windows file checker with the command
"sfc /scannow". Make sure that you use 'run as administrator' to open the console window, or you'll get an error about sfc only being available to administrators. Also a very (very) sensible idea to close all non-essential running applications first to prevent any possibility of weird interactions happening.
Finally, check that the 'hosts' file in [root drive]:/Windows/System32/drivers/etc is valid - for some reason, it looks like the install tried to check or update this file (again, I have no idea why) but the result was a corrupted hosts file, which I assume is the root cause of the 'unable to connect to host' type internet error messages. Copy the file, rename it as 'hosts.txt' and edit it with notepad or wordpad. Look for lines containing garbage strings at the bottom of the file (any line that starts with a # ignore, it is a comment, and any line that has IP addresses or host names should be ignored - though if they reference a site such as "someserver.adobe.com" you might want to treat them with suspicion if you continue to get internet 'cant connect to site' type errors.
Anyhow, when I fixed these two sets of problems, Photoshop cc 2014 started 'right first time' without all the BS messages about serial numbers etc.
Hope this helps somebody out there in AdobeLand......
Rick

Update: I tried several times to reproduce the error, actually it dosen't occur. I changed nothing on my system, without reboot it twice. This is what I said in my beginning times: it occurs sometimes but often. I will keep you up to date.

SOLVED: kernel loads, but doesn't have a root file system

Hi,
The system is an Asus X202E. It does UEFI and has a GPT partition system. I've gotten through that part. And it is clear to me that the kernel loads.
It's the next step that's giving me grief. I've tried this with two bootloaders: gummiboot and rEFInd.
With gummiboot, the kernel panics because it can't mount the root file system. With rEFInd, it gets to the intial ramdisk and then drops me to a shell, apparently because the root file system is set to null, and it obviously can't mount that as "real root".
Here is what I posted on the Arch mailing list, documenting that I have indeed specified the correct root (I'm copying this from the email, eliding the unfortunate line wraps):
bridge-live# cat /boot/loader/entries/arch.conf
Title Arch Linux
linux /vmlinuz-linux
initrc /initramfs-linux.img
options root=PARTUUID=d5bb2ad1-9e7d-4c75-b9b6-04865dd77782
bridge-live# ls -l /dev/disk/by-partuuid
total 0
lrwxrwxrwx 1 root root 10 Apr 15 19:26 0ab4d458-cd09-4bfb-a447-5f5fa66332e2 -> ../../sda6
lrwxrwxrwx 1 root root 10 Apr 15 19:26 3e12caeb-1424-451c-898e-a4ff05eab48d -> ../../sda7
lrwxrwxrwx 1 root root 10 Apr 15 19:26 432a977b-f26d-4e75-b9ee-bf610ee6f4a4 -> ../../sda3
lrwxrwxrwx 1 root root 10 Apr 15 19:26 95a1d2c2-393a-4150-bbd2-d8e7179e7f8a -> ../../sda2
lrwxrwxrwx 1 root root 10 Apr 15 19:26 a4b797d9-0868-4bd1-a92d-f244639039f5 -> ../../sda4
lrwxrwxrwx 1 root root 10 Apr 15 19:26 d5bb2ad1-9e7d-4c75-b9b6-04865dd77782 -> ../../sda8
lrwxrwxrwx 1 root root 10 Apr 15 19:26 ed04135b-bd79-4c7c-b3b5-b0f9c2fe6826 -> ../../sda1
lrwxrwxrwx 1 root root 10 Apr 15 19:26 f64f82a7-8f2b-4748-88b1-7b0c61e71c70 -> ../../sda5
The root partition is supposed to be /dev/sda8, that is:
lrwxrwxrwx 1 root root 10 Apr 15 19:26 d5bb2ad1-9e7d-4c75-b9b6-04865dd77782 -> ../../sda8
So the correct PARTUUID followed by the one I have specified in
arch.conf is:
d5bb2ad1-9e7d-4c75-b9b6-04865dd77782
d5bb2ad1-9e7d-4c75-b9b6-04865dd77782
I'm guessing that this is really the same problem with both gummiboot and with rEFInd, but don't really know. It's clear to me that the initrd is not being correctly constructed. So I removed /etc/mkinitcpio.conf and did, as per the Arch wiki,
pacman -Syyu mkinitcpio linux udev
No joy.
I don't even know which way to go at this point. If I even knew how to tell it where the real disk is in the initial ram disk shell, that would help. Better of course, would be actually solving the problem.
Thanks!
Last edited by n4rky (2013-04-17 21:41:36)

I have made extremely limited progress on this issue.
My previous attempt to specify the root partition in mkinitcpio.conf was insufficient. Furthermore, this is no place--despite the documentation--for the orthodoxy about using UUIDs rather than the straight /dev/sdx. In my case:
root=/dev/sda8
and run
mkinitcpio -p linux
It still drops me into the shell at boot. I can do
mount /dev/sda8 /new_root/
and exit the shell. It still won't believe it has the root device and drops me back in. I just exit.
At this point, for a very brief moment, things look promising. It appears to be starting normally. Then, gdm.service, NetworkManager.service, and dbus.service all fail to start. There may be others but the screen goes by too quickly. At this point, it hangs trying to initialize the pacman keyring and all I can do is CTRL-ALT-DEL.
It occurred to me that this might extend to the rEFInd configuration and so I modified it to also use /dev/sda8 rather than the UUID, but this made no difference. Trying to boot via gummiboot still yields the previously specified kernel panic.

Permz - Quickly change file permissions in any file manager

Designed to be integrated into any file manager, permz is a bash script which presents a GUI menu. You can use it to quickly change file permissions and ownership as a normal user or as root, and delete files as root. I wrote this because I have yet to see a file manager that isn't cumbersome for this - the mechanism is usually buried on a second tab of the Properties window, and changing permissions often involves multiple clicks in a grid. To change the owner of a file, you need to type the username. And if the file is owned by root, you can't do anything.
permz --help
Presents a GUI menu for changing file permissions/ownership. May be run
as a normal user or root.
Requires: zenity gksu
Optional: sudo (recommended to prevent multiple root password prompts)
Usage: permz FILE [...]
MENU FUNCTIONS:
rwxrwxrwx Sets file(s) to given permissions
Sticky Clear/Set Performs "chmod -t" or +t to clear or set the sticky
bit. You may select to clear/set sticky in addition
to changing other permissions.
Recursive go-rxw "chmod -R go-rxw" on file(s) recursively, denying
access to non-owners
Recursive go-w "chmod -R go-w" on file(s) recursively, denying write
to non-owners
Recursive ugo+rX "chmod -R ugo+rX" giving read access to all. Also
sets +x for directories and executables.
Recursive ugo+w "chmod -R ugo+w" on file(s), giving write to all
(You may select several compatible recursive functions above at once)
Owner USER As ROOT Sets ownership to USER:USER as root
DELETE As ROOT Deletes file(s) as root. Must be used alone or with
"Perform Recursively" (to delete directories - USE
WITH CAUTION). Not available if permz is run as root.
Perform As ROOT Run as root to change selected permissions.
(Use of root is automatic when changing ownership)
Perform Recursively Adds -R to all chmod, chown, and delete commands to
descend into subdirectories. Use in conjunction with
any other functions. (Recursion is automatic for
"Recursive" functions above)
Current su command is set to: gksu -gS
If you're somewhat familiar with bash, adding additional options or changing the existing ones is straightforward.
I have tested it pretty thoroughly but if you do encounter anything amiss please let me know.
More details at http://igurublog.wordpress.com/downloads/script-permz/
And in the AUR at http://aur.archlinux.org/packages.php?ID=36978
Instructions for integrating permz into PCManFM-Mod are here.
Last edited by IgnorantGuru (2010-05-05 13:53:08)

rransom wrote:Recursive ugo+rX would be more useful than "Recursive ugo+r (dirs +x)". (The +X feature of chmod is available at least in GNU coreutils, FreeBSD, and POSIX 2003.)
Done - thanks for the tip. I also left the old code active in there with just the menu option disabled, so if anyone wants it the other way or wants both it's easy to enable. The difference is that the old way won't make any files +x, just dirs.
permz doesn't provide every possible setting of permissions, just common ones, so you may want to customize it. But I used to have these as user actions when I used Krusader and I found these were the handy ones, at least for me.

Root File system is reporting that it's full [SOLVED]

My root file system is reporting as full, and I'd like some ideas on how to track the problem. I've tried a number of things like searching for the largest directory, searching for the largest file, and all that jazz. I'm obviously missing something. /dev/sda3 should be at 50%.
One note. The computer started what seemed like normal today. I converted my second hard drive to ext4, rebooted, and started to notice that things that needed the /tmp directory couldn't start. I made some quick space to get operational by removing 56M of stuff from pacman's cache, but that's a quick hack. I don't know if this is related or not. I am running testin

skottish wrote:
MoonSwan wrote:
You're a dork who solved this issue and will know better next time. How is this a bad thing? I'm sure someone around here has done worse Skottish, so don't feel too stupid. (Won't name names but I'm sure as well that I've done worse somewhere...)
In the meantime, while you're down...*bonks skottish with the dork-stick*
Thanks for the kind words MoonSwan.
This happened because of the way my system is set up. I have rsync making backups of /home and /etc to /backup on close. It turns out that rsync created the /backup directory instead of using the existing one. Why? Because /dev/sdb1 wasn't mounted when I restarted after the conversion. Doh!
no shame in that. i totally freaked out once when i was still in school because i couldn't find a paper that was due. turned out i had /home unmounted when i saved the file, but had /home mounted when i went looking for it.
it was hiding under the mounted filesystem the whole time!

File Permissions in Solaris 10

Hi,
I have a problem with permissions on a shell script file. Although the file permissions are "-rwxrwxr-x" anyone else in the group, apart from file owner can't execute this file.
Regards,

First of all thanks for trying to help me. The command line output for:
--> "+ls -al /tmp/restart.sh+" is "+-rwxrwxr-x 1 admin1 admin ...+"
--> "+ls -ald /tmp+" is "+drwxrwxrwt 13 root sys ...+".
When anyone else in the admin group, besides the owner of the file, try to execute that file they get the following error: "+error: chmod: warning: can't change /tmp/restart.sh+".
If I change file owner it works properly, but I don't want to change the owner each time the file is used. Maybe it's all about that sticky bit?!
Best regards,

NMH405 - File permissions

Hi,
My NMH seems to have set file permissions on a folder which means i cant access the photo's (of my wedding of course!). I can move the photo's using the web interface, but i can't move them in windows or ubuntu. Windows says the speical permissions were set by Unix Root .
Now i am thinking there maybe a way to set these back using the alternative NMH405 interface (the non flash one) but i can't for the life of me find out how to access it. PLEASE help!

if i may ask, where are these locked files from (source)?
are all of your files on the Media Hub locked?
i found an article: https://help.ubuntu.com/community/RootSudo, i dont know if this might help.

Weird Locked Files/Permissions/Dock/Etc

I have some sort of odd locked file/permissions problem (I think).
About a year ago, I seem to have done something to my permissions or locked files that I can't seem to fix. I have a variety of disparate symptoms, including applications that won't work or can't be installed/deleted because support or preference files are locked or can't be changed, a need to repeatedly reauthenticate with a password just to move files from one folder to the next, an inability to turn off file sync for mobile me, dock item changes that go away whenever I reboot, locked files that continually reopen in Preview, having to manually delete and reinstall apps like Preview apparently because of locked preference files, printers that won't work because of locked files until I delete all and reinstall, software that won't run properly or fails to launch at all on double click, etc.
It is almost like a ghost in the machine problem because the problems are relatively varied.
I've tried disk utility etc to repair permissions and none of the repairs work (I keep getting the same errors, copied below). I've tried a complete reinstall of the OS, repair permissions from the OS X restore disk, etc. and nothing seems to help.
This is happening on a Mac Pro 1,1 (3.0 GHz), running 10.7.4 with all updates through today and with a Radeon 4870 card, and 9 GB of properly matched ram. Everything else works pretty well and I have no similar problems on my wife's 2011 iMac, my MacBookAir i5, etc.
I'm thinking that there is some sort of locked file or permissions problem that is not getting fixed correctly and that there might be some trick to fixing it.
Help!!
Repairing permissions for “Master”
ACL found but not expected on “Library/Printers”
Repaired “Library/Printers”
ACL found but not expected on “private/etc/apache2/users”
Repaired “private/etc/apache2/users”
ACL found but not expected on “Library/Printers/PPDs”
Repaired “Library/Printers/PPDs”
ACL found but not expected on “Library/Printers/PPDs/Contents”
Repaired “Library/Printers/PPDs/Contents”
ACL found but not expected on “Library/Printers/PPDs/Contents/Resources”
Repaired “Library/Printers/PPDs/Contents/Resources”
ACL differs on “Users”
Repaired “Users”
ACL found but not expected on “private/var/root”
Repaired “private/var/root”
ACL found but not expected on “private/var/root/Library”
Repaired “private/var/root/Library”
ACL found but not expected on “private/var/root/Library/Preferences”
Repaired “private/var/root/Library/Preferences”
Permissions repair complete

Repairing the permissions of a home folder in Lion is a complicated procedure. I don’t know of a simpler one that always works.
Back up all data now. Before proceeding, you must be sure you can restore your system to its present state
Launch the Terminal application in any of the following ways:
☞ Enter the first few letters of its name into a Spotlight search. Select it in the results (it should be at the top.)
☞ In the Finder, select Go ▹ Utilities from the menu bar, or press the key combination shift-command-U. The application is in the folder that opens.
☞ Open LaunchPad. Click Utilities, then Terminal in the page that opens.
Drag or copy — do not type — the following line into the Terminal window, then press return:
chmod -R -N ~
The command will take a noticeable amount of time to run. When a new line ending in a dollar sign ($) appears below what you entered, it’s done. You may see a few error messages about an “invalid argument” while the command is running. You can ignore those. If you get an error message with the words “Permission denied,” enter this:
sudo !!
You'll be prompted for your login password, which won't be displayed when you type it. You may get a one-time warning not to screw up.
Next, boot into Recovery by holding down the key combination command-R at startup. Release the keys when you see a gray screen with a spinning dial.
When the Recovery screen appears, select Utilities ▹ Terminal from the menu bar.
In the Terminal window, enter “resetpassword” (without the quotes) and press return. A Reset Password window opens. You’re not going to reset the password.
Select your boot volume if not already selected.
Select your username from the menu labeled Select the user account if not already selected.
Under Reset Home Directory Permissions and ACLs, click the Reset button.
Select  ▹ Restart from the menu bar.

ExaWatcher - File permissions

Hi,
Has anyone had experience tinkering with the file permissions on the ExaWatcher folders and files? The issue we're experiencing is that all files in /opt/oracle.Exawatcher/archive (and the archive directory itself) have permissions such that they are only viewable by root. We are trying to limit the use of the root user id, would prefer that DBAs use the grid owner id instead so we would like to modify the permissions of each new file that is created to 744.
I tried browsing through the various shell scripts and .conf files in the /opt/oracle.Exawatcher directory to see if there was some sort of parameter driving the existing permissions but it was not immediately clear to me.
Any thoughts or ideas are appreciated.
Thanks.

Thanks for the response. I did notice this information in the HelpExaWatcher.sh script.
[-r|--ResultDir] "ResultDir"
    Defines the directory to allocate the result of the data collections.
    Can only be defined once for each run; if it's not specified, default value:
    "/opt/oracle.ExaWatcher/archive/";
    Creates the directory and its parent directories if not exist. Changes the permission to be 0755 if
    the directory exists. If the directory cannot be created/written to, the directory is set back the
    default. If the default directory cannot be created/written to, ExaWatcher will exit as it's impossible
    to store the collected data.
The ExaWatcher.sh is currently run with the ResultDir set to the above "default" directory and the permissions are not changed "...to be 0755 if the directory exists".
Again, we're looking for the folders and files to have 755 permissions. Any other thoughts?

Automator: shell script to change file permissions

Hey guys,
Just created a workflow to copy some files from one location to another.
Second thing I want to do is run a shell-script to set some file permissions recursively, some for the folders, the other for the files.
I figured I could do the following:
cd /IntoAFolder
find . -type d -exec chmod 770 {} \;
Unfortunately, this seems to be needed to be done as a sudo'er and thus requires the user's password.
So the question is, how do I get that password and hand it to the shell script or is there another way of doing this?

What I want to do is recursively chmod the subfolders and files of a "root"-folder.
The way I know to do so is:
cd /root-folder
find . -type d -exec chmod 755 {} \;
That will chmod all subfolders from the root-folder to 755.
Next i want
find . -type f -exec chmod 644 {} \;
That will chmod all subfiles fromn the root-folder to 644
Unfortunately, find gives me a permission denied when I run this command from the command-line. When I just manualy chmod everything that works fine but is a bit to much work when it comes down to a tree of 5 subfolders and 120 files.
Waht basically hapens:
The user selects a bunch of folders.
Then they are copied to /Applications/RCT3.localised/Data/Styles/Themed
and then I need to chmod them just to be sure, as sometimes stuff break along the way if you don't

File permissions and ownership questions

Hi all,
I'm a bit confused by the file permissions in Snow Leopard. In particular, whenever I create a folder, there is always a group permission assigned to "staff".
1) how is "staff" different from "everyone"?
2) how come if I remove the group permission for "staff", I can't add it back? It doesn't seem like the "staff" group actually exists (it doesn't show up in the user/group dialog)
And finally, does anyone know why ownership is so weird on removable drives? It seems like the "owner" of a folder created an a removable drive is just whoever is logged in at the time. So, if I log in as UserA and do an ls, I see the owner as UserA. If I log in as UserB, I see the owner as UserB.

bmm727 wrote:
Hi all,
I'm a bit confused by the file permissions in Snow Leopard. In particular, whenever I create a folder, there is always a group permission assigned to "staff".
1) how is "staff" different from "everyone"?
staff is the default group that includes all users with accounts on your computer. everyone means everyone including remote users connecting as guests if you have file sharing on who don't have user accounts on your computer.
2) how come if I remove the group permission for "staff", I can't add it back?
in short, because GUI for changing permissions is really messed up in snow leopard.
It doesn't seem like the "staff" group actually exists (it doesn't show up in the user/group dialog)
it does exist, it's just not offered as an option in that dialog. see my comment above about GUI being messed up.
Furthermore, please never delete staff from permissions this way. on top of being messed up GUI for changing permissions is buggy in snow leopard and when you remove staff from permissions that way the group on the item in question changes from staff to wheel (which is why you have to unlock the lock with your admin password in order to do this). this is wrong in most instances as only root belongs to the group wheel.
And finally, does anyone know why ownership is so weird on removable drives? It seems like the "owner" of a folder created an a removable drive is just whoever is logged in at the time. So, if I log in as UserA and do an ls, I see the owner as UserA. If I log in as UserB, I see the owner as UserB.
it's not true for all removable drives. it's only true if a drive has ownership disabled (can be done in the get info popup) or if it's formatted FAT. all thumb drives are formatted FAT by default. FAT is an old windows file system which does not understand POSIX permissions and treats everything as read+write by everybody.

Safari 5.1 file permissions of com.apple.Safari.plist (Read only impossible???)

Hi everyone,
i try to set the user agent to a differnt string. To be sure that the changes in com.apple.Safari.plist are valid i copied the file after i set safari to the changes i want it to have. i did not write anything into the file by hand. Then i set the permission to the file to Read only for my user and copied the file back to ~/Library/Preferences.
After starting safari it sets everything back to its defaults. Safari also changes the file permissions back to read&write for my user. How can i write protect this file?
If thats not possible, does anyone have an idea how to set the user-agent of safari to another string as default value? btw. i also would like to know how to set private mode to on by default.
I don't want to change my browser just because a simple configuration file's permission cannot be set permanently.
Thanks for your help!

after searching a long time i found a solution for the user-agent problem. Well it's not what i wanted in the first place, but at least this works. I can hide the user agent with the use of a small caching proxy server called "polipo".
Polipo can be found here: http://www.pps.jussieu.fr/~jch/software/polipo/
I'm not sure if there are precompiled binaries available. I compiled it from source using the gcc environment shipped with xcode by executing "./configure", "make" and "sudo make install".
To run it at startup i used this plist file:
?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Disabled</key>
    <false/>
        <key>Label</key>
        <string>fr.jussieu.pps.polipo</string>
        <key>ProgramArguments</key>
        <array>
                <string>/usr/local/bin/polipo</string>
                <string>-c</string>
                <string>/etc/polipo.conf</string>
        </array>
        <key>RunAtLoad</key>
        <true/>
    <key>OnDemand</key>
    <false/>
    <key>UserName</key>
    <string>root</string>
    <key>GroupName</key>
    <string>daemon</string>
</dict>
</plist>
i saved it under the name fr.jussieu.pps.polipo.plist in /Library/LaunchDaemons/.
then i modified the example configuration file from the source package and saved it to /etc/polipo.conf. This is the essential modification to hide the user agent:
censoredHeaders = user-agent
There are more options available to censor the Headers and to increase privacy (set-cookie2, cookie2, from, x-pad, link, accept_language).
after that i started the daemon:
sudo launchctl load /Library/LaunchDaemons/fr.jussieu.pps.polipo.plist
at last i configured my proxy settings of osx to my new local proxy for http:
host: 127.0.0.1
port: 8118
that should do it ... i hope this is usefull for someone else ...
please note: hiding the user-agent or blocking cookies may cause websites not to act normal.

OCR and Votinging Disk File Permissions for NFS 2 node RAC cluster

This is a fresh reinstall of Oracle 11gR2 Clusterware on Red Hat Enterprise Linux 64bit and I'm using NFS as my shared storage.
I've create three file systems /ocrVote01 /ocrVote02 and /ocrVote03 as NFS share and exported them to two nodes that will use them as shared OCR and Voting Disk. Currently I'm getting errors when I run root.sh
I've done the following:
chown rac:dba -R /ocrVote01 /ocrVote02 /ocrVote03
It appears that the root.sh script is trying to create a directory /ocrVote01/storage and getting permissions denied.
Any idea why Root can not create this directory?
root.sh is also getting error permission denied at /u01/gridinfra/11.2.0/GI/crs/install/crsconfiglib.pm at line 4478
Any Ideas on what file permissions should be set for /ocrVote01 /ocrVote02 and /ocrVote03 ?
Thanks
32352 close(3) = 0
32352 write(2, "mkdir /ocrVote01/storage/: Permi"..., 112) = 112
| 00000 6d 6b 64 69 72 20 2f 6f 63 72 56 6f 74 65 30 31 **mkdir /o crVote01** |
| 00010 2f 73 74 6f 72 61 67 65 2f 3a 20 50 65 72 6d 69 /storage /: Permi |
| 00020 73 73 69 6f 6e 20 64 65 6e 69 65 64 20 61 74 20 ssion de nied at |
| 00030 2f 75 30 31 2f 67 72 69 64 69 6e 66 72 61 2f 31 /u01/gri dinfra/1 |
| 00040 31 2e 32 2e 30 2f 47 49 2f 63 72 73 2f 69 6e 73 1.2.0/GI /crs/ins |
| 00050 74 61 6c 6c 2f 63 72 73 63 6f 6e 66 69 67 5f 6c tall/crs config_l |
| 00060 69 62 2e 70 6d 20 6c 69 6e 65 20 34 34 37 38 0a ib.pm li ne 4478. |
32352 exit_group(25) = ?

After reading OTN feedback, which is very much appreciated. I decided to look deeper into my NFS configuration and found that the /etc/exports had the incorrect configuration for shared disk where in root can make appropriate changes to voting disk and crs files. The correct configuration for /etc/fstab using NFS for shared storage for voting disk and CRS:
192.168.1.21:/ocrVote01 /ocrVote01 nfs rw,bg,hard,nointr,rsize=32768,wsize=32768,tcp,vers=3,timeo=600,actimeo=0 1 2
192.168.1.21:/ocrVote02 /ocrVote02 nfs rw,bg,hard,nointr,rsize=32768,wsize=32768,tcp,vers=3,timeo=600,actimeo=0 1 2
192.168.1.21:/ocrVote03 /ocrVote03 nfs rw,bg,hard,nointr,rsize=32768,wsize=32768,tcp,vers=3,timeo=600,actimeo=0 1 2

Pacman root file permissions.

Similar Messages

Maybe you are looking for