Announcement

Collapse
No announcement yet.

Can not add forums

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • attroll
    replied
    Originally posted by DannCG View Post
    Hi attroll,

    I'm really appreciate if you could tell us how did you solve this permission issue. I'm having very similar problem like you but my case specifically related to ownership/group issue. Hope you can share here.

    Thx.
    DannCG, just sent you a PM.

    Leave a comment:


  • DannCG
    replied
    Hi attroll,

    I'm really appreciate if you could tell us how did you solve this permission issue. I'm having very similar problem like you but my case specifically related to ownership/group issue. Hope you can share here.

    Thx.

    Leave a comment:


  • attroll
    replied
    I am happy to report that we are getting the file to stay at CHMOD 777 now. But here is the new problem and I think this may be a VB issue but I am not sure.

    If I start out with a new datastore_cache.php file and make it CHMOD 777 and then open up my Admincp it reads the contents from the database into the file and saves the file. Then when I try to delete a forum is says that it was successful but after is says that then it brings up the forum listing again but it it still shows the forum that I jsut deleted. It seems as though it did not get deleted. I then try to click on the forum that I tried to delete and it says "Invalid forum specified".

    To me it seems like it is not writing back to the datastore_cache.php file with the changes.

    Any ideas on this one?
    Last edited by attroll; Sat 5th Jan '08, 1:15am.

    Leave a comment:


  • attroll
    replied
    My team is telling me that through the browser that a file can be accessed that is 777 but can not be written back to and remain as CHMOD 777. They are telling me that it is suppose to revert to 644.

    Sorry but I am getting pretty dam frustrated at this situation. I have four other VB sites running on this same server and none of those have this problem.

    I am getting ready to say the heck with it and upgrade to 3.7 and see if this fixes the issue. I was trying to wait and for 3.7 to cone out of beta first but I do not know what to do now with this problem.

    Leave a comment:


  • Steve Machol
    replied
    I have no idea what your host's response means. However there is no code in vB that would ever change file permissions. None whatsoever. Sorry.

    Leave a comment:


  • attroll
    replied
    Here is an update to what my server management team has replied to me as of today about setting the datastore_cache.php to CHMOD 777 and keeping it that way after it is written to from the admincp section.

    The way linux permissions is structured and the way apache is set up, what you said simply cannot be done.

    We can try to reproduce this, and make linux work like it isn't supposed to, but this will be very, very difficult, albeit impossible.

    This could possibly be a bad update on vbulletin somehow.
    Steve, I am hoping you tell me that this is not true and that a VB upgrade will not be the cause of this or maybe shed some more light on this somehow.

    Leave a comment:


  • attroll
    replied
    The host is not the problem. I how my own server. It is the server management team that can not figure it out.

    Leave a comment:


  • legionofangels2
    replied
    I'd recommend find another host.

    1 and 1 hosting, 5 bucks a month, a ton of bandwith, and they don't mess with your vb at all.

    Leave a comment:


  • Steve Machol
    replied
    It has to be 777 because it needs to be world-writable. Once it's changed to 644 by the server, vB can no longer write to it, hence the the error you are getting.

    Your choices are:

    1. Your host fixes whatever is causing the server to change the file permissions.

    2. Don't use the file datastore cache.

    3. Find another host.

    Leave a comment:


  • attroll
    replied
    Steve

    I am still having problems with this. I have a question to ask you that I need clarification on. Why does the file have to be 777? My server management crew is trying to tell me I should be able to do everything I need to do with 644. I told them it has to be 777. Could you please explain to me why it has to be 777 so I can relay this to my server management team? This is what they replied to me below.

    It is normal that a file when saved using a browser will revert the permission to 644 and the ownership will be nobody:nobody. Any users will be able to read and write to that file as the user ownership is nobody. By giving 777 permission the file will be having execute permission, but I dont think that execute permission is necessary for a php file as it works well with 644 permission.

    Leave a comment:


  • attroll
    replied
    I know turning the datastore caching off works. I have turned it off and it works like a charm. I have a fairly large database and I want to get this working again to keep the loads off the database and to keep the querying down on the database.

    I have a good server management team (or so I thought). I just do not know where to turn to now to get this resolved.

    Leave a comment:


  • Steve Machol
    replied
    vB has absolutely no code in it that changes file permissions - none at all. I'm afraid this remains a server issue.

    If your host can't fix this then you should turn the databstore file caching system off.

    Leave a comment:


  • attroll
    replied
    Steve

    I hope you still checking in on this thread. I have had my server management team check the unmask settings and they change some of them. Here is what they told me they did.
    I have changed the unmask for the user nobody as 000 which should resolve your issue. Please check it and if the problem persists please let me know.

    Also can you please explain why you need to set 777 permission for the file databasestore_cache.php. Most of the php file works with the permission 644.
    The problem is that every time I go into my Admincp and change something the change doe not show up in my admincp and the file reverts back to 644. If I comment out the line in my config.php then everything works fine. My server management team is not understanding this either. They seem to think it is a VB issue.

    Leave a comment:


  • Steve Machol
    replied
    No, there is nothing in vBthat would change the file permissions. More likely the umask setting for that directory is set to automatically change the permissions everytime the file is saved. Ask your host to fix this.

    Leave a comment:


  • attroll
    replied
    Steve

    I am hoping you read this because I would like to here your take on this.

    I had my server guys look into this problem and they told me it was a VB issue and not a server issue. This is what they said.

    Everytime you save the file the function build_forum_permissions was executed which resets the permission of the file to 644. This is the vbullient php function. I edited the file forum.php and disabled the function for "save".
    Is this true? I am not happy with them changing my forum.php file but why are we suppose to set the databasestore_cache.php file to 777 if this happens changing it back to 644 so it in no longer writeable.

    Leave a comment:

widgetinstance 262 (Related Topics) skipped due to lack of content & hide_module_if_empty option.
Working...
X