search

MichaIng / DietPi

Lightweight justice for your single-board computer!
https://dietpi.com/
GNU General Public License v2.0
4.86k stars 496 forks source link

DietPi-Drive_Manager | Deny external drive/userdata mount to /home #3249

Open MartinDeppe opened 4 years ago

MartinDeppe commented 4 years ago

Details:

Steps to reproduce:

  1. Since I encountered already problems with my mysql installation, I didn't update the system since and from v6.22.3.
  2. Last time I updated to v6.22.3 I corrected above problem manually by copying the DB back to "/var/lib/mysql". I also looked for where it is configured on the dietpi system.

Expected behaviour:

Actual behaviour:

Extra details:

Additional logs:

Log file contents:
Job for mariadb.service failed because the control process exited with error code.
See "systemctl status mariadb.service" and "journalctl -xe" for details.
MichaIng commented 4 years ago

@MartinDeppe Many thanks for your report.

Indeed this issue was reported by times, sadly we could never replicate, hence not find out why this works fine in 99% of systems but fails in 1%.

Background

We symlink the MariaDB database location from default /var/lib/mysql to /mnt/dietpi_userdata/mysql. Since usually on SBCs the system is on SDcard, the default database location is on SDcard. Database writes are usually very regular and heavy, e.g. typical Nextcloud oc_filescache database table file is easily hundrets of MiB large and can be rewritten on every access, hence every tiny change to any Nextcloud file or meta data. These kind of heavy regular writes kill SDcards quickly, which is the most common issues for system crashes, data loss etc... So we put database dir to DietPi userdata by default, since this can be moved easily to an external drive, which can handle database I/O much more reliable and faster.

I found users running into MariaDB startup in very rare cases when the DietPi userdata were indeed moved to an external drive. Is this true in your case as well, and can you paste the following:

df -T # Only external userdata mount line required
ls -al /mnt/dietpi_userdata/mysql # To check permissions/ownership etc

I know that AppArmor rules can deny access through symlinks in general. Do you have either AppArmor or SELinux installed?

MartinDeppe commented 4 years ago

Hello MichaIng/DietPi,

man thanks for your reply. You guessed right, I am running it on an external (magnetic) Hard-Disk, so that the writes to the SD-Card are actually minimized to updates of the operating system or any other software.

I give you even some more information than you requested. I think that will help you even more:

root@pi30:~# df -T
Dateisystem    Typ      1K-Blöcke Benutzt Verfügbar Verw% Eingehängt auf
/dev/root      ext4     102687672 1898664 100772624    2% /
devtmpfs       devtmpfs    494908       0    494908    0% /dev
tmpfs          tmpfs       499516       0    499516    0% /dev/shm
tmpfs          tmpfs       499516   12876    486640    3% /run
tmpfs          tmpfs         5120       0      5120    0% /run/lock
tmpfs          tmpfs       499516       0    499516    0% /sys/fs/cgroup
/dev/sda4      ext4     848376672 9655296 795556500    2% /home
tmpfs          tmpfs        51200      16     51184    1% /var/log
tmpfs          tmpfs       499712       0    499712    0% /tmp
tmpfs          tmpfs        10240    1396      8844   14% /DietPi
/dev/mmcblk0p1 vfat         44220   24246     19974   55% /boot
tmpfs          tmpfs        99900       0     99900    0% /run/user/0
root@pi30:~# ls -al /mnt/dietpi_userdata/mysql
insgesamt 176184
drwxrwx--- 7 mysql  mysql      4096 Dez  3 15:02 .
drwxrwxr-x 9 dietpi dietpi     4096 Mai 14  2019 ..
-rwxrwx--- 1 mysql  mysql     16384 Dez  3 15:02 aria_log.00000001
-rwxrwx--- 1 mysql  mysql        52 Dez  3 15:02 aria_log_control
-rwxrwx--- 1 mysql  mysql         0 Mai  4  2019 debian-10.1.flag
-rwxrwx--- 1 mysql  mysql  79691776 Dez  3 15:02 ibdata1
-rwxrwx--- 1 mysql  mysql  50331648 Dez  3 15:02 ib_logfile0
-rwxrwx--- 1 mysql  mysql  50331648 Mai 13  2019 ib_logfile1
drwxrwx--- 2 mysql  mysql      4096 Mai 13  2019 mts
-rwxrwx--- 1 mysql  mysql         0 Apr 20  2019 multi-master.info
drwxrwx--- 2 mysql  mysql      4096 Mai  4  2019 mysql
drwxrwx--- 2 mysql  mysql     12288 Mai  6  2019 nextcloud
drwxrwx--- 2 mysql  mysql      4096 Mai  4  2019 performance_schema
drwx------ 2 mysql  mysql      4096 Dez  3 14:55 schutz_drk
root@pi30:~# ls -al /var/lib/mysql
insgesamt 176212
drwxrwx---  7 mysql mysql     4096 Dez  3 15:09 .
drwxr-xr-x 28 root  root      4096 Dez  2 04:07 ..
-rwxrwx---  1 mysql mysql    16384 Dez  3 15:02 aria_log.00000001
-rwxrwx---  1 mysql mysql       52 Dez  3 15:02 aria_log_control
-rwxrwx---  1 mysql mysql        0 Mai  4  2019 debian-10.1.flag
-rwxrwx---  1 mysql mysql 79691776 Dez  4 21:53 ibdata1
-rwxrwx---  1 mysql mysql 50331648 Dez  4 21:53 ib_logfile0
-rwxrwx---  1 mysql mysql 50331648 Mai 13  2019 ib_logfile1
drwxrwx---  2 mysql mysql     4096 Mai 13  2019 mts
-rwxrwx---  1 mysql mysql        0 Apr 20  2019 multi-master.info
drwxrwx---  2 mysql mysql     4096 Mai  4  2019 mysql
drwxrwx---  2 mysql mysql    12288 Mai  6  2019 nextcloud
drwxrwx---  2 mysql mysql     4096 Mai  4  2019 performance_schema
drwx------  2 mysql mysql     4096 Dez  3 17:24 schutz_drk
-rw-rw----  1 mysql mysql    24576 Dez  3 15:09 tc.log
root@pi30:~# lsblk -f
NAME        FSTYPE LABEL  UUID                                 MOUNTPOINT
sda
├─sda1      vfat          E889-F26F
├─sda2      swap          a95ada14-3f79-4964-adae-783ec691b76e [SWAP]
├─sda3      ext4          c2cfd4d0-e7fe-46ab-8cfa-f897342420e6 /
└─sda4      ext4          511dec91-70f9-46f2-9f54-285bccf75c2e /home
mmcblk0
├─mmcblk0p1 vfat   boot   9304-D9FD                            /boot
└─mmcblk0p2 ext4   rootfs 29075e46-f0d4-44e2-a9e7-55ac02d6e6cc
root@pi30:~#

