I have done new install on Samsung 128 GB SD card - moved /dietpi/userdata to /home/john. MariaDb does not start with error:
root@Odroid:~# service mariadb status
● mariadb.service - MariaDB 10.1.37 database server
Loaded: loaded (/lib/systemd/system/mariadb.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Wed 2019-04-10 23:01:41 NZST; 34s ago
Docs: man:mysqld(8)
https://mariadb.com/kb/en/library/systemd/
Process: 18217 ExecStart=/usr/sbin/mysqld $MYSQLD_OPTS $_WSREP_NEW_CLUSTER $_WSREP_START_POSITION (code=exited, status=1/FAILURE)
Process: 18140 ExecStartPre=/bin/sh -c [ ! -e /usr/bin/galera_recovery ] && VAR= || VAR=`/usr/bin/galera_recovery`; [ $? -eq 0 ] && systemctl set-environment _WSREP_START_POSITION=$VAR || exit 1 (code=exited, status=0/SUCCESS)
Process: 18135 ExecStartPre=/bin/sh -c systemctl unset-environment _WSREP_START_POSITION (code=exited, status=0/SUCCESS)
Process: 18133 ExecStartPre=/usr/bin/install -m 755 -o mysql -g root -d /var/run/mysqld (code=exited, status=0/SUCCESS)
Main PID: 18217 (code=exited, status=1/FAILURE)
Status: "MariaDB server is down"
Apr 10 23:01:40 Odroid systemd[1]: Starting MariaDB 10.1.37 database server...
Apr 10 23:01:41 Odroid mysqld[18217]: 2019-04-10 23:01:41 3069782832 [Note] /usr/sbin/mysqld (mysqld 10.1.37-MariaDB-0+deb9u1) starting as process 18217 ...
Apr 10 23:01:41 Odroid mysqld[18217]: 2019-04-10 23:01:41 3069782832 [Warning] Can't create test file /var/lib/mysql/Odroid.lower-test
Apr 10 23:01:41 Odroid systemd[1]: mariadb.service: Main process exited, code=exited, status=1/FAILURE
Apr 10 23:01:41 Odroid systemd[1]: Failed to start MariaDB 10.1.37 database server.
Apr 10 23:01:41 Odroid systemd[1]: mariadb.service: Unit entered failed state.
Apr 10 23:01:41 Odroid systemd[1]: mariadb.service: Failed with result 'exit-code'.
User mysql has write access on /var/lib/mysql
Any help apprereciated.
John
[Solved] New install 6.22 Odroid xu4 MariaDB error Topic is solved
Re: New install 6.22 Odroid xu4 MariaDB error
Solved this:
https://stackoverflow.com/questions/385 ... home-mysql
On debian 9 you need to change ProtectHome to false in both /lib/systemd/system/mariadb.service and /lib/systemd/system/mariadb@.service then run sudo systemctl daemon-reload.
https://stackoverflow.com/questions/385 ... home-mysql
On debian 9 you need to change ProtectHome to false in both /lib/systemd/system/mariadb.service and /lib/systemd/system/mariadb@.service then run sudo systemctl daemon-reload.
Re: [Solved] New install 6.22 Odroid xu4 MariaDB error
Ah yeah now I understand that ProtectHome=true is an issue then. Was reading about the solution first and way freaking out what the connection between /home /root /run/user and /var/lib/mysql /mnt/dietpi_userdata/mysql should be

Re: [Solved] New install 6.22 Odroid xu4 MariaDB error
It was the same solution to the problem I had in an earlier post on a Z83 device:
viewtopic.php?f=11&t=5563
Not a very intuitive solution.
John
viewtopic.php?f=11&t=5563
Not a very intuitive solution.
John
Re: [Solved] New install 6.22 Odroid xu4 MariaDB error
@johnvick
At least the error message could be clearer IMO when a systemd unit setting itself prevents permissions. Otherwise not sure how it could track this from the main process.
However generally I think it is reasonable to block access for most services to user home directories. Things like database files that can anyway only be accessed by the database server itself fit very well into /var/lib as it's own run directory. We only link it to dietpi_userdata since this makes it easier to move it to an external drive, respectively this is the case already when user moved dietpi_userdata. Just relevant for SDcard/eMMC systems where you want to reduce disk writes as much as possible.
At least the error message could be clearer IMO when a systemd unit setting itself prevents permissions. Otherwise not sure how it could track this from the main process.
However generally I think it is reasonable to block access for most services to user home directories. Things like database files that can anyway only be accessed by the database server itself fit very well into /var/lib as it's own run directory. We only link it to dietpi_userdata since this makes it easier to move it to an external drive, respectively this is the case already when user moved dietpi_userdata. Just relevant for SDcard/eMMC systems where you want to reduce disk writes as much as possible.