I'm trying to let my user bob the permissions to change the screen brightness, which means: let bob read, write permissions for /sys/class/backlight/intel_backlight/brightness
using:
udevadm info -a -p /sys/class/backlight/intel_backlight/
shows that following result:
looking at device '/devices/pci0000:00/0000:00:02.0/drm/card1/card1-eDP-1/intel_backlight':
KERNEL=="intel_backlight"
SUBSYSTEM=="backlight"
DRIVER==""
ATTR{actual_brightness}=="7500"
ATTR{bl_power}=="0"
ATTR{brightness}=="7500"
ATTR{max_brightness}=="7500"
ATTR{type}=="raw"
.
.
.
So I wrote a udev rule for that in /etc/udev/rules.d/30-brightness.rules
30-brightness.rules
KERNEL=="intel_backlight", SUBSYSTEM=="backlight", RUN+="/usr/bin/find /sys/class/backlight/intel_backlight/ -type f -name brightness -exec chown bob:bob {} \; -exec chmod 666 {} \;"
But event after a reboot the file permissions stays -rw-r--r-- 1 root root
So my question is how to change specific file permissions using udev rule and what am I doing wrong?
I have solved the problem,
the dev-rule should look like this (without the backslashes)
KERNEL=="intel_backlight", SUBSYSTEM=="backlight", RUN+="/usr/bin/find /sys/class/backlight/intel_backlight/ -type f -name brightness -exec chown bob:bob {} ; -exec chmod 666 {} ;"
But note that the above RUN command won't work on the terminal command line (for that you need to have the backslashes)
Related
I try to find all directories in /home that are not owned by root and change their permissions to ensure they have 711 permission in the same command.
find \home type -d -not -user root -ls | chmod 711 {} \
But the command I used doesn't work.
The following should work:
find /home -type d -not -user root -exec chmod 711 {} +
The -exec action allows you to run a separate executable (in this case chmod) and supply the found names to it. The + at the end allows find to run chmod with multiple names at once.
The above includes fixes for a few typos: \home should be /home, type -d should be -type d.
The first instruction has wrong syntax. You could try:
find /home -type d -not -user root -ls
Also, you shouldn't use "ls" if you care about performance. Instead I suggest using the -exec switch.
Good luck
I have a directory (we will call /files) with ~1300 subdirectories, each of which contains further subdirectories and files.
90% of the top level directories in /files belong to apache:apache and the rest belong to root:root. I need everything to belong to apache:apache.
I think if I do a recursive chown on the whole lot it will be quite extreme, so I was wondering if there's a more efficient way to recursively change ownership of just the root:root directories to apache:apache.
Bonus if chmod can be done on these directories in the same way.
Your recursive chown would have probably been done already, but you could use this instead:
find . -type d \( ! -user apache -o ! -group apache \) -print0 | xargs -0 chown apache:apache
To change directories that have the wrong permission:
find . -type d ! -perm 755 -print0 | xargs -0 chmod 755
Using linux's find command is going to help there:
find /files -user root -group root -type d \
-exec chmod something {} \; -exec chown apache.apache {} \;
for more details on WHY that works there is http://www.explainshell.com/explain?cmd=find+%2Ffiles+-user+root+-group+root+-type+d+-exec+foo+\%3B
I am trying to change the permissions of a files present in a directory and subdirectories using the below command and running into below error..can anyone help?
user#machine:/local/mnt/workspace$ find . -type f -exec chmod 644 {} \;
chmod: changing permissions of `./halimpl/ncihal/adaptation/NonVolatileStore.cpp': Operation not permitted
you can run the following command:
#chown -R directory_path
But it will change the permissions of directories also.
For only files, you can run.
#find directory_path -type f -exec chmod 644 {} \;
It also looks like you dont have enough permissions. try
#sudo find directory_path -type f -exec chmod 644 {} \;
or run the command as root user.
It looks to me like you don't have permission to change NonVolatileStore.cpp.
Are you aware of chmod's -R switch that recursively changes permissions?
if you have the root privilege, try:
sudo find . -type f -exec chmod 644 {} \;
It could be that you simply don't own that file. Run an ls -l on it to see full permissions and who the owner is.
It could also be the filesystem is read only.
I have a Linux server (Debian 7) with lots of users who needs Wordpress. When I create the users what group should they be in? Today I assign them to www-data.
Then they download Wordpress by SFTP and runs the installation.
Which file permissions and user/group should their files have, specially wp-config.php?
Now, users can peek in eachothers wp-config.php from the terminal and read the password. Not very good.
Since the users aren't root they cant change file permissions/owner of wp-config.php which would solve my problem.
You can use this script by Mike Conigliaro for for setting permissions correctly on all wordpress files.
WP_OWNER=changeme # <-- wordpress owner
WP_GROUP=changeme # <-- wordpress group
WP_ROOT=/home/changeme # <-- wordpress root directory
WS_GROUP=changeme # <-- webserver group
# reset to safe defaults
find ${WP_ROOT} -exec chown ${WP_OWNER}:${WP_GROUP} {} \;
find ${WP_ROOT} -type d -exec chmod 755 {} \;
find ${WP_ROOT} -type f -exec chmod 644 {} \;
# allow wordpress to manage wp-config.php (but prevent world access)
chgrp ${WS_GROUP} ${WP_ROOT}/wp-config.php
chmod 660 ${WP_ROOT}/wp-config.php
# allow wordpress to manage .htaccess
touch ${WP_ROOT}/.htaccess
chgrp ${WS_GROUP} ${WP_ROOT}/.htaccess
chmod 664 ${WP_ROOT}/.htaccess
# allow wordpress to manage wp-content
find ${WP_ROOT}/wp-content -exec chgrp ${WS_GROUP} {} \;
find ${WP_ROOT}/wp-content -type d -exec chmod 775 {} \;
find ${WP_ROOT}/wp-content -type f -exec chmod 664 {} \;
This is how I solved it:
Create users in a group "users". Create a script in /etc/cron.hourly that fixes permissions on all wp-config.php-files like this:
for f in locate wp-config.php
do
chgrp www-data $f
chmod 640 $f
done
Works like a charm.
I have tried the following command to chmod many images within a folder...
chown -R apache:apache *
But i get the follwing error
-bash: /usr/bin: Argument list too long
I then tried ...
ls | xargs chown -R apache:apache *
and then get the following message...
-bash: /usr/bin/xargs: Argument list too long
Does anyone have any way to do this? I'm stumped :(
Many thanks
William
Omit the * after xargs chown because it will try to add the list of all file names twice twice (once from ls and then again from *).
Try
chown -R apache:apache .
This changes the current folder (.) and everything in it and always works. If you need different permissions for the folder itself, write them down and restore them afterwards using chown without -R.
If you really want to process only the contents of the folder, this will work:
find . -maxdepth 1 -not -name "." -print0 | xargs --null chown -R apache:apache
This may work:
find . -maxdepth 1 -not -name -exec chown -R apache:apache {} \;
You can simply pass the current directory to chown -R:
chown -R apache:apache .
The one corner case where this is incorrect is if you want all files and subdirectories, but not the current directory and the .dotfiles in it, to have the new owner. The rest of this answer explains approaches for that scenario in more detail, but if you don't need that, you can stop reading here.
If you have root or equivalent privileges, doing a cleanup back to the original owner without -R is probably acceptable; or you can fix the xargs to avoid the pesky, buggy ls and take out the incorrect final * argument from the OP's attempt:
printf '%s\0' * | xargs -r0 chmod -R apache:apache
Notice the GNU extension to use a null byte as separator. If you don't have -0 in your xargs, maybe revert to find, as suggested already in an older answer.
find . -maxdepth 1 -name '*' -exec chmod -R apache:apache {} +
If your find doesn't understand -exec ... {} + try -exec ... {} \; instead.