I am trying to use rsync to backup some data from one computer (PopOS! 21.04) to another (Rocky 8.4). But no matter which flags I use with rsync, file permissions and ownership never seem to be saved.
What I do, is run this command locally on PopOS:
sudo rsync -avz /home/user1/test/ root#192.168.10.11:/root/ttt/
And the result I get something link this:
[root#rocky_clone0 ~]# ls -ld ttt/
drwxrwxr-x. 2 user23 user23 32 Dec 17 2021 ttt/
[root#rocky_clone0 ~]# ls -l ttt/
total 8
-rw-rw-r--. 1 user23 user23 57 Dec 17 2021 test1
-rw-rw-r--. 1 user23 user23 29 Dec 17 2021 test2
So all the file ownership change to user23, which is the only regular user on Rocky. I don't understand how this happens, with rsync I am connecting to root on the remote host, but as the result files are copied as user23. Why isn't -a flag work properly in this case?
I have also tried these flags:
sudo rsync -avz --rsync-path="sudo -u user23 rsync -a" /home/user1/test root#192.168.10.11:/home/user23/rrr
This command couldn't copy to the root directory, so I had to change the remote destination to user23's home folder. But the result is the same.
If someone could explain to me what am I doing wrong, and how to backup files with rsync so that permissions and ownership stay the same as on the local computer I would very much appreciate it.
Have a look at how the (target)filesystem is mounted on the Rocky(target) system.
Some mounted filesystems (such as many FUSE mounts) do not support the classical unix permissions, and simply use the name of the user who mounted the filesystem as owner/group.
Any attempt to chown/chmod/etc (either by you or by rsync) will just silently be ignored, but appear to "succeed" (no errors reported).
I am trying to mount an nfs partition onto my Windows server 2012 which has cygwin running. I went through quite a few links, such as 'mount' while using Cygwin but none have helped. I want to mount over nfs 10.x.x.x/foo into a partition on Windows, either inside c:/bar or to /tmp/bar.
On cygwin, I used the command:
mount //10.x.x.x/foo /tmp/bar
The mount command goes through, and the output of mount is:
$ mount
//10.x.x.x/foo on /tmp/bar type unknown (binary,user)
C:/cygwin/bin on /usr/bin type ntfs (binary,auto)
C:/cygwin/lib on /usr/lib type ntfs (binary,auto)
C:/cygwin on / type ntfs (binary,auto)
C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto)
However, when I try to cd or ls into the directory, I do not see anything.
ls /tmp/bar
ls: cannot access /tmp/bar: No such file or directory
$ ls -la /tmp/
ls: cannot access /tmp/vdnet: No such file or directory
total 4
drwxrwxrwt+ 1 Administrator None 0 Apr 5 10:34 .
drwxr-xr-x+ 1 Administrator None 0 Jul 9 2015 ..
d?????????? ? ? ? ? ? bar
What is the right way to mount nfs partitions using cygwin?
Before read: I don't want to use any udev rule.
I need to change (programmatically) the permissions of some device. But first in order to underestand what I have to do (in code) I want to make the job using just chmod command.
So far, I've tried this:
root# ls -l /dev/sdb
root# brw-rw-rw- 1 root disk 8, 16 Apr 7 05:27 /dev/sdb
root# chmod 0600 /dev/sdb
root# ls -l /dev/sdb
root# brw------- 1 root disk 8, 16 Apr 7 05:27 /dev/sdb
as you can see, /dev/sdb has read and write permissions only for the owner (wich is root). But I'm still able to create new files and read files from my connected flash drive.
What I'm missing. How can I use chmod to prevent users to write to some device?
Can be done what I'm asking for?
Thank in advance.
I have mounted a external drive at:
# mkdir /mnt/external
and subsequently:
mkdir -p /mnt/external
mount /dev/sdb1 /mnt/external
Now only the root-user has access to write to these folders.
linux-wyee:/home/martin # dir /mnt
drwxr-xr-x 2 root root 4096 13. Dez 22:01 external
How to change this - how to change that all can write to the external drive. I need to change the permissions within the terminal.
chmod 777 /dev/sdb1 /mnt/external or something alike -
Try this first,
umount /dev/sdb1
chmod -R 0777 /mnt/external
then mount with
mount /dev/sdb1 /mnt/external
or try
chmod -R 0777 /mnt/external
chmod -R 777 /mnt/external
No need to specify the device. You chmod the directory recursively.
However, usually external drives are formatted with FAT32 or some sort of Windows-compatible file system, which does not have POSIX / UNIX permissions. So this step may be redundant.
How is your drive formatted?
Have you tried writing to it as a non-root user?
A solution posted on behalf of the OP.
Update:
linux-wyee:/mnt # chown martin:users /mnt/external
See the results: - it is obvious that it works ;-)
martin#linux-wyee:/> cd mnt
martin#linux-wyee:/mnt> ls -l
insgesamt 4
drwxr-xr-x 3 root root 4096 13. Dez 19:43 external
martin#linux-wyee:/mnt> su
Passwort:
linux-wyee:/mnt # ^C
linux-wyee:/mnt #
linux-wyee:/mnt # chown martin:users /mnt/external
linux-wyee:/mnt # cd mnt
bash: cd: mnt: Datei oder Verzeichnis nicht gefunden
linux-wyee:/mnt # ls -l
insgesamt 4
drwxr-xr-x 2 martin users 4096 13. Dez 22:01 external
linux-wyee:/mnt #
It works as you see now the user martin has got permissions.
chmod -R 0777 /mnt/external
This seems to be excessive for me. Everyone on this machine can execute whatever he wants from external disk. A wide opened door for hackers. They can e.g. save a picture using a web form, change execute bit and run it as a script on your system.
Perhaps, rw access for owner and group and r for others would be a better option.
I had a similar problem, but the solution for me was to use the uid and gid options of the CIFS filing system. (I had to use CIFS because apparently NFS doesn't allow access via username and password, which I needed.)
How can one detect being in a chroot jail without root privileges? Assume a standard BSD or Linux system. The best I came up with was to look at the inode value for "/" and to consider whether it is reasonably low, but I would like a more accurate method for detection.
[edit 20080916 142430 EST] Simply looking around the filesystem isn't sufficient, as it's not difficult to duplicate things like /boot and /dev to fool the jailed user.
[edit 20080916 142950 EST] For Linux systems, checking for unexpected values within /proc is reasonable, but what about systems that don't support /proc in the first place?
The inode for / will always be 2 if it's the root directory of an ext2/ext3/ext4 filesystem, but you may be chrooted inside a complete filesystem. If it's just chroot (and not some other virtualization), you could run mount and compare the mounted filesystems against what you see. Verify that every mount point has inode 2.
On Linux with root permissions, test if the root directory of the init process is your root directory. Although /proc/1/root is always a symbolic link to /, following it leads to the “master” root directory (assuming the init process is not chrooted, but that's hardly ever done). If /proc isn't mounted, you can bet you're in a chroot.
[ "$(stat -c %d:%i /)" != "$(stat -c %d:%i /proc/1/root/.)" ]
# With ash/bash/ksh/zsh
! [ -x /proc/1/root/. ] || [ /proc/1/root/. -ef / ]
This is more precise than looking at /proc/1/exe because that could be different outside a chroot if init has been upgraded since the last boot or if the chroot is on the main root filesystem and init is hard linked in it.
If you do not have root permissions, you can look at /proc/1/mountinfo and /proc/$$/mountinfo (briefly documented in filesystems/proc.txt in the Linux kernel documentation). This file is world-readable and contains a lot of information about each mount point in the process's view of the filesystem. The paths in that file are restricted by the chroot affecting the reader process, if any. If the process reading /proc/1/mountinfo is chrooted into a filesystem that's different from the global root (assuming pid 1's root is the global root), then no entry for / appears in /proc/1/mountinfo. If the process reading /proc/1/mountinfo is chrooted to a directory on the global root filesystem, then an entry for / appears in /proc/1/mountinfo, but with a different mount id. Incidentally, the root field ($4) indicates where the chroot is in its master filesystem. Again, this is specific to Linux.
[ "$(awk '$5=="/" {print $1}' </proc/1/mountinfo)" != "$(awk '$5=="/" {print $1}' </proc/$$/mountinfo)" ]
If you are not in a chroot and the root filesystem is ext2/ext3/ext4, the inode for / will always be 2. You may check that using
stat -c %i /
or
ls -id /
Interresting, but let's try to find path of chroot directory. Ask to stat on which device / is located:
stat -c %04D /
First byte is major of device and lest byte is minor. For example, 0802, means major 8, minor 1. If you check in /dev, you will see this device is /dev/sda2. If you are root you can directly create correspondong device in your chroot:
mknode /tmp/root_dev b 8 1
Now, let's find inode associated to our chroot. debugfs allows list contents of files using inode numbers. For exemple, ls -id / returned 923960:
sudo debugfs /tmp/root_dev -R 'ls <923960>'
923960 (12) . 915821 (32) .. 5636100 (12) var
5636319 (12) lib 5636322 (12) usr 5636345 (12) tmp
5636346 (12) sys 5636347 (12) sbin 5636348 (12) run
5636349 (12) root 5636350 (12) proc 5636351 (12) mnt
5636352 (12) home 5636353 (12) dev 5636354 (12) boot
5636355 (12) bin 5636356 (12) etc 5638152 (16) selinux
5769366 (12) srv 5769367 (12) opt 5769375 (3832) media
Interesting information is inode of .. entry: 915821. I can ask its content:
sudo debugfs /tmp/root_dev -R 'ls <915821>'
915821 (12) . 2 (12) .. 923960 (20) debian-jail
923961 (4052) other-jail
Directory called debian-jail has inode 923960. So last component of my chroot dir is debian-jail. Let's see parent directory (inode 2) now:
sudo debugfs /tmp/root_dev -R 'ls <2>'
2 (12) . 2 (12) .. 11 (20) lost+found 1046529 (12) home
130817 (12) etc 784897 (16) media 3603 (20) initrd.img
261633 (12) var 654081 (12) usr 392449 (12) sys 392450 (12) lib
784898 (12) root 915715 (12) sbin 1046530 (12) tmp
1046531 (12) bin 784899 (12) dev 392451 (12) mnt
915716 (12) run 12 (12) proc 1046532 (12) boot 13 (16) lib64
784945 (12) srv 915821 (12) opt 3604 (3796) vmlinuz
Directory called opt has inode 915821 and inode 2 is root of filesystem. So my chroot directory is /opt/debian-jail. Sure, /dev/sda1 may be mounted on another filesystem. You need to check that (use lsof or directly picking information /proc).
Preventing stuff like that is the whole point. If it's your code that's supposed to run in the chroot, have it set a flag on startup. If you're hacking, hack: check for several common things in known locations, count the files in /etc, something in /dev.
On BSD systems (check with uname -a), proc should always be present. Check if the dev/inode pair of /proc/1/exe (use stat on that path, it won't follow the symlink by text but by the underlying hook) matches /sbin/init.
Checking the root for inode #2 is also a good one.
On most other systems, a root user can find out much faster by attempting the fchdir root-breaking trick. If it goes anywhere you are in a chroot jail.
I guess it depends why you might be in a chroot, and whether any effort has gone into disguising it.
I'd check /proc, these files are automatically generated system information files. The kernel will populate these in the root filesystem, but it's possible that they don't exist in the chroot filesystem.
If the root filesystem's /proc has been bound to /proc in the chroot, then it is likely that there are some discrepancies between that information and the chroot environment. Check /proc/mounts for example.
Similrarly, check /sys.
I wanted the same information for a jail running on FreeBSD (as Ansible doesn't seem to detect this scenario).
On the FreeNAS distribution of FreeBSD 11, /proc is not mounted on the host, but it is within the jail. Whether this is also true on regular FreeBSD I don't know for sure, but procfs: Gone But Not Forgotten seems to suggest it is. Either way, you probably wouldn't want to try mounting it just to detect jail status and therefore I'm not certain it can be used as a reliable predictor of being within a jail.
I also ruled out using stat on / as certainly on FreeNAS all jails are given their own file system (i.e. a ZFS dataset) and therefore the / node on the host and in the jail both have inode 4. I expect this is common on FreeBSD 11 in general.
So the approach I settled on was using procstat on pid 0.
[root#host ~]# procstat 0
PID PPID PGID SID TSID THR LOGIN WCHAN EMUL COMM
0 0 0 0 0 1234 - swapin - kernel
[root#host ~]# echo $?
0
[root#host ~]# jexec guest tcsh
root#guest:/ # procstat 0
procstat: sysctl(kern.proc): No such process
procstat: procstat_getprocs()
root#guest:/ # echo $?
1
I am making an assumption here that pid 0 will always be the kernel on the host, and there won't be a pid 0 inside the jail.
If you entered the chroot with schroot, then you can check the value of $debian_chroot.