Can't make hard link for mounted host file in LXD container - hardlink

I configed a host directory as a disk device in an unprivileged LXD container, like /opt/app/var, and I created a backup directory on container self filesystem, like /backup.
I used rsync to backup /opt/app/var files to /backup with hard link, but I got Invalid cross-device link
lxd container device config:
devices:
var:
path: /opt/app/var
source: /opt/app/var
type: disk
in container:
$ cat /proc/mounts | grep opt
/dev/sda2 /opt/app/var ext4 rw,relatime,stripe=64,data=ordered 0 0
$ cat /proc/mounts | grep "/ "
/dev/sda2 / ext4 rw,relatime,stripe=64,data=ordered 0 0
$ cat /etc/fstab
LABEL=cloudimg-rootfs / ext4 defaults 0 0
I found the mountpoint made by lxd is from /dev/sda2, and the root partition mountpoint is from /dev/sda2 too, so it should be on a same device.

This is not a container issue.
You cannot create hard links across mount points, even when it’s the same device you (bind) mounted to different places in your FS hierarchy.
Try this on your system:
> cd /tmp/
> mkdir bar
> mkdir barm1
> mkdir barm2
> sudo mount --bind bar barm1
> sudo mount --bind bar barm2
> cd barm1
> echo foo > foo
> ll ../barm2/
drwxr-xr-x 2 user users 4096 Jul 13 15:56 ./
drwxrwxrwt. 19 root root 147456 Jul 13 15:57 ../
-rw-r--r-- 1 user users 4 Jul 13 15:56 foo
> cp --link foo ../barm2/foo2
cp: cannot create hard link '../barm2/foo2' to 'foo': Invalid cross-device link

Related

mkdir fails with directory exists after bash test if directory exists fails

I'm building a gitlab ci pipeline, and try to create a directory if it not exists.
Can anybody tell me what I'm doing wrong here?
$ if [ ! -d aws ]
$ then
$ mkdir aws
mkdir: cannot create directory ‘aws’: File exists
ERROR: Job failed: exit code 1
the relevant part of the gitlab-ci.yml
script:
- export
- ls -al
- if [ ! -d aws ]
- then
- mkdir aws
- fi
$ ls -al
total 128
drwxrwxrwx 16 root root 4096 Sep 17 12:07 .
drwxrwxrwx 6 root root 4096 Sep 17 12:07 ..
drwxrwxrwx 2 root root 4096 Sep 17 12:07 aws
I now just used mkdir -p and removed the test
you have something with aws name, which might be symbolic link, hard link, regular file, vs.
first delete or move that file to somewhere else then try again
you can try -e (returns true if file exists regardless of type).

bash script to edit file using sed doesn't persist reboot

I've written a script to migrate the boot directory from a microSD card to a USB drive. This is for a raspberry pi 4 project. As part of that script there are two files that get updated to remove the microSD reference and use UUID references of the USB thumb drive. The script is run as sudo. The script for updating the /boot/cmdline.txt and /etc/fstab files are as follows:
#!/bin/bash
fCMDLINE=/boot/cmdline.txt
fFSTAB=/etc/fstab
cat $fCMDLINE
sed -i -r -e 's/PARTUUID=([a-z]\S*)/PARTUUID='"$vPARTUUID"'/g' $fCMDLINE
cat $fCMDLINE
cat $fFSTAB
sed -i -r -e 's/PARTUUID=([a-z]\S*)/\/dev\/disk\/by-uuid\/'"$vUUID"'/g' $fFSTAB
cat $fFSTAB
After running the entire script the pre & post files are as follows:
CMDLINE FILE
#ORIGINAL
console=serial0,115200 console=tty1 root=PARTUUID=d9b3f436-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait quiet splash plymouth.ignore-serial-consoles
#UPDATED
console=serial0,115200 console=tty1 root=PARTUUID=0b1e4c33-0a73-4c26-aad2-03c1b5fd9266 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait quiet splash plymouth.ignore-serial-consoles
FSTAB FILE
#ORIGINAL
proc /proc proc defaults 0 0
PARTUUID=d9b3f436-01 /boot vfat defaults 0 2
PARTUUID=d9b3f436-02 / ext4 defaults,noatime 0 1
# a swapfile is not a swap partition, no line here
# use dphys-swapfile swap[on|off] for that
#UPDATED
proc /proc proc defaults 0 0
/dev/disk/by-uuid/5bee13fa-5c62-45b0-91ed-12c544d4b528 /boot vfat defaults 0 2
/dev/disk/by-uuid/5bee13fa-5c62-45b0-91ed-12c544d4b528 / ext4 defaults,noatime 0 1
# a swapfile is not a swap partition, no line here
# use dphys-swapfile swap[on|off] for that
The output for both files is correct and the sed command appears to have executed as expected on the replacement of the UUIDs. But, when I reboot the raspberry pi the original fstab file is the one that persists and it isn't updated. This only happens after the reboot. Prior to that the files are correct and everything is mounted as expected.
#After Reboot
pi#raspberrypi:~ $ sudo cat /etc/fstab
proc /proc proc defaults 0 0
PARTUUID=d9b3f436-01 /boot vfat defaults 0 2
PARTUUID=d9b3f436-02 / ext4 defaults,noatime 0 1
# a swapfile is not a swap partition, no line here
# use dphys-swapfile swap[on|off] for that
Not that it should matter, but here are the two files with permissions.
/boot/
-rwxr-xr-x 1 root root 191 Dec 8 01:01 cmdline.txt
/etc/
-rw-r--r-- 1 root root 314 Sep 26 01:31 fstab
The expected behavior would be for the fstab file to persist a reboot the same way the cmdline.txt file persists. There must be something obviously that I'm just missing. Any thoughts?
update...
I hadn't noticed before, but the two files above don't have the same date - - The 9/26 file is the original from the Buster (9/26) image and didn't update. Before reboot the file is:
-rw-r--r-- 1 root root 382 Dec 8 18:16 fstab
Baffling - it makes me think it's a hardware issue or a much deeper OS bug.

Copy of /dev/null has different behaviours depending on location

I tried mimicking the behaviour of /dev/null in another location, but some strange error occurs. I learned how to generate a special file similar to /dev/null in -bash: /dev/null: Permission denied.
When in some folder, e.g. home, the following occurs:
$ sudo mknod -m 666 null2 c 1 3
$ cat null2
cat: null2: Permission denied
On the other hand, when in /dev, no error occurs:
$ cd /dev
$ sudo mknod -m 666 null2 c 1 3
$ cat null2
I can reproduce the error on another xubuntu machine, but on a third machine the error does not occur. Any clue whats going on there?
Strangely, on any of these machines, permissions and major/minor are identical:
$ ls -la null2
crw-rw-rw- 1 root root 1, 3 Mär 4 17:42 null2
$ ls -la /dev/null
crw-rw-rw- 1 root root 1, 3 Mär 4 11:46 /dev/null
Also same when copying /dev/null
$ sudo cp -pR /dev/null null2 && cat null2
cat: null2: Permission denied
Is the nodev mount option set for the file system containing your home directory?
Specifying nodev forces the file system to not interpret block special devices (like the null2 special file you create with mknod).

Run shell script inside a container

I´m using lemonlatte / docker-webvirtmgr as base file, but the problem is that there are no ssh keys configured for the user www-data, so I wrote the following shell script:
#!/bin/sh
if [ ! -d "/var/local/webvirtmgr/nginxhome" ]; then
mkdir /var/local/webvirtmgr/nginxhome
chown -R www-data:www-data /var/local/webvirtmgr/nginxhome
usermod -d /var/local/webvirtmgr/nginxhome www-data
su - www-data -s /bin/bash -c "ssh-keygen -b 2048 -t rsa -f ~/.ssh/id_rsa -q -N ''"
su - www-data -s /bin/bash -c "touch /var/local/webvirtmgr/nginxhome/.ssh/config && echo -e 'StrictHostKeyChecking=no\nUserKnownHostsFile=/dev/null' >> /var/local/webvirtmgr/nginxhome/.ssh/config"
su - www-data -s /bin/bash -c "chmod 0600 ~/.ssh/config"
fi
After that I added the two statements to the dockerfile:
ADD setupssh.sh /webvirtmgr/setupssh.sh
RUN /bin/sh -c "/webvirtmgr/setupssh.sh"
I already tried CMD /webvirtmgr/setupssh.sh, RUN /webvirtmgr/setupssh.sh but with no success...
When I run the script inside the container by hand it is working fine.
What is wrong here?
greetings
UPDATE:
Here is the link to the repo of the maintainer: link
UPDATE 2:
The build of the dockerfile was successful and I put the statement between:
RUN apt-get -ys clean
<statements were here>
WORKDIR /
The directory /var/local/webvirtmgr is defined as a volume.
VOLUME /var/local/webvirtmgr
Therefore this directory is a mountpoint in the running container and what you have added to it gets overwritten.
You will have to use a different directory, then your script will work.
Here´s a Dockerfile to test it:
FROM lemonlatte/docker-webvirtmgr
RUN mkdir /var/local/webvirtmgr2
RUN touch /var/local/webvirtmgr2/t && touch /var/local/webvirtmgr/t
RUN ls -la //var/local/webvirtmgr
RUN ls -la /var/local/webvirtmgr2
Output:
Sending build context to Docker daemon 4.608 kB
Sending build context to Docker daemon
Step 0 : FROM lemonlatte/docker-webvirtmgr
---> 18e2839dffea
Step 1 : RUN mkdir /var/local/webvirtmgr2
---> Running in d7a1e897108e
---> cc029293525e
Removing intermediate container d7a1e897108e
Step 2 : RUN touch /var/local/webvirtmgr2/t && touch /var/local/webvirtmgr/t
---> Running in 1a1375651fa7
---> e314c2529d90
Removing intermediate container 1a1375651fa7
Step 3 : RUN ls -la //var/local/webvirtmgr
---> Running in 5228691c84f5
total 8
drwxr-xr-x 2 www-data www-data 4096 Jun 6 09:22 .
drwxr-xr-x 6 root root 4096 Jun 6 09:22 ..
---> ec4113936961
Removing intermediate container 5228691c84f5
Step 4 : RUN ls -la /var/local/webvirtmgr2
---> Running in a6d2a683391a
total 8
drwxr-xr-x 2 root root 4096 Jun 6 09:22 .
drwxr-xr-x 6 root root 4096 Jun 6 09:22 ..
-rw-r--r-- 1 root root 0 Jun 6 09:22 t
---> 3cb98c5c1baf
Removing intermediate container a6d2a683391a
Successfully built 3cb98c5c1baf

Gluster strange issue with shared mount point like seprate mount.

I have two nodes and for experiment i have install glusterfs and create volume and successfully mounted on own node, but if i create file in node1 it is not showing in node2, look like both behaving like they are separate.
node1
10.101.140.10:/nova-gluster-vol
2.0G 820M 1.2G 41% /mnt
node2
10.101.140.10:/nova-gluster-vol
2.0G 33M 2.0G 2% /mnt
volume info split brian
$ sudo gluster volume heal nova-gluster-vol info split-brain
Gathering Heal info on volume nova-gluster-vol has been successful
Brick 10.101.140.10:/brick1/sdb
Number of entries: 0
Brick 10.101.140.20:/brick1/sdb
Number of entries: 0
test
node1
$ echo "TEST" > /mnt/node1
$ ls -l /mnt/node1
-rw-r--r-- 1 root root 5 Oct 27 17:47 /mnt/node1
node2 (file isn't there, while they are shared mount)
$ ls -l /mnt/node1
ls: cannot access /mnt/node1: No such file or directory
What i am missing??
Iptable solved my problem
iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 49152 -j ACCEPT

Resources