#!/bin/sh
DOMAINLIST='*.io.domain.fun io.domain.fun *.*.domain.fun'
for i in $DOMAINLIST
do
mkdir $i
done
This shell code run out unreadable directory name
on my windows 10 . chinese character set
$ dir
_2X68P~X.A _E2MJ8~X.FUN
on my linux
# ls -alh .
total 32K
drwxr-xr-x 5 admin administrators 4.0K 2022-04-09 12:33 ./
drwxr-xr-x 6 admin administrators 4.0K 2022-04-09 11:06 ../
drwxr-xr-x 2 admin administrators 4.0K 2022-04-09 12:33 *.io.17lai.fun/
drwxr-xr-x 2 admin administrators 4.0K 2022-04-09 12:33 *.a/
maybe this is a character set problem?
it's probably not a good practice, but you can escape special characters with \ (e.g. mkdir '\*.a')
I know now . Win10 can not have * in file or dir name!
Related
I'm not using SELinux, and still I can't get the apache user to create files in my cache storage directory. Can this work without using chown to change the user to the actual apache user?
[root#server live_storage]# getenforce
Disabled
[root#server live_storage]# su -s /bin/bash -c 'touch /home/admin/live_storage/c50d02d942c0a3d.cache' apache
touch: cannot touch ‘/home/admin/live_storage/c50d02d942c0a3d.cache’:
Permission denied
[root#server admin]# ls -lsa
total 84
4 drwx------. 10 admin admin 4096 24 mei 10:32 .
4 drwxr-xr-x. 3 root root 4096 9 mei 11:12 ..
4 drwxrwxrwx 3 admin admin 4096 24 mei 10:33 live_storage
[admin#server live_storage]$ touch '/home/admin/live_storage/c50d02d942c0a3d.cache'
[admin#server live_storage]$ ls '/home/admin/live_storage/c50d02d942c0a3d.cache'
/home/admin/live_storage/c50d02d942c0a3d.cache
Figured it out. Apache didn't have execute rights on the /home/admin directory. chmod +x /home/admin fixed the problem
I am very new to linux and am using putty and pscp to move files to a live hosted directory. I would like to rename my recently uploaded dist folder to its actual project name using mv but get a permission denied error. What is the safest and most reasonable way to arrange these files so I can rename them?
lawton#lawtonb:/var/www/html$ ls -la
total 268
drwxr-xr-x 4 root root 4096 Aug 30 16:42 .
drwxr-xr-x 3 root root 4096 Aug 18 23:05 ..
-rw-rw-r-- 1 lawton lawton 253276 Aug 27 18:06 bundle.js
drwxr-xr-x 2 root root 4096 Aug 30 16:42 dist
-rw-r--r-- 1 root root 17 Aug 18 23:24 info.php
drwxr-xr-x 2 root root 4096 Aug 27 18:59 react-youtube
lawton#lawtonb:/var/www/html$ mv dist BTC_Sorter
mv: cannot move 'dist' to 'BTC_Sorter': Permission denied
If this is a one-time rename, your best course of action would be to run mv with sudo, like this:
sudo mv dist BTC_Sorter
If, however, you'd like to have permissions for your user or group, you should do some reading about chown (The link belongs to the Arch Linux wiki, but should be useful regardless of your distro).
In your particular case, the directory dist is owned both by the user and the group root, hence why you'd need to use sudo, chown or simply the root account.
You are not the owner of the file, you need execute the command with sudo
sudo mv src dest
I am currently creating an application that requires separate users running duplicate programs. They cannot run under root because of security reasons, so they are initiated by a Java app that I am working on, and I am starting them with runuser -l. However, I cannot cd into a directory, even though it is owned by the user, and the user has 770 permissions in the folder.
Here's what I'm running:
runuser -l lp1 -c 'java \-jar /root/Desktop/workspace/LitePanel/servers/server1/server.jar \-Xms1024M nogui'
And the output of this is:
runuser: warning: cannot change directory to /root/Desktop/workspace/LitePanel/bin/servers/server1/: Permission denied
Here's an ls -all:
drwxr-xr-x. 3 root root 4096 Jan 30 14:03 .
drwxr-xr-x. 7 root root 4096 Jan 30 14:02 ..
drwxrwx---. 2 lp1 lp1 4096 Jan 31 03:07 server1
Inside the directory:
drwxrwx---. 2 lp1 lp1 4096 Jan 31 03:07 .
drwxr-xr-x. 3 root root 4096 Jan 30 14:03 ..
-rwxrwx---. 1 lp1 lp1 9170551 Jan 31 03:07 server.jar
And here's /etc/passwd:
lp1:x:501:501::/root/Desktop/workspace/LitePanel/bin/servers/server1/:/bin/false
Anyone know why this is happening? It looks like the user has the necessary permissions to do this.
You have said that the directory itself has permissions 770 and is owned by the user, but what about its parents? I believe the cd command will need at least read access (and possibly execute) on the parent directories.
I have this old Perl script. This script is working from cron on CentOS 6.4. It creates a temporary directory and is trying to unzip files there.
This is a piece of code:
$lg->li("Creating Directory... \n\t$unzip_dir");
mkdir ($unzip_dir, 0777) or my_die("mkdir $unzip_dir failed") unless (-e $unzip_dir && -d $unzip_dir);
However after execution the directory has weird permissions:
drwxrwsr-x 42 buser agroup 12K Dec 30 09:18 .
drwxrwsr-x 4 buser agroup 4.0K Apr 6 2012 ..
drw-rwSr-- 2 auser agroup 4.0K Dec 28 11:51 tm_unpack_dir_1388412502.20184
The umask for user auser is a 0002.
Why the new directory has no execution permission? Any idea, how this can happen?
The weird permissions are caused by the setgid bit on the parent directory in combination with an unusual umask:
Look at the permissions of the parent directory, the first line:
drwxrwsr-x 42 buser agroup 12K Dec 30 09:18 .
drw-rwSr-- 2 auser agroup 4.0K Dec 28 11:51 tm_unpack_dir_1388412502.20184
Notice it has rwxrwsr-x which means that the setgid bit is set. The setgid bit on a directory causes new files in the directory to be created with the same group as the directory. New directories inherit the setgid bit from their parent.
A umask of 0113 will cause the strange permissions you're seeing. That is an unusual umask, the default is 0022. The umask is set in the environment executing the script, or directly in the script itself.
Don't worry about 0777 after mkdir in your script: mkdir $dir, 0777 means "create $dir without interfering with the present umask". 0777 is the default and can be safely omitted.
Try setting the umask directly in your script:
umask 0022;
$lg->li("Creating Directory... \n\t$unzip_dir");
mkdir ($unzip_dir) or my_die("mkdir $unzip_dir failed") unless (-e $unzip_dir && -d $unzip_dir);
should cause:
drwxrwsr-x 42 buser agroup 12K Dec 30 09:18 .
drwxr-sr-x 2 auser agroup 4.0K Dec 28 11:51 tm_unpack_dir_1388412502.20184
New directory permissions are rwxr-sr-x which is more normal. Notice that the setgid bit is still set because of the parent directory.
Oh, you might wonder why the setgid bit is sometimes lowercase 's' and sometimes uppercase 'S'. That depends on the executable bit. Lowercase s means the executable bit is set, uppercase means it's not set:
$ mkdir foo
$ ls -l
drwxr-xr-x 2 johan johan 4096 Dec 30 17:22 foo
$ chmod g+s foo
$ ls -l
drwxr-sr-x 2 johan johan 4096 Dec 30 17:22 foo
$ chmod g-x foo
$ ls -l
drwxr-Sr-x 2 johan johan 4096 Dec 30 17:22 foo
Your code looks correct to me.
Confirming on my system:
perl -e 'mkdir("foo", 0777);'
drwxr-xr-x 2 user user 512 Dec 30 10:48 foo
mkdir is affected by your umask. A funky umask can do funky things.
What does this yield for you?
perl -e 'printf("%04o\n", umask());'
I get this:
0022
Which is why my folder is created 0755 when I ask for 0777.
I've debugged script and found source of the problem.
The problem caused by tar.gz archive sent to us by one of our submitters. These tar files having directory without execution permission set. I have no idea how they achieve such result.
One more problem - the Gnu Tar have no key to prevent restoring files and directories permissions.
So after extracting archive with wrong permissions I have to recursively set right permissions on the all files and directories in the archive.
Thank you everybody.
It means that the setuid and setgid bits have been set.
The setuid (set user id) is a permission bit, that allows the users to exec a program with the permissions of its owner.
The setgid (set group id) is a bit that allows the user to exec a program with the permissions of the group owner.
http://linuxg.net/how-to-set-the-setuid-and-setgid-bit-for-files-in-linux-and-unix/
Does SCP have a problem setting file permissions or have I misconfiguration my server?
Use case:
There is a file on a server that I want to edit called "importantFile.txt". The file has owner and group of "master":
ls -l importantFile.txt:
-rw-rw-r-- 1 master master 7 Mar 18 08:11 importantFile.txt
I am called "slave" but luckily, I am in group "master" so I can edit the file as I see fit. However, I'm a lazy slave and can't be bothered to edit the file on the server, I'd prefer to edit the file on my local machine and SCP it to the server:
echo "bored slave info" > importantFile.txt
scp importantFile.txt slave#theServerAddress:/pathToFile/importantFile.txt
If I do this, the contents of the file on the server are uploaded fine and the timestamp of the file is updated but the permissions of the file don't change, the file is still owned by "master". This is a problem because if "slave" uploaded bad content, no one would know it was "slave" who caused the problem, "master" would look guilty.
Perhaps I have to set a umask? if so where? I tried .bash_profile without success and haven't found anything on Google about umask in /etc/ssh/sshd_config.
That's nothing special about scp - try logging on to the server as slave, and editing the file using your favourite text editor... You'll find the same behaviour occurs... Writing to a file does not make you the owner of the file.
Example:
as root
#cd /tmp
#mkdir fubar
#chgrp vboxusers fubar
#cd fubar/
#touch testfile
#chgrp vboxusers testfile
#chmod g+w . testfile
#ls -al
total 16
drwxrwxr-x 2 root vboxusers 4096 2009-03-19 10:30 .
drwxrwxrwt 15 root root 12288 2009-03-19 10:29 ..
-rw-rw-r-- 1 root vboxusers 0 2009-03-19 10:30 testfile
#echo foo > testfile
#ls -al
total 20
drwxrwxr-x 2 root vboxusers 4096 2009-03-19 10:30 .
drwxrwxrwt 15 root root 12288 2009-03-19 10:29 ..
-rw-rw-r-- 1 root vboxusers 4 2009-03-19 10:30 testfile
as user (in vboxusers group)
>cd /tmp/fubar
>ls -al
total 20
drwxrwxr-x 2 root vboxusers 4096 2009-03-19 10:30 .
drwxrwxrwt 15 root root 12288 2009-03-19 10:29 ..
-rw-rw-r-- 1 root vboxusers 4 2009-03-19 10:30 testfile
>echo bar >> testfile
>ls -al
total 20
drwxrwxr-x 2 root vboxusers 4096 2009-03-19 10:30 .
drwxrwxrwt 15 root root 12288 2009-03-19 10:29 ..
-rw-rw-r-- 1 root vboxusers 8 2009-03-19 10:31 testfile
>vim testfile
>ls -al
total 20
drwxrwxr-x 2 root vboxusers 4096 2009-03-19 10:31 .
drwxrwxrwt 15 root root 12288 2009-03-19 10:31 ..
-rw-rw-r-- 1 root vboxusers 12 2009-03-19 10:31 testfile
>cat testfile
foo
bar
baz
You have to delete the file to overwrite it. Wether you are able to do that depends on the directory's permissions and ownership. Hijacking ownership of an already existing file is not possible. The write permission you have is only applied on the contents of the file.
It seems you can configure how Emacs deals with this through the backup-by-copying-when-mismatch variable (see the Emacs Manual or type C-h-v backup-by-copying-when-mismatch in Emacs).
I actually filed a bug report about this, because I thought it was a bug in Tramp.
I had misunderstood the way files work, modifying file contents do not change ownership or group.
Why the confusion? EMACS - Whenever I was editing a file I was using Emacs and Emacs does change the owner and group to the current user. It does this because it makes a backup file at save time by moving the "filename" to "filename~" and creating a new file called "filename" - because it's a new file, it has the current users file permissions. I guess this is 1up to VI fans?