Task owner cannot start it's own task after migrating from GVM 11 -> GVM 20.08


Under gvm 20.08 latest stable release; and after migrating from GVM11; some (not all) users cannot start their own tasks any longer. Problem doesn’t happen if the task was created after migration. The only available error is

event task:MESSAGE:2020-11-18 15h49.40 UTC:27649: Task XXX (c7e79b9a-6d12-4ce0-8cfe-45ae013b619c) could not be started by Username

I have also notice this on tasks owned by admin but scheduled. Tasks won’t start with the same error message. This did not happened with GVM11.

Adding the task owner write permissions to this task fix the problem, but obviously this is a non-sense since the user is the task owner !

Anyone has witnessed this ?


During the migration to gvm 20.08 many globally owned objects became owned by the “feed import user”. This concerns default scan configs and port lists. The feed import user is a user of your choice and everybody with the roles Admin and User gets automatic permission. Maybe some of your accounts are neither the feed import user nor sport one of the access roles?

1 Like

Thanks Tino for your explaination. I didn’t know this.
My users were indeed not part of the built-in User role. I have added them to this role and will see if that makes any difference.

I also have another weird permission issue. My administrator user, who is part of the “Super Admin” group, cannot modify his own permissions. Eg; he can’t add himself to other roles/groups without getting a “permission error”.

How is that possible ?


An account with the role Superadmin has par definition permission to do everything with everything on the GSM. It achieves nothing if you add anything to such an account. There is no way the permissions of such an account can be edited, it will always have permissions to every object.
In case this isn’t clear: an account with the role superadmin, should not be used for production tasks. It’s intended to help you out in case you are confused about your own permission setup, and need to an account that ignores permissions all together.


I agree with that, but the error message is actually very confusing. This sounds like the super user do not have all permissions; hence the confusion.