Fork me on GitHub
Current release is 2.1.6 (21 Nov 2014).

Users who have not yet upgraded to 2.1 should get security release 2.0.18.14 (1 Nov 2014). We will stop providing these security releases to 2.0 at the end of this year.

FileUpload Folder Permissions

edited November 2011 in Vanilla 2.0 Help
This discussion is related to the FileUpload addon.
I've recently added the FileUpload plugin and through testing noticed that uploads are not accessible by forum users. The forum users have the upload and download role permissions set, however the actual folder permissions aren't being set for web users to access the content (e.g., 777).

If I go back in and adjust the permissions on the new folder(s)/file(s) manually via chmod the items (and thumbnails) show up just fine. New uploads don't appear to be getting those permissions though.

I'm still getting up to speed on PHP, but I took a look at the class.fileupload.plugin.php file and the placemedia function appears to use mkdir with 777 permissions. So it must be something with my server setup...

Any suggestions?

I'm running Vanilla 2.0.18.1 with FileUpload 1.5.2 on a (hosted) linux server. The files are getting new file names generated. Also, $Configuration['Garden']['RewriteUrls'] = TRUE;
Tagged:

Answers

  • I think I have fixed the issue. I disabled it and re-enabled the plugin and the permissions seem to be taking now.
  • have the same problem, but re-enabling the plugin doenst help.. in the script it looks like de folders were created with 777 but on the server de folders has 774 and uploaded files 664.. when i change that manually to 777 everything works!

  • You should NEVER set your Folder permissions to 777. PHP Usually runs under your Host Account user or at the very least the Group of your Host Account user, so can access it just fine. The Public/Other write rights apply to web users and has nothing to do with your forum working or not. Most of my folders at root of forum and in uploads folder are either 771 or 751. PHP really should only need Read too and not Execute since the script is just read and ran by the PHP interpreter. The Write permission on the Public side is never needed. The Read Permission allows them to get a listing of the files within it (The Index Of pages in a browser), and the Execute Permission gives them the right to get a file from the folder (If they know the exact name they can read it, but they can't see a list of all the files in the folder)

    UnderDog
  • x00x00 MVP
    edited October 2013

    @Nilla_Wafer trust me this is the bane of my life, I have been trying to get this message across for years. good luck with that.

    I blame cheap web hosts. They never developed infrastructure that would support good practice, they took the lazy option, which means many people have no idea file ownership let alone permissions.

    Personally I favour the set up of the process user only assigned to to file allowed and everything else under another user.

    However you get extremely weird stuff with VPS setups like the process user being nobody (linux 'nobody' user), but only running cgi to some account user, but this is only when directly referenced, anything included from this file it makes no difference, so long as it can be read.

    This is kind of irrational, it is ok if you only have one dispatcher, but on older software it is not MVC like.

    The real suck of it is the write capability of this user.

    grep is your friend.

    UnderDog
Sign In or Register to comment.