Please provide debug ouput from snapperd daemon capturing the failure. Just kill current snapperd instance and start it manually by "snapperd -d" command. It should write debug log in /var/log/snapper.log file.

Or follow my comment: https://bugzilla.redhat.com/show_bug.cgi?id=1556798#c9

Anyway this seems like selinux policy issue where snapper is not allowed to create configuration file in btrfs subvolume for new snapshot.

So it seems snapperd is not allowed to set proper context on /mnt/snapper_test/.snapshots subvolume and probably it's not allowed to create file in that subvolume later.

I think snapperd is not allowed create/write in/to directories with selinux label other than snapperd_data_t.

Just out of curiosity. What's the selinux type of /mnt/snapper_test/.snapshots subvolume?

# snapper -c bugtest create  -p -t single
IO Error.
# ls -aZ /mnt/snapper_test
drwxr-xr-x. root root system_u:object_r:unlabeled_t:s0 .
drwxr-xr-x. root root system_u:object_r:mnt_t:s0       ..
drwxr-x---. root root system_u:object_r:unlabeled_t:s0 .snapshots

Hello,

The exact same issue is also observed with thin lvm volume snapshots:
Below is more detailed information from the result of testing with thin lvm volume:

[1] First I had created a thin lvm volume "/dev/mapper/vg1-thinvolume":


[root@testhost1 ~]# lvs -a -o+devices
  LV                 VG   Attr       LSize   Pool       Origin Data%  Meta%  Move Log Cpy%Sync Convert Devices              
  root               rhel -wi-ao----  <8.00g                                                           /dev/sda2(0)         
  swap               rhel -wi-ao----   1.00g                                                           /dev/sda2(2047)      
  [lvol0_pmspare]    vg1  ewi-------   4.00m                                                           /dev/mapper/mpathd(0)
  mythinpool         vg1  twi-aotz-- 200.00m                   0.00   0.98                             mythinpool_tdata(0)  
  [mythinpool_tdata] vg1  Twi-ao---- 200.00m                                                           /dev/mapper/mpathd(1)
  [mythinpool_tmeta] vg1  ewi-ao----   4.00m                                                           /dev/mapper/mpathe(0)
  thinvolume         vg1  Vwi-a-tz-- 100.00m mythinpool        0.00                                                         
[root@testhost1 ~]# 


[2] Formatted the above thin lv with ext4 filesystem and mount it on 


[root@testhost1 ~]# mkfs.ext4 /dev/vg1/thinvolume 

[root@testhost1 ~]# mkdir /root/test_mnt1
[root@testhost1 ~]# mount /dev/vg1/thinvolume test_mnt1

[root@testhost1 ~]# mount|grep -i test_mnt1
/dev/mapper/vg1-thinvolume on /root/test_mnt1 type ext4 (rw,relatime,seclabel,stripe=4096,data=ordered)


[3] Now tried to create a snapshot using "snapper" utility:


[root@testhost1 ~]# snapper -c test-1 create-config -f 'lvm(ext4)' /root/test_mnt1
[root@testhost1 ~]# snapper list-configs
Config | Subvolume      
-------+----------------
test-1 | /root/test_mnt1
[root@testhost1 ~]# 


Check the SELinux context on "/root/test_mnt1" before creation of snapshot:


[root@testhost1 ~]# ls -ladZ /root/test_mnt1
drwxr-xr-x. root root system_u:object_r:unlabeled_t:s0 /root/test_mnt1
[root@testhost1 ~]# 


The snapshot creation fails with following "IO Error" message:


[root@testhost1 ~]# snapper -c test-1 create  -p -t single
IO Error.
[root@testhost1 ~]#


[4] The snapshot creation was failing as the SELinux context on "/root/test_mnt1/.snapshots" directory was "system_u:object_r:admin_home_t:s0":


[root@vm253-62 ~]# ls -aZ /root/test_mnt1
drwxr-xr-x. root root system_u:object_r:unlabeled_t:s0 .
dr-xr-x---. root root system_u:object_r:admin_home_t:s0 ..
drwx------. root root system_u:object_r:unlabeled_t:s0 lost+found
drwxr-x---. root root system_u:object_r:admin_home_t:s0 .snapshots
[root@vm253-62 ~]# 


Got following AVC denial errors during snapshot creation:


[root@testhost1 ~]# less /var/log/audit/audit.log
[...]
type=AVC msg=audit(1539342687.118:239): avc:  denied  { create } for  pid=3910 comm="snapperd" name="1" scontext=system_u:system_r:snapperd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:admin_home_t:s0 tclass=dir
type=SYSCALL msg=audit(1539342687.118:239): arch=c000003e syscall=258 success=no exit=-13 a0=7 a1=7fe1e40569c8 a2=1ff a3=7fe1ec6115f0 items=0 ppid=1 pid=3910 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="snapperd" exe="/usr/sbin/snapperd" subj=system_u:system_r:snapperd_t:s0-s0:c0.c1023 key=(null)


Kind regards,

Milan.

*** Bug 1657280 has been marked as a duplicate of this bug. ***

commit 1c1eb497985e94117c075c81ca051c19e6edf431 (HEAD -> rhel7.7-contrib, origin/rhel7.7-contrib)
Author: Lukas Vrabec <lvrabec>
Date:   Mon Dec 17 11:16:08 2018 +0100

    Update snapperd policy to allow snapperd manage all non security dirs.
    Resolves: rhbz#1619306

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2019:2127