Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I have a really strange problem. I have a few files in a large directory that I want to make readable by everyone. So I try this:

sudo find readme* -not -perm -o+r -exec chmod +r {} \;

and get this:

sudo: unable to execute /usr/bin/find: Success

I don't know why it says Success, because the permissions were not changed. I verified by typing this:

find readme* -not -perm -o+r -exec ls -l {} \;

and get something like

-rw------- 1 root root 536871076 Nov 22 14:06 readme_20101122200429
-rw------- 1 root root 536871892 Nov 22 14:08 readme_20101122200642
-rw------- 1 root root 293458128 Nov 22 14:10 readme_20101122200859

as a last resort, I tried:

sudo chmod +r *

and got:

sudo: unable to execute /bin/chmod: Success

and again Success really means fail. So, I gave up and logged in as root and tried:

find readme* -not -perm -o+r -exec chmod +r {} \;

This time it worked. Why?

EDIT: /etc/sudoers looks like:

## Allow root to run any commands anywhere
root    ALL=(ALL)       ALL

##Me
user1   ALL=(ALL)       ALL
share|improve this question

migrated from stackoverflow.com Nov 23 '10 at 6:17

This question came from our site for professional and enthusiast programmers.

    
What does /etc/sudoers look like? –  Ignacio Vazquez-Abrams Nov 22 '10 at 20:10
    
Could it be because the sudo does not roll over into the -exec part of the command, so the find was run as root, but the chmod was not? –  Ben Lee Nov 22 '10 at 20:15
    
@Ben Lee: It's even stranger than that. See my new line about sudo chmod +r * –  User1 Nov 22 '10 at 20:21
    
Maybe your path is messed up. Type echo $PATH and see if it looks right. Also try which find and which chmod. –  Ben Lee Nov 22 '10 at 20:23
    
@Ben: I thought that too. The error ("Success") message shows that path of the executable. I think it looks okay. –  User1 Nov 22 '10 at 20:32

2 Answers 2

up vote 4 down vote accepted

I don't know on wich version of find you are using. But, usually the first argument is the directory where to find, and if you want to filter on some filenames you have to use the -name argument. My guess will be

sudo find . -name 'readme*' -not -perm -o+r -exec chmod +r {} \;

Do not forget to single-quote the file name pattern. If you don't, the * will be evaluated by the shell and not passed directly as an argument. This may explain the strange behaviour. Because in this case, probably the shell try to pass every filename matching readme* as arguments to sudo.

share|improve this answer
    
Commands he gave work perfectly fine for me with sudo so it probably isn't the case. –  maarons Nov 22 '10 at 22:15
    
This flavor of command actually worked! I have a LOT of files matching the pattern. I think the * expands all of those files and overflows some buffer. If I do a -name with the readme* pattern, it works fine. I'm not sure why. This was RHEL5.5 Sever. –  User1 Nov 23 '10 at 15:10
    
@User1: It works fine to say find -name 'readme*' and not find readme* because in the latter case bash is expanding the glob into a list that overflows the command buffer and in the former case find is expanding the glob internally where no such restriction applies. –  phogg Nov 24 '10 at 14:37

I think you should use:

sudo sh -c 'find readme* -not -perm -o+r -exec chmod +r {} \;'

This causes sudo to run the shell which then interprets the argument to -c as a shell script. Using single-quotes around it is simplest - unless there are single quotes in the command to be executed. In that case, each single quote in the command is replaced by four characters - '\'': quote, backslash, quote, quote.

However, in the context, I'd not want to guarantee that you wouldn't get:

sudo: unable to execute /bin/sh: Success

The odd error probably means that an exec*() family function call returned, but the value left in errno was zero. That shouldn't happen - but apparently did. What happens with:

sudo /bin/ls      # Or /usr/bin/ls if that's correct for your machine

When did you last check on the sudo installation? When did you last reboot? It looks like there is something screwball in the way sudo is (mis)handling the commands for you.

Is the directory you're working in NFS mounted? Root typically has rather minimal privileges in such directories. But the error should be of the EPERM (No permission) variety, not the 'success when failed' variety.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.