I uploaded a website that is working in the localhost using Akeeba backup. It is done by creating a new public_html at the host using its cpanel. Next i transfer the .jpa & the kickstart.php to this new folder. Finally i browse the kickstart.php and restore the website running on joomla 2.5.14.
Accessing the admin panel of Joomla, it reports all folders as WRITEABLE and site runs good. In cpanel all folders permission is set to 755 & files 644 as expected; i then change configuration.php to 444.
However when i try to edit the configuration.php in the host, i found i can't change the file permission or save any edit. This in fact affects all files. After informing the host, they change the file ownership setting, then in cpanel i CAN edit files BUT now Joomla reports all folders become UNWRITEABLE creating more problems eg cannot install new extension; some how Joomla no longer has edit rights to the folders.
More ... at this state, to make a folder WRITEABLE to Joomla, it must be set file permission to 777. It is unexpected & unacceptable; 775 is sufficient for Joomla to report as writeable ie if the host is doing the right thing for Joomla (as i found in another hosting site).
When i tell the host to change it back to the state after Akeeba restoration, they say that will mean they have to set the folders with ownership = nobody.
I would imagine ownership of folders & all its content can be made to be the cpanel user AND the joomla ie php/apache user. Can someone enlighten me this puzzle so that i can talk more intelligently with the host or point where i went wrong. I am getting no where with them.
PS: Latest Sharing Update
The solution is find a host that has Server API showing as cgi/fastcgi which mean that suPHP of Apache is enabled (sorry cannot post .jpg < 10 reputation)
With cgi, Joomla report all 755 folders as writeable.
Now the new question
If the host use Server API = Apache 2.0, how can i enable suPHP from the website?
As you have worked out, suPHP or FastCGI should usually be enabled for Joomla file permissions and file ownership to work as you would expect.
There is a good article on this at: http://boomshadow.net/tech/php-handlers
In a shared hosting environment you don't usually have access to change which PHP file handler is enabled but your web hosting company may be able to change this for you.
If your web hosting company can't enable suPHP or FastCGI, the only other option might be to find a new web hosting company.
Related
Good day,
I had created my online store on a VPS, I opted to move the store to a web hosting package. After installing opecart using softalicioucs the default installation worked fine. I then edited the config files in both admin and public_html to change the database to the original backup of my VPS.
Once I do this, "You don't have permission to access this resource. Additionally, a 403 Forbidden error was encountered while trying to use an ErrorDocument to handle the request".
If I go back to the installed default database its all good again. I have set the necessary permissions etc for the user to access the backup database.
Anyone knows what is going on? is there some table storing access information?
After disabling MODSECURE I realised that the new installation created tables with prefixes not as my original interfaces, hence the solution was to change the prefix in the config file.
Good morning. I have a dedicated ubuntu server behind my company's firewall. It is using Django, Gunicorn, and Nginx to serve an Intranet application to employees. The original app responds to the URL [server_name]/[original_application_name]. I want to serve additional apps from this server. I have followed this tutorial as I did when setting up the original app.
I can run Gunicorn and serve the app, I have created a second systemd service file that appears steady (copied from the original app with paths changed - service runs), same for a new 'sites-available' file in Nginx (copied from original and modified), new .sock file exists, binding appears successful. However, I have yet to hit on the right configuration combination between settings.py [allowed_hosts], [new_app].service, and nginx etc.
The original app is running and when I try a URL related to the new app it gives an error saying it cannot find the request in the url.py of the original app. The new app would be used by the IT dept. Ideally, the new URL would be something like: it.[server_name]/[new_application_name].
I have looked through other cases with this problem but most use Apache or are on a public hosting site. I have seen this but it requires a "socket file". My original app is not using a socket file. I was hoping to do this without interfering with the original app. Is a "socket file" required? How can I configure this to serve both apps? Never having done this, what will the new URL be? The URL for the admin site in both apps is 'admin/', how can I accommodate this? Thanks!
I combined into one file as you suggested and I am almost there! I have original site responding at [server_name]/inventory and new site responding at [server_name]/assets. Great! My only problem is the admin page. In both apps the admin site is called admin! So, [server_name]/admin brings up the original site. How can I get to the new admin page?
[Update]
I've managed to upload a small file (but not yet a large image). ../media/filer_public/ sub-directories are being correctly created and file correctly uploaded. Need to investigate nginx configurations.
[OP]
I've logged into a new Django CMS system as superuser but cannot Add filer image or Add filer file to a page as the file upload silently fails; very briefly flashing its upload graphics but not actually uploading anything. I believe all the settings.py are correct as static artifacts are rendered correctly and Nginx has credible similar locations for both media and static directories.
I believe all file and directory permissions and ownerships are correct; i.e. that Nginx has user and / or group ownership of the Django CMS app directories and that permissions are correct.
The Postgres table filer_folder has a row for a new filer folder I created when editing a page but no corresponding directory has been created in the file system. I can add text and new text block plugins that get saved correctly.
Django CMS is running in a Docker container web which I have confirmed has rw (read/write) access to a Docker volume.
I see nothing abnormal in webs logs.
How can I find out what's (not) happening?
Simply adding client_max_body_size 10M; to the nginx configuration for the site solved the issue.
Similar issues were addressed in Stackoverflow and elsewhere:
Server Fault
Setting up Django and your web server with uWSGI and nginx
Hy,
I am really new to Pimcore (I'm a joomla guy) and my friend asked me if I could help him transfer a page based on Pimcore to another server. I made a sql dump and copied all the files from the server to my hd and after that on the new server, imported the sql database, changed the username in the db and copied all the files back on the server. Also I made the correct changes for the db in the system.xml file in the config folder. But now all I get is a blank screen but the backend works partially (I can't see the files and the page). I would really appreciate some help!
Thanks in advance
Several things could go wrong, but start with checking:
MySQL user has access to the imported views. This is quite a common issue when importing views between servers,
Apache Linux user has read/write access to the whole website/var folder, access to /var/config is not enough. Pimcore writes cache files to website/var/cache for example.
You are missing mod_rewrite in apache, or your vhost does not allow override.
anytime a user logs into our Wiki they get the following error: "This Wiki uses cookies to log in users. You have cookies disabled. Please enable them and try again." Even though the error displays, the user is actually logged in and can make edits as normal. If the user doesn't look closely they can't tell they are logged in and it's causing confusion I would be glad if anyone gives me a hint
Wikimedia's advice is Check to make sure PHP's directory for storing session data is writable. This directory can be found in the php.ini file under the session.save_path setting. Errors in this php.ini setting can also cause other problems.
... (and) make sure the Internet Guest Account (eg. IUSR_FOOBAR, nobody, or apache) has write permissions to the folder listed in the session.save_path variable of the php.ini file.
Source.
If you are using a hosting site you need to edit your php scripting configuration (php.ini). The page should have information on your web document root. If there is already a "tmp" folder created then use it. If there is not a tmp folder in your current set up create one that is NOT browseable by users and tell the php.ini file the location as directed above.
For future reference... We just had a similar problem on Appropedia (same error, but couldn't log in at all). It turned out the temp directory was full. Cleared the temp directory, problem solved.
It turned out the temp directory was full
In my case it was because the entire partition was full, needed more space.
Problem I just had was due to default install of our PHP using C:\windows\temp as a base folder for PHP session and other data.
Of course, once someone empties out the temp folder because its full of junk .... the sub-folders for PHP information go with it too :\
If you are using NGINX + PHP-FPM the previous answers will likely not be of any assistance.
From the command line, run:
php-fpm -i|grep --color cookie_path
See what your cookie_path is, then stat the folder and ensure your php-fpm user has write access to it.
To resolve this issue using Nginx and Php-Fpm, I had to change my cookie_path from it's default of / (seriously, why would this be a default?) to /tmp.
After restarting nginx and php-fpm, it works perfectly.