0

I have a Debian 10 machine having it's large virtual drive formatted without a partition. It comes up as /dev/sdb in a df. The instance of mariadb had been in /var/lib/mysql as standard for Debian 10, but I frequently fill the root filesystem up with Bin logs due to replication. I am moving it to my large /dev/sdb filesystem to alleviate this problem.

In moving it to the mount point of /dev/sdb (/usr/www1/), I created a mysql directory matching the permissions exactly and "rsync -avzh" the files to this new /usr/www1/mysql directory and change the datadir in the mariadb server conf file. When I attempt to start it, I get the following logged error

2021-04-07 15:26:28 0 [ERROR] mysqld: File './mysql-bin.index' not found (Errcode: 30 "Read-only file system")
2021-04-07 15:26:28 0 [ERROR] Aborting

The common solution I've seen is to add an alias to apparmor which I did, but on closer examination, the MariaDB profile for apparmor is empty and has comments to suggest apparmor no longer tracks permissions for mariadb due to it providing very little value, but creates too many problems for mariadb users (or something to that effect). The change didn't help, but that suggested that this isn't my problem.

I've double checked the permissions repeatedly and even tried tightening and loosening permissions with the same results.

I'm now concerned that since the drive is not formatted with a conventional partition, that mariadb will not start on a drive formatted in this fashion and sees it as read-only. The system does not see it as read-only as shown in this lsblk:

NAME   MAJ:MIN RM    SIZE RO TYPE MOUNTPOINT
sda      8:0    0     75G  0 disk 
├─sda1   8:1    0    512M  0 part /boot/efi
├─sda2   8:2    0   58.5G  0 part /
├─sda3   8:3    0     16G  0 part [SWAP]
└─sda4   8:4    0 1007.5K  0 part 
sdb      8:16   0      1T  0 disk /usr/www1
sr0     11:0    1   14.1M  0 rom

Is it possible that mariadb uses a different method of checking the file system it is going to start on, and misinterprets it as read-only. Do I need to rebuild this drive with a partition before it can work with mariadb?

Edit to add requested information:

/etc/fstab entry for mount:

/dev/sdb /usr/www1 ext3 defaults,errors=remount-ro 0 1

This filesystem has worked for our apache2 serving horrendous numbers of pages this year so it would seem that most software doesn't see it as read-only. It was quite by accident that it ended up formatted this way. I hadn't used linux before putting up these servers and followed a cookbook that must have been for USB drives.

apparmor log had normal entries but no DENIED messages. It always starts with 5 messages about redirections that must be standard. It is in syslog.

Improve this question
7
  • I can safely assume that your problem has nothing to do with partitions. What filesystem type is this, and how did you mount it (please post commands or /etc/fstab contents)? Also, if Apparmor is at the root of the problem, there must be log messages somewhere. I don't know where Apparmor writes its logs, unfortunately.
    – berndbausch
    Apr 8, 2021 at 0:47
  • @berndbausch Thank you for responding. I added the information into the post. It is encouraging if you think it is not the formatting. Reformatting and partition would be a major job.
    – TreedEagle
    Apr 8, 2021 at 1:28
  • The errors=remont-ro option has the effect that the filesystem is mounted read-only when inconsistencies are detected during startup. If that is the case, the mount command should report that, and you should see corresponding messages in the system log /var/log/syslog. That would be the first thing I would check.
    – berndbausch
    Apr 8, 2021 at 2:46
  • By the way, I would replace the device file /dev/sdb by its UUID or LABEL in /etc/fstab. Device file names are not guaranteed to be persistent, and the next time you add a disk or otherwise change the disk configuration, /dev/sdb might refer to a different storage device.
    – berndbausch
    Apr 8, 2021 at 2:48
  • Thank you for your help. Just by spurring to look further than my paradigm, I found that the ProtectSystem was set to full and includes /usr in the debian installation. If you would like to post the answer, feel free. A mariadb database in /usr requires that ProtectSystem=false in /etc/systemd/system/multi-user.target.wants/mariadb.service. Works like a charm now.
    – TreedEagle
    Apr 8, 2021 at 2:48

1 Answer 1

Reset to default
0

I'm answering this myself so there will be a record of this variant of the solution. It turns out the solution to this is quite similar to all the examples on the net where people can't get mariadb to start when they move it to /home, with a twist.

On Debian 10, systemd includes /usr in directories. It's by design that you can't have a website running out of /usr if it uses a mariadb. To correct it, as sudo:

vi /etc/systemd/system/multi-user.target.wants/mariadb.service
/ProtectSystem=full
s/full/false/
ZZ
systemctl daemon-reload
systemctl start mariadb

I'm not sure if this needs to be repeated on every update so be vigilant when applying patches.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .