Can anyone explain why sudo ls with a wildcard doesn't work?
Solution 1
One possibility is that you don't have permissions to access one or more of the directories in that path (/sites/servers/server_instance/logs
). The wildcard expansion is carried out by your shell, and then the expanded paths are passed to the sudo
command.
If your user doesn't have permissions, expansion wouldn't work in the first command. It would be run as-is (ls -ltr /sites/servers/server_instance/logs/access*
), and there isn't a file literally named access*
). If abc
does have the required permissions for all the directories in the path, the second command, which didn't have any wildcards, would be untouched by your shell, and it would work fine.
$ sudo namei -lx foo/bar/baz
f: foo/bar/baz
drwxr-xr-x muru muru foo
drwx------ test test bar
drwxr-xr-x muru muru baz
$ sudo ls foo/bar/b*
ls: cannot access 'foo/bar/b*': No such file or directory
$ sudo -u test ls foo/bar/
baz
Solution 2
You may have globbing disabled.
Look for something like set -f
or set -o noglob
before those lines in the script, or if in an interactive shell run echo $-
; if there's an f
in the output, globbing is disabled:
$ echo $-
fhimBH
To fix that, remove set -f
or set -o noglob
from the script, or if in an interactive shell run set +f
or set +o noglob
:
$ set -f
$ echo $-
fhimBH
$ ls access*
ls: cannot access access*: No such file or directory
$ set +f
$ echo $-
himBH
$ ls access*
access
Related videos on Youtube
Faisal
Updated on September 18, 2022Comments
-
Faisal almost 2 years
$ sudo -iu abc ls -ltr /sites/servers/server_instance/logs/access* ls: cannot access /sites/servers/server_instance/logs/access*: No such file or directory $ sudo -iu abc ls -ltr /sites/servers/server_instance/logs/ total 594812 -rwxrwxrwx 1 abc abc 45 Mar 21 12:42 old.log -rwxrwxrwx 1 abc abc 304537970 Mar 24 12:45 console.log -rwxrwxrwx 1 abc abc 304537970 Mar 24 13:20 access_nginx.log
Can anyone explain why this happens? I am stuck on a script due to this.
-
Faisal about 8 yearsYeah, i as my individual user don't have access to that path. In script i am going as my user (via ssh) and running that command via production user. Is there any work around for this ? (One point to noted is i don't have to give password for switching user)
-
kos about 8 years@Faisal How about running the script as the target user (
sudo -u abc /path/to/script
)? In that case globbing shouldn't fail. In any case muru suggested the path issue in his answer, not me. You should consider accepting his answer (askubuntu.com/help/accepted-answer). -
Faisal about 8 yearsthanks Muru , your opinion was correct , i changed the permission to 755 and now its working fine.
-
Marc van Leeuwen about 8 years@Faisal: I would think that changing permissions is not the proper remedy, though it reveals that the diagnosis is correct. The proper remedy would seem to be to not do globbing while preparing the sudo command, but rather suppress it here (by quoting the path argument), passing the argument as-is to the
ls
command that can then (when the identity change fromsu
has taken effect) do the globbing. -
muru about 8 years@MarcvanLeeuwen
ls
doesn't do any globbing. -
Stig Hemmer about 8 yearsYou can make globbing happen in the sudo environment by adding
sh -c
to the command line. -
clem steredenn about 8 years@Faisal if that answers your question, consider accepting it...
-
Faisal about 8 yearsIt worked fine for me.. Thanks for answering..
-
Faisal about 8 yearsActually i am running that on remote machine via script so -i would be needed. Thanks to you as well for answering.
-
Noumenon over 4 years@StigHemmer Thanks a lot -- I wanted a workaround, not just an answer why it doesn't work. Just to spell out your solution, it's
sudo bash -c "ls -d /foo/bar/*"
. -
Bob Stein almost 3 years
sudo sh -c "ls --color=always foo/bar/" | less -R
for a colorized list that doesn't disrupt the scrollback buffer. Thanks @Noumenon and @StigHemmer.