I’m having a bit of a torrid time setting this up at home. I’ve downloaded the tar.gz and unpacked it.
My first attempt to install by pointing the browser at the 1.7.2 directory failed at step 1 when it does a check of all the components needed to run it. I had quite a few marked as X but I’ve got it down to one which is write access to install.php and settings.php.
I’ve set install.php to rw,rw,rw and it still failed because there is no settings.php file included with the 1.7.2 download.
I tried to trick the installer by making a blank settings.php file and setting this to rw,rw,rw. The installer then said database error which I have taken as a sign of success at step 1 and is now going to step 2 which fails as the settings.php file is blank - hence no DB.
Creating a file is a function of the directory, so you need to make the root directory of the Xibo installation writable to the web server
Elaborating a little -
settings.php is not missing, it is meant to not be there and get created once your DB has been populated by the installer.
You need to delete your blank settings file, make the directory writeable and then run the installer again.
I am having the same problem. You are vague in your response. Which directory needs to be made writeable and which user actually requires write access?
We’re not aiming to be vague, it’s just that there’s so many possibilities.
The directory is whatever directory you’ve installed Xibo in - ie the one that contains xmds.php and index.php.
The user is whatever user your web server is running as. On Linux that might be the user
httpd depending on your distribution. On Windows that could be the
SYSTEM account, or your IIS user, or an actual user if you’re running your LAMP stack as the user you’re logged in as.
I am using IIS (Windows), and my Xibo directory is the default C:\inetpub\wwwroot\Xibo per the guide on Xibo’s website (http://xibo.org.uk/manual/en/install_cms.html). This is a fresh install of IIS with no odd setup, so I have no clue why this is not working.
I think on IIS you have to enable the site to write data in th IIS properties somewhere. I’m not sure where as I don’t use it myself. You need to ensure that the directory itself is writable to your IIS user. You configure who IIS runs as so I’ve no idea who that would be. It could be Network Service account, or System, or another account. I’m sorry I can’t be more precise.
Perhaps this would be of assistance: http://stackoverflow.com/questions/14653722/how-do-i-give-asp-net-permission-to-write-to-a-folder-in-windows-7
We do not develop on IIS or test on IIS so it is difficult for us to comment on the exact steps required to set it up.
I’m running IIS on a fresh Install of Windows 8.1 Pro. I’m having the same issue, I copied xmds.php and renamed it to c:\inetput\wwwroot\xibo\settings.php and erased the content of the file. I than modified permission and gave settings.php and install.php full access by every user account, that worked. Not the proper way to do things, but a far simpler solution than others provided.
I can’t imagine how that worked… didn’t the installer think that Xibo was already installed because
settings.php existed? Or did you also manually populate the database?
When I copied another php file and renamed it to settings.php, Xibo gave me the warning that xibo was already installed. When I erased the content of settings.php, I got the permissions warning instead of the ‘xibo already installed’ error msg. The settings.php file is populated as you complete the setup, which is the names of the database, its users, and related passwords. It may not have been necessary to even create a blank settings.php page, the most likely solution was that I just had to allow every single account full permission to install.php, as I’m confident the system would create settings.php in step 2 (the step just after you got stuck).
You don’t need to give the world write access. That’s a really bad idea. All that’s required is write permission for the user your webserver runs as. I can’t tell you what that user is called because it varies from webserver to webserver.
I agree with both points, I was just trying to give him a solution that works after the install is completed the permissions should be changed, most likely both files can be set to read only (as long as you don’t change the database name/user/pw)
I hope this worked for you @dhumes
They are only written to that one time, so yes you could change them back to read only afterwards.
I’ve the same problem on IIS 8, Windows 2012 server, PHP 5.6, also with RW permissions to everyone.
The solution is to bypass the check in:
\config\config.class.php (3 hits)
Line 633: return (is_writable(“install.php”) && (is_writable(“settings.php”)) || is_writable("."));
I’ve substituted this line with:
the installation process created correctly the settings.php file.
There’s no need to modify the source code. It’s perfectly possible to install on IIS without if you set the permissions correctly.