I'm facing #subj . If I try to create a file/dir in my home directory it gets created as root:daemon instead of user:staff. I found this behaviour only for one directory ( all the other dirs aren't affected).
It used to create files properly before and now it sets root:daemon with 644.
I can't see any guid or sticky bits, etc.
What do I miss?
$ whoami
user
$ pwd
/home/user
$ touch 1
$ ll 1
-rw-r--r-- 1 root daemon 0 Jul 31 09:50 1
$ ls -ld /home/user/
drwxr-xr-x 13 user staff 4096 Jul 31 09:50 /home/user/
$ ls -ld /home/
drwxr-xr-x 5778 root staff 450560 Jul 31 08:21 /home/
$ umask
0022
I might be due to file access control set to root:daemon. If you run
getfacl /home/user
it should tell you if that was the problem. If yes, then you can set per-folder with the command setfacl with the parameters you prefer.
Another cause that comes to my mind is if that is a mountpoint masked with those particular user and group; you can check that with cat /etc/fstab.
Related
I have a Dropbox folder on one computer with all the original modification dates. Recently, after transferring my data onto another computer, due to a .DS_Store issue, some of the folder's "Date Modified" dates were changed to today. I am trying to write a script that would take the original modification date of a folder, and then be able to find the corresponding folder in my new computer, and change it using touch. The idea is to use stat and touch -mt to do this. Does anyone have any suggestions or better thoughts? Thanks.
Use one folder as the reference for another with --reference=SOURCE:
$ cd "$(mktemp --directory)"
$ touch -m -t 200112311259 ./first
$ touch -m -t 200201010000 ./second
$ ls -l | sed "s/${USER}/user/g"
total 0
-rw-r--r-- 1 user user 0 Dec 31 2001 first
-rw-r--r-- 1 user user 0 Jan 1 2002 second
$ touch -m --reference=./first ./second
$ ls -l | sed "s/${USER}/user/g"
total 0
-rw-r--r-- 1 user user 0 Dec 31 2001 first
-rw-r--r-- 1 user user 0 Dec 31 2001 second
There's an odd behaviour when using relative paths. For example:
$ cd /Users
$ ls -l ../bin
ls: ../bin: No such file or directory
$ ls -l /bin
-r-xr-xr-x 1 root wheel 623344 31 May 08:33 bash
-rwxr-xr-x 1 root wheel 36768 31 May 08:33 cat
...
But the following works fine:
$ cd /dev
$ ls -l ../bin
-r-xr-xr-x 1 root wheel 623344 31 May 08:33 bash
-rwxr-xr-x 1 root wheel 36768 31 May 08:33 cat
...
Some other directories do not return the No such file or directory message, but they act as if there was nothing there. For example:
$ cd /Users
$ ls -l ../dev
$
returns nothing, and back to the prompt. The following, however, works fine:
$ cd /bin
$ ls -l ../dev
crw------- 1 root wheel 19, 1 11 Jun 16:54 afsc_type5
crw------- 1 root wheel 10, 0 11 Jun 16:54 auditpipe
crw-r--r-- 1 root wheel 9, 3 11 Jun 16:54 auditsessions
...
I could not find anything on the release notes. The WWDC2019 session 710 (What's New in Apple File Systems) also does not mention anything.
I think it might be related to the new separation of directories into a read-only and a read-write volumes. But still, it should work.
I found this to be specially problematic when using npm link, which links to /usr/local/lib/node_modules/... but expressed as a relative path from the destination package. After linking I have to manually change the link from relative to absolute. An ugly hack that may have some unforeseen consequences.
Anybody any clues?
The issue has been resolved with in Catalina beta 4.
I was looking for a way to cp a file and mod its perms to 400 at the same time... after some testing in the public_html folder...
public_html >> ls -lah
-rw-r--r-- 1 user user 0 Feb 27 14:21 a.txt
public_html >> cp a.txt{,.bak}
-rw-r--r-- 1 user user 0 Feb 27 14:21 a.txt
-rw-r--r-- 1 root root 0 Feb 27 14:23 a.txt.bak
perms are still the same (644) and although the file is owned by root, it is still readable via public_html
public_html >> cp a.txt{,.bak} && chmod 400 a.txt.bak
-rw-r--r-- 1 user user 653 Feb 27 14:26 a.txt
-r-------- 1 root root 653 Feb 27 14:30 a.txt.bak
this works but looking for something for a set newbs to use
awk/sed command possibly?
dont think I'm missing a cp flag that could modify the perms, wasn't seeing anything and don't think there are but wanted to pick the collective brain
thanks...
install(1) can both copy files and create directories, and set their permissions at the same time.
install -m 0400 foo bar/
What does the command cp $1/. $2 do? I know cp is used for copying from source(stored in variable $1) to destination(stored in variable $2). I am just confused with the /. used along with the variable. Can someone please help me understand this?
The command:
$ cp -R $1/. $2
copies contents of directory pointed by $1 to the directory $2.
Without -R switch this command would fail both when $1 is a file or directory.
In general, . points to the current directory. You can see that by comparing inode's shown by ls:
$ mkdir test
$ ls -ali
9525121 drwxr-xr-x 3 IU wheel 102 23 mar 12:31 .
771046 drwxrwxrwt 21 root wheel 714 23 mar 12:30 ..
9525312 drwxr-xr-x 2 IU wheel 68 23 mar 12:31 test
$ cd test
$ ls -ali
9525312 drwxr-xr-x 2 IU wheel 68 23 mar 12:31 .
9525121 drwxr-xr-x 3 IU wheel 102 23 mar 12:31 ..
Note that inode 9525312 points to test when viewed from the parent directory, and points to . when viewed from inside the test directory.
This must be really simple to do but have completely drawn a blank. I can see the permission of files by using ls -la which can give something like:
-rwxr-xr-x 1 james staff 68 8 Feb 13:33 basic.sh*
-rw-r--r-- 1 james staff 68 8 Feb 13:33 otherFile.sh*
How do I translate that into a number for use with chmod like chmod 755 otherFile.sh (with out doing the manual conversion).
stat -f "%Lp" [filename] works for me in OS X 10.8.
You should be able to use the stat command instead of ls. From looking at the manpage, this should work to get the file permissions:
for f in dir/*
do
perms=$(stat -f '0%Hp%Mp%Lp' $f)
echo "$f has permissions $perms"
done
(although I am not at my Mac at the moment and therefore cannot test it).