I'm having issues with getting Apache working with my virtualhosts, and I've narrowed it down to the fact that I'm adding manually-created virtual hosts (vs. the others which are created by a python script). When I run:
ls -l
I get this:
-rw-r--r-- 1 root wheel 772 May 10 17:53 host1.com
-rw-r--r-- 1 root wheel 766 May 10 17:53 host2.com
-rw-r--r--# 1 myname wheel 914 Mar 28 14:24 host3.com
-rw-r--r-- 1 root wheel 3897 May 10 17:53 host4.com
-rw-r--r-- 1 root wheel 5240 May 10 17:53 host5.com
-rw-r--r-- 1 root wheel 4037 May 10 17:53 host6.com
I'm not sure what the "#" refers to, but that manually-created file my username as the owner instead of root. When I view the file info in OS X (Finder), I see that permissions for most of the files show "system" has Read & Write access, but my manually-created vh file shows that I (my username) has Read & Write access.
Can someone tell me how to set the permissions for "system" or "root" in Terminal? I do have superuser access.
You can change the ownership of a file in terminal by using
sudo chown owner:group filepath
Or in your case
sudo chown root:wheel filepath
Additionally, you can change the permissions of a file by using chmod
The # indicates that there are extended attributes. You can use the command xattr to have a look at them
You can set the owner with chown
Related
Using:
podman version 4.2.0
AlmaLinux 8.7
I've created an image based on redhat/ubi8 with the following Dockerfile:
FROM docker.io/redhat/ubi8
RUN dnf install -y gcc-c++ cmake python39 openssh git
RUN useradd -ms /bin/bash foobar -g users
USER foobar
WORKDIR /home/foobar/
RUN mkdir -p .ssh
$ docker build -t mount_test_image .
I run the image from a directory that contains a directory ssh, and I want to mount that directory to /home/foobar/.ssh with ownership of foobar.users
$ ls -l
-rw-r--r--. 1 host_user users 269 Dec 7 09:10 Dockerfile
drwxrwxr-x. 2 host_user users 18 Dec 2 10:41 ssh
docker run -it -d --rm --mount type=bind,src=ssh,target=/home/foobar/.ssh --name=mount_test mount_test_image
However when I enter the container via
docker exec -it mount_test '/bin/sh'
The home directory looks like this:
drwx------. 1 foobar users 18 Dec 7 17:10 .
drwxr-xr-x. 1 root root 21 Dec 7 17:10 ..
-rw-r--r--. 1 foobar users 18 Jun 20 11:31 .bash_logout
-rw-r--r--. 1 foobar users 141 Jun 20 11:31 .bash_profile
-rw-r--r--. 1 foobar users 376 Jun 20 11:31 .bashrc
drwxrwxr-x. 2 root root 18 Dec 2 18:41 .ssh
I obviously get a "permission denied" when trying to access that directory.
sh-4.4$ ls /home/foobar/.ssh
ls: cannot open directory '/home/foobar/.ssh': Permission denied
I tried changing the ownership of the directory on the host to match the uid of the container user, but then it just looks like this:
drwxrwxr-x. 2 nobody root 18 Dec 2 18:41 .ssh
My host user uid:gid is 501:100 and the container user is 1000:100. Right now I'm just trying to generate an ssh key to upload to bitbucket, but this seems like a simple feature a container should be have. All the tutorials and examples just stop after the --mount command instruction and say "there ya go!". What good is the mount point if you can't read/write it?
EDIT:
I tried on Archlinux using docker instead of podman and it works like one would expect with both -v and --mount. The owner of the mounted directory in the container matches the uid and gid of the host. Is this then a bug in podman or is it just done differently?
You are using a non-root user (foobar) in a rootless container. You must use --userns=keep-id for the container user to see the mounted volumes.
https://github.com/containers/podman/blob/main/docs/tutorials/rootless_tutorial.md#using-volumes
I have a proxmox server so under debian, and I want to mount a remote directory from my Nas Synologies to make backups.
I normally use ssh mounts without any problem.
But this time I have an error that I have never encountered, I can create files, but not delete them.
I find this very strange and I don't see where this can come from
root#proxmox:/mnt/# sshfs user#192.168.0.1:home/data /mnt/dist-folder/ -o reconnect,
ServerAliveInterval=60,ServerAliveCountMax=30,allow_other,
default_permissions,uid=0,gid=0,umask=007
root#proxmox:/mnt# cd dist-folder/
root#proxmox:/mnt/dist-folder# touch aa.txt
root#proxmox:/mnt/dist-folder# ls -la
total 12
drwxrwx--- 1 root root 114 Mar 13 09:53 .
drwxr-xr-x 7 root root 4096 Mar 13 09:37 ..
-rwxrwx--- 1 root root 0 Mar 13 09:53 aa.txt
root#proxmox:/mnt/dist-folder# rm aa.txt
rm: cannot remove 'aa.txt': Permission denied
With uid=0,gid=0 for root user and group
Thanks
This is finally a problem specific to synology.
For the assembly of the file it is absolutely necessary to respect the path by starting with
/homes/<user>home/
So it's give
sshfs user#192.168.0.1:/homes/proxmox/home/data /mnt/dist-folder/
And it's works fine !
It's not the first time that I have an abnormal configuration for this synology tool... AGrrrr
I'm super-confused about file permissions in MSYS. Things started to go wrong after my company transferred my windows-user to a different domain. Now I have this concrete problem:
I want to compile cpputest. I unzipped it using windows, started an msys console and owner and group look like this:
M.Grunwald#GNA ~/Projects/cpputest-3.8
$ ls -la
total 1956
drwxrwx---+ 1 M.Grunwald Domain Users 0 16. Nov 10:21 .
drwxrwx---+ 1 M.Grunwald COMPANY_DE+Domain Users 0 16. Nov 10:21 ..
-rwxrwx---+ 1 M.Grunwald Domain Users 11030 2. Mai 2016 .cproject
-rwxrwx---+ 1 M.Grunwald Domain Users 228 2. Mai 2016 .gitattributes
-rwxrwx---+ 1 M.Grunwald Domain Users 746 25. Mai 12:32 .gitignore
and so on.
When I start autogen.sh, this happens:
$ ./autogen.sh
autom4te-2.69: cannot open autom4te.cache/requests: Permission denied
$ ls -lad autom4te.cache/
drwxr-xr-x+ 1 M.Grunwald Domain Users 0 Nov 16 10:23 autom4te.cache/
So the directory belongs to me, I have all permissions, but I'm not allowed to touch anything in it:
$ touch autom4te.cache/requests
touch: cannot touch 'autom4te.cache/requests': Permission denied
It seems that "I" am not really M.Grunwald and don't belong to "Domain Users", neither... On the other hand:
$ echo "UID: $UID GID: $GROUPS"
UID: 1117609 GID: 1049089
$ ls -lnad autom4te.cache/
drwxr-xr-x+ 1 1117609 1049089 0 Nov 16 10:23 autom4te.cache/
So the IDs match. umask is 0000, too and still group and others don't have write permission. If I want to change this:
$ chmod g+w autom4te.cache
chmod: changing permissions of 'autom4te.cache': Permission denied
Now I'm completely confused and blocked on many similar tasks (always permission problems, cpputest is just one example). Can you help me?
The problem was solved after I re-ran the mingw installer.
I need to change permissions of files in my /media/MAVEN/Projects
MAVEN is my windows disk partition.
The permissions on the Projects folder are:
:/media/MAVEN/Projects$ ls -la
\total 340
drwxrwxrwx 1 root root 12288 Oct 6 21:31 .
drwxrwxrwx 1 root root 32768 Oct 9 06:32 ..
all the projects are set to drwxrwxrwx
I need to change them to 755 so I tried:
~$ sudo chmod 755 -R /media/MAVEN/Projects
But I get errors: ...Read-only file system
The result of ls -la /media/MAVEN/Projects remains the same.
Help me resolve this.
Problem solved. I found out that I was using a package that was mounting my disk as read only. Its called pysdm I disabled that feature.
I have a django application which should read and write to a crontab. However if I create the file with this:
sudo su www-data
crontab -e
I can see that:
# ls -la
total 12
drwx-wx--T 2 root crontab 4096 Aug 13 16:28 .
drwxr-xr-x 5 root root 4096 May 1 2012 ..
-rw------- 1 www-data crontab 202 Aug 13 16:28 www-data
However the file is still not readable and writeable by django. If I switch with sudo to www-data user I can't edit the file. How to setup the permissions properly?
You are not allowed to read that dir, for good reason.
You can however:
Read the file with crontab -l
Replace the crontab with crontab /path/to/file/which/will/replace/it.
So a workable solution would be:
Store current crontab -l in some tempfile.
Do you modifications on that tempfile
Install that tempfile with crontab /path/to/tempfile
The reason is in man cron:
Users are not allowed to edit the files under that directory
directly to ensure that only users allowed by the system to run periodic tasks can add them, and only syntactically correct crontabs will be written
there. This is enforced by having the directory writable only by the crontab group and configuring crontab command with the setgid bid set for that
specific group.