./images/avatars directory not writable even though...
 

...the permissions and ownership on it are correct:

I'm logged onto our server now (SSH) and looking at the directory for avatars: ./images/avatars

The directory has no image files. The index.html file is there as well as the thumbs sub-directory, which is also devoid of any images files (it also has an index.html file).

I don't know what to make of this, as this is the only avatar directory I am aware of, yet all the Administrators avatars are being displayed, as well as their profile pictures.

Something interesting, is that in the AdminCP, when I run Maintenance > General Update Tools > Rebuild Avatar Thumbnails I get the message:
Yet the permissions and ownership of the directory, files, sub-directory and files are correct:
Added:
This from the follow-up post by our member:
Suggestions? Comments? Thoughts?

Why is the avatars directory not writable, according to vBulletin, even though it is? How do I fix this?


Additionally, our members (non-Administrators) are also saying:

"I also get similar errors when trying to send PMs, access profile settings and general settings"

Edit: Actually Stefan118's probably right. It could just be that the error message you posted is displaying the relative path.

The directory is not writable, becouse you do NOT have set the right permissions!

drwxr-xr-x means: chmod 755 permissions on a directory: writeable by owner, readable by all and where files are executable by all.

You need to set them to: drwxrwxrwx (chmod 666) which means that everyone can read, write and execute the files.

But ALL the directories under images have the exact same permissions, and those were set when the forum was installed. They must be correct, and, this problem didn't present itself until just a few days ago. Prior to that, all was just fine.

but still i mis the w from write, so your forum can't write to the directory.
It has been set to writable for a logged in user only (the owner of the site)

Well, the first set of 3 is the permissions for the owner of the file or directory. So if it was working before then it could be that the owner of the directories was changed, or maybe that the user the php scripts run as was changed.

Hmm. Looking at the Avatar File Path note (AdminCP > Avatars > Add New Avatars) it does say:

Avatar File Path
This file path should be readable AND writeable by your web server (usually chmod 0777)

I can/will change the permissions, but how did the directory and sub-directory/contents permission get set to 0755? I didn't do it, and I know that none of the other Administrators did.

Hmm.

They say to set it to 777 because then it will be writable for everyone. But it's possible that it could work with the permissions set to 755 depending on what user owns the file and what user the php scripts run as. I only know the basics of linux admin, but I think it's normal for the web server to run as a different user than the one that owns the files and directories, for security.

Why it is changed i don't know.
But the fact is, you need to set it to eighter 666 or 777 (executable is an option)

Now I'm confused. I don't want to set anything within our forums root directory to globally read/writable (0777) unless that is what it is supposed to be, and I really doubt that that is the case. As I said, I changed nothing, nor our other Administrators.

What are the permissions for the ./images/avatars directory on your forums? What are the permissions on the contents of that directory? In other words, what are the 'default' permissions supposed to be?

Thats true, the vbulletin software does not login to the server with the owners username and password. Actualy, it doesn't login at all.

Part of the confusion might be the use of the word "user". I've been talking about users in the OS, which is different than vb users. If you set a directory to be writable to everyone (all OS users, that is), that probably isn't an issue.

Edit: I guess what I'm saying is that I agree, you should set it to 777 and see if that works.

i looked at mine, and it is also 755.
Also there is 1 directory in it, called thumbs, and there are 2 files called: index.html and thumbs.db

Which would be 'safer' - more 'conservative'? 0777 allows for execution, and 0666 does not, yes?

correct.

The "execute" bit means something different for files than directories. While it means "executable" for a file, for a directory is means "searchable". It may or may not work with the directory "searchable" bit set to off, I don't know. But you probably won't be able to do a directory listing in ssh.

As to this question:

But this crossed my mind...
Do you save your images in your database or on the filesystem?
That could explain something.

I don't know, but given there are no images in the directory, yet the Administrators avatars and profile pictures are being seen, I'd say in the database. How can I validate that?

I'm off to work haha, KH99 will take over ;)

Yeah, I didn't answer that question the first time because we have a dedicated server with an admin guy, so I don't understand everything about how it's set up (that's the site I work on, not vbulletin.org - I have no idea about this site). Anyway, ours is set to 775, but I think that works because the web server user's group and the "group" of the file are the same (again I'm talking about the linux concept of a group and not vbulletin).

I think the vb help says to set it to 777 so that you don't have to figure out all that stuff. I think it's safe to use 777.

Thank you. chmod to 0777 on the ./images/avatars directory as well as the sub-directory thumbs but left the index.html file in both directories at 0644.

AdminCP > Maintenance > General Update Tools > Rebuild Custom Avatar Thumbnails and Rebuild Avatar Thumbnails no longer complains that it can't write there.

Still, even after that, and clearing the system cache, no one other than the Administrators has their avatars showing, nor their profile pictures.

--------------- Added [DATE]1353273912[/DATE] at [TIME]1353273912[/TIME] ---------------

Found it. Images are currently being served from the database