Can I configure this behaviour into not using a symbolic link? I would highly appreciate, if it would be configurable via dietpi-config or so.

By the way, I needed to install apache2 (for nextcloud), which actually might be the reason for the problem, since it isn't integrated well enough as it seems. The hard thing for me to confront was, that by trying to install "phpmyadmin" the process removed my at that time current databases completely. It is running again, but I lost all configurations made since the last version I had.

It seems that neither AppArmor nor selinux are installed (obviously) and I never worked with AppArmor yet:

root@pi30:~# dpkg -l | egrep -i 'apparmor|selinux'
ii  libapparmor1:armhf              2.11.0-3+deb9u2              armhf        changehat AppArmor library
ii  libselinux1:armhf               2.6-3                        armhf        SELinux runtime shared libraries
ii  libsemanage-common              2.6-2                        all          Common files for SELinux policy management libraries
ii  libsemanage1:armhf              2.6-2                        armhf        SELinux policy management library
ii  libsepol1:armhf                 2.6-2                        armhf        SELinux library for manipulating binary security policies

When I installed DietPi on my Raspberry, I didn't get it to work by using a symlink to the new location. The effect was, that mariadb didn't start with a symlink, IIRC.

I hope that helps you and me Martin

Am 04.12.19 um 17:40 schrieb MichaIng:

@MartinDeppe https://github.com/MartinDeppe Many thanks for your report.

Indeed this issue was reported by times, sadly we could never replicate, hence not find out why this works fine in 99% of systems but fails in 1%.

    Background

We symlink the MariaDB database location from default |/var/lib/mysql| to |/mnt/dietpi_userdata/mysql|. Since usually on SBCs the system is on SDcard, the default database location is on SDcard. Database writes are usually very regular and heavy, e.g. typical Nextcloud oc_filescache database table file is easily hundrets of MiB large and can be rewritten on every access, hence every tiny change to any Nextcloud file or meta data. These kind of heavy regular writes kill SDcards quickly, which is the most common issues for system crashes, data loss etc... So we put database dir to DietPi userdata by default, since this can be moved easily to an external drive, which can handle database I/O much more reliable and faster.

I found users running into MariaDB startup in very rare cases when the DietPi userdata were indeed moved to an external drive. Is this true in your case as well, and can you paste the following:

|df -T # Only external userdata mount line required ls -al /mnt/dietpi_userdata/mysql # To check permissions/ownership etc |

I know that AppArmor rules can deny access through symlinks in general. Do you have either AppArmor or SELinux installed?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/MichaIng/DietPi/issues/3249?email_source=notifications&email_token=AN5R2PUFLK25Y6OD2CW22BTQW7MPVA5CNFSM4JTNGFG2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEF5UUTI#issuecomment-561728077, or unsubscribe https://github.com/notifications/unsubscribe-auth/AN5R2PSU24K7OA6NSVJPUJLQW7MPVANCNFSM4JTNGFGQ.

MichaIng commented 4 years ago

@MartinDeppe

/dev/sda4 ext4 848376672 9655296 795556500 2% /home

I think that is the issue.

2019-12-04 23:21:13 root@micha:/var/log# systemctl cat mariadb | grep ProtectHome
ProtectHome=true

Mount the external drive to /mnt/<something> instead, adjust the /mnt/dietpi_userdata symlink accordingly and MariaDB should start fine 🙂. Btw now that I see this, I remember this being the issue in the other case as well 😄.