От него и пробовать запускать скрипт я так понял?

скрпиту нужен доступ к датакаталогу СУБД, а он доступен только от рута и от юзера postgres. так что и запускать нужно скрипт от postgres. и владельцем каталога /backup1c/backups делать юзера postgres.

угу... то есть, нужно убить шару и сделать ее снова, но на пользователя рут с uid и gid его?

в постгресе утилиты любят проверять чтобы на каталог стояли postgres:postgres права. если нет, то оно может руннуться и не работать. и это я про ванилный постгрес. подозреваю, чтобы в probackup такая же петрушка. таким образом если вы там начнёте с рутом колдовать, думаю, что к успеху вы не придёте

у меня тоже ванильный от 1С

если "убить" — это размонтировать на тачке с СУБД, то да. umount /backup1c

да это и имел ввиду

можете ещё попробовать с другой стороны подойти: на нас указать всем этим каталогам uid и gid от пользователя и группы postgres вашей машины. не знаю, сработает ли и вообще получится ли...

Да сейчас так и хотел сделать

postgres@srv1c:/script$ id uid=110(postgres) gid=118(postgres) groups=118(postgres),104(ssl-cert) rw,nosuid,nodev,noexec,relatime,vers=3.0,cache=strict,username=backup1c,uid=110,forceuid,gid=118,forcegid,addr=10.1.1.251,file_mode=0777,dir_mode=0777,iocharset=utf8,soft,nounix,serverino,mapposix,rsize=4194304,wsize=4194304,bsize=1048576,echo_interval=60,actimeo=1,closetimeo=1 так должно быть типо?!

похоже на правду. если уже перемонтировали с этими значениями, что теперь говорит команда find /backup1c -type d -exec ls -ld {} \; ?

я не выполнил эту команду еще... отвязать шару не получилось unmout

как вариант вместо unmount можно попробовать mount -o remount /backup1c но если дело действительно в контейнеризации, то не поможет и это.