Looking at the html source on your site I don't see any code for the avatar on normal users, so it couldn't be a permission error (and write permissions would only affect uploading new ones). Or maybe I just happened to look at a user that had no avatar - can you link to a thread with a user you know should have an avatar?

Have you tried temporarily disabling hooks to see if there's a problem with a mod?

Here you go.

http://www.kubuntuforums.net/member....73-vinnywright

--------------- Added [DATE]1353274122[/DATE] at [TIME]1353274122[/TIME] ---------------

There haven't been any MODS added prior to this issue being reported.

I see no avatar code, so I guess the forum thinks that user has no avatar for some reason, or else there's a mod affecting it. (Edit: I couldn't see the user's profile since I'm not logged in. Does the avatar show up there?).

BTW, just noticed your forum is about linux, so sorry if I was explaining stuff that you probably know better than I do. :o

The only 'addition' to our forum was the installation of ZB BLOCK, but it operates totally within it's own directory -- it doesn't touch anything outside of that. And, it was installed seven days ago, and I do remember seeing everybody's avatars after that. This issue seems to have presented itself within the past few days.

Originally Posted by kh99
Have you tried temporarily disabling hooks to see if there's a problem with a mod?

How does one 'temporarily disable hooks'? On a MOD per MOD basis, or 'globally'?

Oh..check the usergroup manager, look at the "Can Upload Custom Avatars" setting. According to the code if the user has a custom avatar but that permission is set to "No", no avatar will display.

Can Upload Profile Pictures and Can Upload Custom Avatars are both set to Yes.

We are using the database to store these image files.

To answer the above question I missed - to disable hooks you can edit includes/config.php and put this somewhere in the file (after the <?php line at the top):


But like you said, if you haven't added anything it probably won't be that. You might try disabling zbblock just to make sure, but I don't really see how that could cause this problem.

So that user has a custom avatar? And if you go to the user's profile, can you see it there? I'm kind of out of ideas.

I already disabled zbblock earlier -- it didn't make a difference, and I didn't believe it would. But it was an attempt to 'eliminate' zbblock as a possible cause.

The user 'had' a custom avatar. It isn't showing in his user profile now, as is the case with all our other members who had avatars. As I said, this issue is affecting everyone except for the members of the Administrators and Retired Administrators usergroups.

When I set the permissions on the ./images/avatars directory/sub-directory and ran the rebuild maintenance options, I saw lots of image files being updated -- in the database.

I guess I could execute the Move Items from Database into File System. I'll have to change the permissions on the ./customavatars and ./customprofilepics directories before doing so.

Hmm...does the user have a record in the customavatar table (where userid = their id)?

I'm just now in the AdminCP and looking at one of our members who has a custom avatar. Under Image Options his avatar is showing. In fact, it looks as if the custom avatars and profile pictures are known to our forum, as they can be seen when looking at their User information in the AdminCP.

Does that suggest anything to you regarding this issue?

Maybe try this experiment, if it's not too much trouble: edit the postbit_legacy template, and find this line:

and change it to


That should force it to show avatars for everyone, but only for you (it looks like your userid is 1816). See if that makes the avatars look right.

The change won't save.
I get:

Since the template tags aren't really html, the html comments don't work to comment them out. There is a vb:comment tag you could use:

Also, I only added "$bbuserinfo[userid] == 1816 OR" so all you have to do is remove that when you're done.

Hmm. Well, now with this:
Trying to save I get:
I've used the <!-- --> tags in the templates before.

Yeah, the vb:comment tags aren't working like I thought the should - I don't know why. But the problem is the first vb:if tag you're trying to comment out isn't getting commented out, and there's no corresponding </vb:if>. I guess if you really want to keep it in there you'll need a closing tag, like:


Yes, you can use html comments in a template, but they just get passed through to the browser. They don't affect the template compiler, so they don't work to comment out the special template tags.

I had a thought (it almost hurt).

All the affected members belong to the Established Users usergroup, which is an Additional Usergroup. They have all the permissions necessary. But, they belong to the Registered Users usergroup which doesn't have the permissions to use avatars or profile pictures.

I was making changes to the Registered Users usergroup 'today', but of course, the issue we are having began a day or so ago.

Question: Do the more restrictive permissions of the Registered Users usergroup override those of the Additional Usergroup? I don't believe that is how vBulletin works, but I have to ask.

I'm pretty sure it's the opposite - a user has the most permissions of any of the usergroups he belongs to, so Yes overrides No and higher numbers override lower numbers, except where a 0 means "no limit" or something like that.

The experiment I wanted to try above was made to check if the problem was that $show[avatar] was false but everything else was OK. But if that's the case, then the only thing I can see that would cause that is the "Can Upload Custom Avatars" permission.

Okay, made the template change correctly and it saved. Cleared the system cache and logged out of my forum (clears cache and cookies) and came back in. Still no member avatars or profile pictures.

Not to complicate the issue here, but these members are also not able to PM anyone or access the change options within Settings: