Running chmod 640 filea.txt as a regular user doesn't update filea.txt's permission. What might be a reason why chmod cannot modify the permissions? (Choose two.)
A.
filea.txt is owned by another user and a regular user cannot change the permissions of another user's file.
B.
filea.txt is a symbolic link whose permissions are a fixed value which cannot be charged.
C.
filea.txt has the sticky bit set and a regular user cannot remove this permission.
D.
filea.txt is a hard link whose permissions are inherited from the target and cannot be set directly.
E.
filea.txt has the SetUID bit set which imposes the restriction that only the root user can make changes to the file.
you can change the permissions on a hard link file without issues due it will be change the permissions in the original source too. You cannot change the permissions on symbolic inks due all is under 777
A Sticky bit is a permission bit that is set on a file or a directory that lets only the owner of
the file/directory or the root user to delete or rename the file. No other user is given
privileges to delete the file created by some other user.
Permissions on all hard links to the same data on disk are always identical. The same applies to attributes.
That means if you change the permissions/owner/attributes on one hard link, you will immediately see the changes
on all other hard links.
upvoted 2 times
...
Log in to ExamTopics
Sign in:
Community vote distribution
A (35%)
C (25%)
B (20%)
Other
Most Voted
A voting comment increases the vote count for the chosen answer by one.
Upvoting a comment with a selected answer will also increase the vote count towards that answer by one.
So if you see a comment that you already agree with, you can upvote it instead of posting a new comment.
MIU
Highly Voted 1 year, 7 months agoKiddyLitty
Most Recent 3 months agoLazylinux
3 months, 1 week agoSloop93
3 months, 2 weeks agotoni23
5 months, 1 week agominhng99
6 months, 2 weeks agoRobert12
1 year, 3 months agoMcLaba
1 year, 3 months agoRobert12
1 year, 3 months ago