I am using rules to implement an "email subscription" feature where users can opt in to having new content of a particular content type emailed out to them (so they can read on a Blackberry which can't access the site). This works well but in my original setup, raises an error whenever the user uploads a user picture (avatar). This happens to all users, all of the time when uploading user pictures, irrespective of whether they opt in or out of the email subscription:

The specified file temporary://filename.jpg could not be copied, because no file by that name exists. Please check that you supplied the correct filename

In fact the picture upload has worked, but this error tends to confuse users, who then think their picture upload has failed.

At first sight this looks like an issue with the temporary directory but this is set correctly to /tmp on my system (Ubuntu Linux).

I've found a workaround.

I have one rule triggered "after updating an existing user account" to grant a "send me emails" role if the user has ticked a taxonomy field on their profile to opt in, and a similar one to do the reverse. I need the rules because non-privileged users can't directly alter their own roles.

These rules are the problem. But if I instead choose to fire them "before saving a user account", keeping everything else the same, they still work and the users no longer see the error.

The actual emailing is done by a "send mail to all users of a role" rule triggered on e.g. "after saving new content" - no problems there.


soul_discharge’s picture

I am having the same issue here as well. I have a rule granting a user a role after updating a field in their account profile. My users receive the same error as well after updating their user picture. Just like Matthew I ended up resolving the issue by changing the event method to "Before saving a user account". Is there a particular reason why this happens?

khanz’s picture

Version: 7.x-2.3 » 7.x-2.6

Facing exactly same error with Drupal7.26 and Rules 2.6. Changing the event method to "Before saving a user account" fixes the error. Though i am curious why this happens.

tedbow’s picture

Version: 7.x-2.6 » 7.x-2.7

I can confirm that I have same problem in 7.x-2.7 and 7.x-2.6.

Same method above fixes it.

Pafla’s picture


I am having the same issue.

My rule is "Role Superuser appoved":
Event - After updating an existing user account
Conditions - User has role(s) Parameter: User: [account], Roles: Superuser
Actions - Remove user role Parameter: User: [account], Roles: User

When adding the role "Superuser" to a user, the User picture (Avatar) disapere, but not the file on server.
And when uploading a new avatar the same error occurs.

If I disable this rule.
And add the role "Superuser" and remove the role "User" manually, then no problems.

What is the difference between "After updating an existing user account" and "Before saving a user account"?


plato1123’s picture

I'm having the same issue with Rules 7x-2.9

Yikes! I just spent 7+ hrs trying to figure out what module could possibly be causing this. People experiencing this error due to rules are unlikely to come across this thread as there are many many circumstances that can cause this exact error that have nothing to do with rules.

plato1123’s picture

Priority: Minor » Critical
qichanghai’s picture

The problem happens because in user module, a "picture_upload" property is copied to the account object from the $edit(which is the submitted values from profile form) in the user_save($action, $edit, $caterogy) function. And it's passed to rules, and rules passed this object(with some changes defined in the rule) as the $edit parameter to save the user again. And the "picture_upload" from $edit is copied to "picture" of $account in user_user_presave. Since it's a temporary file, it will be copied and saved as a permanent file, and since it's already done, the error comes.

So the solution should be either 1), the user module shouldn't copy the "picture_upload" property from the edit form to account object, or 2), the rules module shouldn't directly use this object as the $edit parameter of the user_save function, but only the values changed by the rule.

My workaround is adding an php code action in the rule to unset this property.