Is it possible for a non-root user to get a crontab?
Yes, crontab -e works as non-root, this isn’t container specific.
each container will have its own crond as started by init scripts in that container, each container has its own crontabs and it all operates the same way inside the containe for all users in that container. if that image has a different crond, then it will be as different as that software is different. containers offer a way to run different crons, as needed, instead of a whole VM to do it.
~ # su userx
/root $ whoami
userx
/root $ crontab -e
crontab: must be suid to work properly
/root $
This is on an Alpine container. Debian says
userx@dtest:/root$ crontab -e
crontabs/userx/: fdopen: Permission denieduserx@dtest:/root$
Any suggestion?
On the Ubuntu container images, crontab -e works fine.
For other container images, it is important to create properly the non-root account.
$ lxc launch images:alpine/edge crontab
Creating crontab
Starting crontab
$ lxc exec crontab sh
~ # ls /home/
~ # adduser alpine
Changing password for alpine
New password:
Retype password:
passwd: password for alpine changed by root
~ # su -l alpine
crontab:~$ crontab -e
... furious crontab editing with vi ...
crontab:~$ crontab -l
10 * * * * uptime
crontab:~$
Can you show a full test case (from container creation to failure) on Alpine and Debian?
for Debian:
gpasswd -a userx crontab
$ lxc launch images:alpine/edge crontab
Creating crontab
Starting crontab
$ lxc exec crontab sh
~ # ls /home/
~ # adduser alpine
Changing password for alpine
New password:
Retype password:
passwd: password for alpine changed by root
~ # su -l alpine
crontab:~$ crontab -e
crontab: must be suid to work properly
crontab:~$
Druggo’s solution for Debian is working. So just Alpine container is giving trouble now.
Edit: error cannot be reproduced using a zfs storage. this issue seems to be with Alpine/dir backend combo
Thank you. This works indeed