jus7incase

when backing up the flash drive content, the file config/super.dat is renamed to config/super.dat_CA_BACKUP. When you rebuild a flash drive from scratch and copy the config folder over to the flash drive it is easy to forget to rename super.dat_CA_BACKUP back to super.dat. If you forget that the server will not assign the drives and report the config as "stale". This is highly confusing and should at least be documented in the UI. It would be better if the file gets automatically renamed back by the pulgin after copying it to the backup location!

It would be great to have logging in the homebridge GUI container. I ooked for the log file but couldn't find it. also systemd is not running, so currently I saw no possibility to get the logs into the UI. If something doesn't work you definitely need the logs to solve the problem. Could you please extend the container to provide the logs and also set then in the initial config.json?

Hi! in the TVHeadend configuration the storage path setting for timeshift data is coming as empty. As a result, the timeshift buffer is managed inside the docker container filesystem and this may grow larger than intended. This may not be what everyone wishes to do. I thus suggest to have either in the standard setting a storage path set for timeshift as: /recordings/timeshift As a result the timeshift buffer is stored in the path where the DVR recordings go. Alternatively you could introduce a separate path for the timeshift buffer and as well a respective mapping for the container config. Just my 2 cents...

Hi altogether, to be honest I was not reading all 80+ pages of this upport thread.. I would like cache directories to initially scan all my disks. Is it going to do that automatically or is there something that I need to tune, so that it does a complete tree walk? Thanks!

Dear all if I understand correctly the "Docker Safe New Perms" is installed by the plugin "Fix Common Problems", so I post my problem here. I have run Docker Safe New Perms on all disks except for the Cache disk (nothing to be moved). Then I wanted to use unBalance to move the content of one disk to another disk. During the planning phase unBalance would complain that it found directories with improper permissions and I shall run "Docker Safe New Perms". So how can this be since I did run "Docker Safe New Perms" in advance. It turns out that unBalance considers existing Set-U-ID oder Set-G-ID bits as problematic, and "Docker Safe New Perms" does not clear out these bits. I do not know whether these bits are actually a real problem for the unBalance procedure. But if they are, then "Docker Safe New Perms" should remove those bits, e.g. by setting the permissions to 00777. (Note the leading 2 zeroes! Yes this is correct, with just one zero it will NOT clear those bits!) This can be done manually as long as "Docker Safe New Perms" does not do it: find /mnt/disk?/ -type d -and -not -perm 0777 -exec chmod 00777 {} \; However, if those bits do not create a problem with the unBalane procedure, the unBalance should not report them as an issue. if you search like this, you will find the directories where SUID or SGID are set: find /mnt/disk?/ -type d -and -not -perm 0777 This is not what we want if we do not want to report those directories. Instead it should be used: find /mnt/disk?/ -type d -and -not -perm -0777 Note the "-" (minus) character in front of the 0777. Now additional bits being set will not be reported! It would be great to get feedback from the author of unBalance whether these bits should be cleared or whether the should rather not be reported. In the first case it would be good to get feedback from the author of the plugin "Fix Common Problems" whether clearing of the SUID SGID bit for directories can/will be implemented. I am going to cross-link both postings in both support threads. Fix Common Problems thread:

Dear all if I understand correctly the "Docker Safe New Perms" is installed by the plugin "Fix Common Problems", so I post my problem here. I have run Docker Safe New Perms on all disks except for the Cache disk (nothing to be moved). Then I wanted to use unBalance to move the content of one disk to another disk. During the planning phase unBalance would complain that it found directories with improper permissions and I shall run "Docker Safe New Perms". So how can this be since I did run "Docker Safe New Perms" in advance. It turns out that unBalance considers existing Set-U-ID oder Set-G-ID bits as problematic, and "Docker Safe New Perms" does not clear out these bits. I do not know whether these bits are actually a real problem for the unBalance procedure. But if they are, then "Docker Safe New Perms" should remove those bits, e.g. by setting the permissions to 00777. (Note the leading 2 zeroes! Yes this is correct, with just one zero it will NOT clear those bits!) This can be done manually as long as "Docker Safe New Perms" does not do it: find /mnt/disk?/ -type d -and -not -perm 0777 -exec chmod 00777 {} \; However, if those bits do not create a problem with the unBalane procedure, the unBalance should not report them as an issue. if you search like this, you will find the directories where SUID or SGID are set: find /mnt/disk?/ -type d -and -not -perm 0777 This is not what we want if we do not want to report those directories. Instead it should be used: find /mnt/disk?/ -type d -and -not -perm -0777 Note the "-" (minus) character in front of the 0777. Now additional bits being set will not be reported! It would be great to get feedback from the author of unBalance whether these bits should be cleared or whether the should rather not be reported. In the first case it would be good to get feedback from the author of the plugin "Fix Common Problems" whether clearing of the SUID SGID bit for directories can/will be implemented. I am going to cross-link both postings in both support threads. unBalance support thread:

+1 from my side