Apache Friends Support Forum

macOS Big Sur 11.4
XAMPP 7.4.20-0

When I try to update WordPress 5.7.2 plugins WordPress ask for FTP info.
I have read that this is a permission issue.
I'm running my MacBook Air as standard user.
I have tried changing permissions from the Get Info menu on the htdocs folder and the wordpress folder inside htdocs folder. But every time I try to change the permission, the spinning wheel keep spinning. I get the feeling that the folder did not change permission.
I don't know what to do. I have tried solution from stack overflow
As you can see down below I tried channing permission but it didn't work
TERMINAL ------------------------
Last login: Sun Jul 18 14:16:28 on ttys002
% chmod 777 /Applications/XAMPP/xamppfiles/htdocs/
chmod: /Applications/XAMPP/xamppfiles/htdocs/: No such file or directory
END OF terminal ------------------------

XAMPP TERMINAL ------------------------
root@debian:~# chmod 777 /Applications/XAMPP/xamppfiles/htdocs/
chmod: cannot access '/Applications/XAMPP/xamppfiles/htdocs/': No such file or directory
root@debian:~#
END OF XAMPP TERMINAL ------------------------

XAMPP TERMINAL ------------------------
root@debian:~# chmod -R 0777 /opt/lampp/htdocs/
root@debian:~#
END OF XAMPP TERMINAL ------------------------

Remember I'm using MacBook Air as a standard user.

Your normal UserID does not have sufficient rights to create/write files in /opt/lampp/htdocs (thats how it is). There are multiple options to overcome that problem, for example start your editor via "sudo" (actually thats what the error message tells you!). Or change the file mode of htdocs so that everybody can write to it. Open a terminal an run this command:

sudo chmod 777 /opt/lampp/htdocs

You have to provide your password for "sudo". After then you can store all files into htdocs. Actually this is very basic linux knowlegde. Nothing special.

The error is too generic and does not tell you exact problem. What you need is to find out what is the real issue. If your site is serving a Internal Server Error, this can be caused by a number of things, such as:

Errors in .htaccess files
Server permission
Server timeout
Script timeout
Or some other Web Server Issues
Normally, a permissions issue on the file (or files) would be one cause of the 500 Internal Server Error. The simple solution is to run chmod 644 on the problem file(s) or chmod 755 on the directories.

$ sudo chmod -R 777 /"your files location"

The best way to debug the error depends upon the server and what’s actually running at the time. Consider some debugging tips to help diagnose and fix common causes of this problem.

http://net-informations.com/q/mis/500.html

fegie wrote:The solution from https://community.bitnami.com/t/bitnami-wordpress-mac-os-11-3-big-sur-error-starting-wordpress-stack/94776 worked for me (start from comment #9).
A new version of the hyperkit executable seems to do the trick.

Here is the direct link to it: https://community.bitnami.com/t/bitnami-wordpress-mac-os-11-3-big-sur-error-starting-wordpress-stack/94776/9
And the quoted solution from jota

jota wrote:Hi everyone,

The Bitnami team is currently working on updating the Bitnami OS X VM catalog fixing this problem. In the meantime, we’ve prepared a new hyperkit file that you can use in your installations. Please follow these steps to update the file:

Note: This is a testing file and it’s highly suggested to perform a backup of all the files under the .bitnami folder to recover them if something goes wrong.

• Take a backup of your current files
  

  Code: Select all

  cp -rp ~/.bitnami ~/.bitnami.back

• Download the new hyperkit binary
  

  Code: Select all

  cd /tmp
curl -LJO "https://downloads.bitnami.com/files/hyperkit/hyperkit-testing-20210430"

• Ensure that the md5 checksum matches with this one
  

  Code: Select all

  % md5 /tmp/hyperkit-testing-20210430
MD5 (/tmp/hyperkit-testing-20210430) = 37495adde6a3279dd7265904b85c3dc9

  
  

  Warning: Do not continue with the next step if the md5 checksum doesn’t match

  
  
• Replace your current hyperkit binary with the downloaded one
  

  Code: Select all

  mv /tmp/hyperkit-testing-20210430 ~/.bitnami/stackman/helpers/hyperkit
chmod +x ~/.bitnami/stackman/helpers/hyperkit

• Start the Bitnami OS X VM again and ensure you can access your application.
  

  Note: If you get a security warning regarding the new hyperkit binary not being signed, go to Security under System Preferences and allow its execution. Restart the OS X VM if necessary

Happy to help!

tch7227 wrote:i am new here, so hopefully i'm doing well...
I had the same issue and i found a solution or workaround for me and maybe it will help you as well.
read everything before you try it out and of course no guarantee...

1. I converted my vm data (~/.bitnami/stackman/machines/xampp/vm/machine.qcow2) from qcow2 to vmdk (as end1an described)

Code: Select all

qemu-img convert -f qcow2 -O vmdk machine.qcow2 ~/Downloads/machine.vmdk

(for installing qemu - https://www.qemu.org/download/#macos - I used homebrew - https://brew.sh)
2. I changed the machine.vmdk to machine.zip and extracted it (also with keka - https://www.keka.io/en/)

3. i installed xampp 7.4.16 for macOS with the installer (not vm)
4. I copied my projects from the old restored /opt/lampp/htdocs folder to the new one /Applications/XAMPP/xamppfiles/htdocs
5. I copied my projects database folders + phpmyadmin from the old restored /opt/lampp/var/mysql/ folder to the new one /Applications/XAMPP/xamppfiles/var/mysql
6. i copied ibdata1, ib_logfile0, ib_logfile1 from the old restored /opt/lampp/var/mysql/ folder to the new one /Applications/XAMPP/xamppfiles/var/mysql
7. i copied db.myd, db.myi, db.frm and proc.myd, proc.myi, proc.frm from the old restored /opt/lampp/var/mysql/mysql/ folder to the new one /Applications/XAMPP/xamppfiles/var/mysql/mysql/ (I'm not sure if this step is a must, but I did it...)
8. i fixed the file/folder permissions/rights for the files I copied to mysql or mysql/mysql to the same like the others in these folders with the terminal (for changes I used sudo chown -R _mysql [file or folder], sudo chgrp -R _mysql [file or folder], sudo chmod -R 770 [file or folder] and ls -l for listing) - be carful by changing rights

after restarting mysql it worked (before I used a err log file to see why the mysql server didn't start /Applications/XAMPP/xamppfiles/var/mysql/usersname-macbookname.local.err) ... some project Wordpress settings are lost (I don't no why, but nothing important for me) and the link to the localhost is now localhost without port :8080 ...

AT LEAST I've got all my databases, files, folders etc - good luck

some more links I used:
https://stackoverflow.com/questions/29258769/how-to-restore-mysql-database-in-xampp
https://superuser.com/questions/1328965/how-to-restore-mysql-database-using-files-on-data-folder
https://stackoverflow.com/questions/38759870/xampp-mysql-table-doesnt-exist-in-engine-1932/44799226

Thanks for the solution. It really works

i am new here, so hopefully i'm doing well...
I had the same issue and i found a solution or workaround for me and maybe it will help you as well.
read everything before you try it out and of course no guarantee...

1. I converted my vm data (~/.bitnami/stackman/machines/xampp/vm/machine.qcow2) from qcow2 to vmdk (as end1an described)

Code: Select all

qemu-img convert -f qcow2 -O vmdk machine.qcow2 ~/Downloads/machine.vmdk

(for installing qemu - https://www.qemu.org/download/#macos - I used homebrew - https://brew.sh)
2. I changed the machine.vmdk to machine.zip and extracted it (also with keka - https://www.keka.io/en/)

3. i installed xampp 7.4.16 for macOS with the installer (not vm)
4. I copied my projects from the old restored /opt/lampp/htdocs folder to the new one /Applications/XAMPP/xamppfiles/htdocs
5. I copied my projects database folders + phpmyadmin from the old restored /opt/lampp/var/mysql/ folder to the new one /Applications/XAMPP/xamppfiles/var/mysql
6. i copied ibdata1, ib_logfile0, ib_logfile1 from the old restored /opt/lampp/var/mysql/ folder to the new one /Applications/XAMPP/xamppfiles/var/mysql
7. i copied db.myd, db.myi, db.frm and proc.myd, proc.myi, proc.frm from the old restored /opt/lampp/var/mysql/mysql/ folder to the new one /Applications/XAMPP/xamppfiles/var/mysql/mysql/ (I'm not sure if this step is a must, but I did it...)
8. i fixed the file/folder permissions/rights for the files I copied to mysql or mysql/mysql to the same like the others in these folders with the terminal (for changes I used sudo chown -R _mysql [file or folder], sudo chgrp -R _mysql [file or folder], sudo chmod -R 770 [file or folder] and ls -l for listing) - be carful by changing rights

after restarting mysql it worked (before I used a err log file to see why the mysql server didn't start /Applications/XAMPP/xamppfiles/var/mysql/usersname-macbookname.local.err) ... some project Wordpress settings are lost (I don't no why, but nothing important for me) and the link to the localhost is now localhost without port :8080 ...

AT LEAST I've got all my databases, files, folders etc - good luck

some more links I used:
https://stackoverflow.com/questions/29258769/how-to-restore-mysql-database-in-xampp
https://superuser.com/questions/1328965/how-to-restore-mysql-database-using-files-on-data-folder
https://stackoverflow.com/questions/38759870/xampp-mysql-table-doesnt-exist-in-engine-1932/44799226

Hi,
You should go 'Open Terminal' on Xampp Panel.. Then, You can write 'chmod 777 /opt/lampp/phpmyadmin/config.inc.php' in terminal. (without quotes)
After you've done your editing, type 'chmod 644 /opt/lampp/phpmyadmin/config.inc.php' and then type 'exit' and restart Xampp.

One more thing, I am also having the 1045 error, but editing in the config file did not solve my problem. I don't think this change will fix the problem.

hello and good day - dear community,

risks on hosting wordpress - with the wrong configuration - note: weve discussed this bout 1.5 years ago. from time to time its a good idea to refresh the discussion again...

this discussion helps to make up ideas, and mindet - if it gives some ideas to others - i am happy. I am the one who benefits from writing about these mattes - i am benefiting the most!!

for all those who may be tired of re-reading these kinds of stuff - a big big SORRY - hopefully some of you might find it helpful


regards... unleash




When working with WordPress in a more secure environment where websites are not entirely world-writable,

you will notice upgrades request FTP or FTPS credentials as the server itself does not typically have write access in properly-configured environments. Entering these credentials for every upgrade can become quite tedious, and WordPress has implemented some constants you can define within wp-config.php to make upgrades automatic.

It should be noted here that you can also make upgrades automatic by setting the file ownership of all files within the WordPress directory to the same user/group under which the webserver is running. THIS IS HORRIBLE SECURITY PRACTICE!

While storing your FTP credentials for a specific user can also be considered insecure in certain instances, it can be a very safe method to automate WordPress updates under the proper conditions. Some general considerations which can make stored credentials MUCH more secure include:

end of cit: see more here https://www.serverstack.com/blog/2013/0 ... r-ssh/0020


well can you advice me

– what is needed to run the automated updates of plugins!?
– do i need to have suPHP enabled
– what else do i need to have?


by the way
– i need to have a overview on all necessary conditions and things…. – there a plugin suggests to get done all the things – i t is called infinitewp – but i guess that – to run this – i need to have the horrible server conditions too!?[/quote]





update: Well i want to dig into the processes of the automatic-update: at the moment my server does not fullfill the needs that are mandantory to be met if one wants to run the automatic-updates:

Well in this posting i want to gather togehter all i can get - to understand these porcesses - in order to dive into this technique and to enlarge my understanding: the Wordpress site had been automatically updated to the latest version. I knew about the feature but I've always wondered exactly how it works. Therefore i gathered some information about hte update-process how it works and which credentials at serverside we need.

furthermore i have found some ideas about a shorter way to automatically update WordPress? here some infos on the updating WordPress plugins, there’s a prompt for the FTP login:

Connection Information:
To perform the requested action, WordPress needs to access your web server. Please enter the FTP credentials to proceed.
If we do not remember the credentials, we should contact our web host.
Hostname: host
FTP Username: user
FTP Password: pass
Connection Type: FTP or FTPS (SSL)

This will work fine, except if it’s host uses SFTP over SSH with Port 22.
Failed to connect to FTP Server host:21
It will attempt to always use port 21 as well.
This is the user’s permission problem.

step-1: First open wp-config.php file of your WordPress installation folder.
step-2: Copy below code and paste it at the end of the wp-config.php file.

define('FS_METHOD','direct');

we need to make sure ownership permissions are set to Apache so that WordPress can update and/or
install plugins without requiring FTP credentials. We can set permissions via SSH.

Single site hosting:
chown -R apache:apache /var/www/html
basically, it’s easy to set up wordpress-server to do the automated update:

- Permissions in the wordpress tree: 755 on directories, 644 on files.
- Ownership of files: The same user under which PHP is running

Once we have that, WP is able to update itself. By default, that means it will do minor update (e.g., 5.2.3 to 5.2.4),
but not major ones (5.2.x to 5.3.x), nor will it auto-update plugins. We can add constants to wp-config.php for core updating.
See https://wordpress.org/support/article/e ... re-updates.

For auto-updating themes and plugins, see https://www.wpbeginner.com/plugins/how- ... s-plugins/
Also a good read https://wordpress.org/support/article/e ... -constants

here i found a shorter way to automatically update WordPress?
cf: https://wordpress.stackexchange.com/que ... -wordpress

This is how we can start to update WordPress daily:

Code: Select all

cat <<-"CRON_DAILY" > /etc/cron.daily/nses_cron_daily
    for dir in /var/www/html/*/; do cd "$dir" && /usr/local/bin/wp plugin update --all --allow-root; done
    for dir in /var/www/html/*/; do cd "$dir" && /usr/local/bin/wp core update --allow-root; done
    for dir in /var/www/html/*/; do cd "$dir" && /usr/local/bin/wp theme update --all --allow-root; done
    chown www-data:www-data /var/www/html/* -R
    find /var/www/html/* -type d -exec chmod 755 {} \;
    find /var/www/html/* -type f -exec chmod 644 {} \;
CRON_DAILY
chmod +x /etc/cron.daily/nses_cron_daily


I create the file with the heredocument, change permissions, and run daily.
Is there a shorter, pluginless way to update (less rows, hahaha)?
Update: I didn't change basically anything inside wp-config.php besides database credentials.

the Wordpress site had been automatically updated to the latest version. I knew about the feature but I've always wondered exactly how it works. PHP isn't a permanently-running process: it only runs when requested. So as far as I can tell, Wordpress can only update itself when someone loads a web page. But the update process is not instantaneous, so surely a user visiting the site would have a really slow page load. Is there a different trick they use for automatic updates? I've searched all over the place but haven't found any explanation.

some more into depth going details on the auto-update-process: the automatic update is pushed from wp.org. The update process still runs on our site, but in the background via wp-cron.
When a new minor update is released, the guys at WordPress start to roll out the update. The actual update process is started after our site checked wp.org for updates, an update is theoretically available, and our site is chosen by random to be updated. As every site checks with wp.org for new versions (usually twice dayily using wp-cron), the rolloutserver knows how many sites need an update. Then the rollout begins, starting slowly - 1 out of 128 sites gets updated automatically. This is being monitored, and if the successrate indicates no problems with the rollout, more of the sites get the automatic update (usually the next step would be 1 out of 64, and continuing to increase that way) until all automatic updates are delivered.
This enables the developers to stop the rollout if any problems occur, but the last update from 3.8 to 3.8.1 has had a 100% success rate. The sites selected by the 1 out of 128 is actually random. Well, not really, but if you want to know, it works like this: The Url of the site needing an update gets hashed using MD5. Using just the first three characters of this hash and converting it to base10, this results in 4096 possibilities. The update started for sites having a calculated number between 0 and 31 (4096 / 32 = 128).

cf: https://wordpress.stackexchange.com/que ... dates-work

and futhtermore i found more infos:

WordPress Automatic Updates :: There are four typologies of updates and WordPress automatic updates:

Core updates
Plugin updates
Theme updates
Translation files updates
Core updates are divided into three sub-typologies:

Core development (only available for development installations)
Minor core updates (maintenance and security) – enabled by default in stable installations
Major core updates
WordPress allows us to automate the update process for any of these typologies providing two wp-config.php constants and a good number of API filters.

Controlling Background Updates Through wp-config.php
WordPress provides a couple of wp-config.php constants that allow us to control auto-updates. Setting AUTOMATIC_UPDATER_DISABLED to true will disable any kind of automatic upgrade:

define( 'AUTOMATIC_UPDATER_DISABLED', true );
WP_AUTO_UPDATE_CORE allow us to control core updates (minor, major and development releases). This constant can be defined as follows:

# Disables all core updates:
define( 'WP_AUTO_UPDATE_CORE', false );

# Enables all core updates, including minor and major:
define( 'WP_AUTO_UPDATE_CORE', true );

# Enables minor updates:
define( 'WP_AUTO_UPDATE_CORE', 'minor' );
In development installations WP_AUTO_UPDATE_CORE defaults to true. In stable installations it defaults to minor.

For the sake of completeness, I should mention an additional constant that can be defined to disable auto-updates. However, setting its value to true will disable any file edits, even themes and plugin installations and manual updates.

define( 'DISALLOW_FILE_MODS', true );
Instead, you may prefer to define the DISALLOW_FILE_EDITS constant, which would disable the file editor, but keeping safe the installation and update functionalities.

Related tutorial: wp-config.php File – An In-Depth View on How to Configure WordPress

Controlling Background Updates Through API Filters
Configuration constants provide a general way to enable or disable auto-updates. But WordPress provides a number of filters which grant a deeper control over any kind of updates.

Note: Filters should be used within plugins, and “must use plugins” are a good option for background updates. mu-plugins reside in a specific folder inside /wp-content and are automatically enabled by WordPress. These plugins do not appear in WordPress Plugins Screen, so they could not be accidentally disabled or removed by the site admins. For a deeper view, refer to the Codex documentation

First, returning true through the automatic_updater_disabled filter has the same effect as defining the AUTOMATIC_UPDATER_DISABLED constant to true in wp-config.php:

add_filter( 'automatic_updater_disabled', '__return_true' );
We can control any of the update typologies through the auto_update_$type filters which enable or disable updates depending on the value of $type ('core', 'plugin', 'theme' or 'translation').

So, we can automate all core updates by returning true through the auto_update_core filter:

Code: Select all

add_filter( 'auto_update_core', '__return_true' );
In the following example, we’re enabling automatic updates for themes, plugins and translations:

add_filter( 'auto_update_theme', '__return_true' );
add_filter( 'auto_update_plugin', '__return_true' );
add_filter( 'auto_update_translation', '__return_true' );
In the examples above we’ve ju st enabled auto-updates. But these filters give us a greater control over updates. In the following example we’re automating auto-updates for two specific plugins:

function cb_auto_update_plugins ( $update, $item ) {
   $plugins = array ( 'hello', 'akismet' );
   if ( in_array( $item->slug, $plugins ) ) {
      // update plugin
      return true;
   } else {
      // use default settings
      return $update;
   }
}
add_filter( 'auto_update_plugin', 'cb_auto_update_plugins', 10, 2 );
The callback function keeps two arguments:


$update: a boolean which sets wether to update or not;
$item: the update offer object. The function checks wether the item to update is in $plugins array, then returns true or false accordingly.

Last, we can make difference between development, minor and major updates, by returning true or false through the following filters:

Code: Select all

add_filter( 'allow_dev_auto_core_updates', '__return_false' );
add_filter( 'allow_minor_auto_core_updates', '__return_true' );
add_filter( 'allow_major_auto_core_updates', '__return_true' );
We know that occasionally an update can fail. In the worst case, the website can go down after an update failure. But luckily we can ask WordPress to notify us with an email after any update (or attempt).


suPHP is a tool for executing PHP scripts with the permissions of their owners. It consists of an Apache module (mod_suphp) and a setuid root binary (suphp)

but generally speaking bout the Automatic WordPress Updates Using FTP/FTPS or SSH - in a more secure environment

Introduction When working with WordPress in a more secure environment where websites are not entirely world-writable, you will notice upgrades request FTP or FTPS credentials as the server itself does not typically have write access in properly-configured environments.

cf https://www.serverstack.com/blog/2013/0 ... or-ssh/20/

Entering these credentials for every upgrade can become quite tedious, and WordPress has implemented some constants you can define within wp-config.php to make upgrades automatic.
It should be noted here that you can also make upgrades automatic by setting the file ownership of all files within the WordPress directory to the same user/group under which the webserver is running. THIS IS HORRIBLE SECURITY PRACTICE! While storing your FTP credentials for a specific user can also be considered insecure in certain instances, it can be a very safe method to automate WordPress updates under the proper conditions. Some general considerations which can make stored credentials MUCH more secure include:

FTP:
1. Creating a separate user and restricting its access to only allow connections from localhost
2. Ensuring your FTP daemon is “chrooting” the user to their own directory only
3. Configuring your FTP daemon to listen only on localhost, thus preventing external connections
4. Using something more secure than FTP, such as SSH — Yes, we realize this one does not actually improve FTP security

SSH:
1. Creating a separate user (usually an alias with the same UID, different GID) and restricting access to only localhost for this specific user in sshd_config with the AllowHosts option
2. Creating some advanced SSH configuration such as chrooted SFTP-only users
3. Using public key authentication, which can be further secured by specifying a “from” address in the user’s authorized_keys file

There are several other ways one can make their FTP/FTPS or SSH setup more secure, but they are far beyond the scope of this post and can vary greatly in their application due to the hosting environment and several other factors. We are going to assume you’re already working with a secure setup for the purposes of this guide.

again Well in this posting i want to gather togehter all i can get - to understand these porcesses - in order to dive into this technique and to enlarge my understanding: the Wordpress site had been automatically updated to the latest version. I knew about the feature but I've always wondered exactly how it works. Therefore i gathered some information about hte update-process how it works and which credentials at serverside we need


Nemesis wrote cf: viewtopic.php?f=2&t=78850&p=266927&hilit=wordpress+suphp#p266927

....or short, a cronjob runs (normaly) on the host that should perform an action from time to time. So, when you allowed to use cronjobs on your site - that are running your wordpress installation - you don't must deal with an ftp/rsh/scp remote file connection, to update the files at your own.
Before you do automated updates, it would be better to do a backup of your wordpress installation. The files in your webserver Documentroot (apache) and the database tables of your wordpress installation. Also do from time to an checkup of your backups, that those are realy functional and could be rolled out on another webspace.
Practice that, when you are responsible for that installation.
With ZFS and i guess btrfs (Linux) too, you can also do snapshots of your filesystem.

Moin,

die ".eml"-Dateien sind "Base64" kodiert.
Da bringt es nicht viel denen eine andere Endung zu geben.
Hier mal das Script:

Code: Select all

#!/bin/sh
prefix="/opt/lampp/htdocs/sendmail/new"
numPath="/opt/lampp/htdocs/sendmail"

if [ ! -f $numPath/email_numbers ]; then
echo "0" > $numPath/email_numbers
fi
emailNumbers=`cat $numPath/emailNumbers`
emailNumbers=$(($emailNumbers + 1))
echo $emailNumbers > $numPath/emailNumbers
name="$prefix/letter_$emailNumbers.eml"
while IFS= read line
do
echo "$line" >> $name
done
chmod 666 $name
/bin/true


Wenn ich der Crack in Linux wäre, dann würde ich wahrscheinlich eine Lösung hin husten, bin ich aber nicht und deshalb frage ich.

Gruß Heiko

P.S. Warum wurde aus zwei Themen eines gemacht? Wenn ich die Lösung für Thema 1 habe und das Thema dann als gelöst setzen will, geht das jetzt nicht mehr. Ich dachte, eine Frage/Problem gleich ein Beitrag und nicht viele Frage in einen Beitrag.

Currently using 8.0.0-2-vm on Mac 11.1.

I had a previously running version of XAMPP-VM that stopped after the upgrade to Big Sur. Instead of searching here, I first tried reinstalling, only I stupidly replaced my previous VM version with the non-VM version. This resulted in me losing my Wordpress installation. Not too worried because I have the database backed up.

I uninstalled the erroneous non-VM version and removed the ~/.bitnami folder just to be sure. Downloaded 8.0.0-2-vm and ran the installation. After install, I can start the stack, start all the services, mount the /opt/lampp directory, etc. I can open phpmyadmin at localhost:8080/phpmyadmin.

I followed the instructions at https://www.apachefriends.org/faq_stackman.html to re-install Wordpress. I downloaded the linux version which was named bitnami-wordpress-5.6-0-module-linux-x64-installer.run. I mounted /opt/lampp and copied that file into /opt/lampp/temp. Then I used the General tab to open a terminal and ran the following:

Code: Select all

cd /opt/lampp/temp
chmod +x bitnami-wordpress-5.6-0-module-linux-x64-installer.run
./bitnami-wordpress-5.6-0-module-linux-x64-installer.run

I mainly gave the default answer to all questions, chose a username and blog title, etc. Everything was fine until I hit Y to complete the installation. At the end, I see the following error:

Code: Select all

Warning: Problem running post-install step. Installation may not complete
correctly
 Error running /opt/lampp/bin/php -c "/opt/lampp/etc"
"/opt/lampp/apps/wordpress/scripts/setup.php": child process exited abnormally
Press [Enter] to continue:

At this point, I press enter, and it asks if I want to start the wordpress module. I select Y, but afterwards there is no wordpress instance running as far as I can tell. http://localhost:8080/wordpress auto changes to just localhost/wordpress and reports "connection refused." https://localhost:8443/wordpress (also enabled in the stack) reports "Error establishing a database connection."

If I run the installer again, it completes without error, but I still can't connect to the wordpress module.

Code: Select all

ps aux | grep word

shows no wordpress instance running, although I'm not sure if that's what it would call itself. I ran just a ps aux and didn't see anything that looked like wordpress, but I could have missed it.

I've tried completely deleting the XAMPP install including the ~/.bitnami folder, but after reinstallation the error persists. I think I'm missing something in the uninstall, because each time I reinstall XAMPP the IP address of the XAMPP stack increments by 1. Clearly there's some configuration out there that is left behind, and I'm not sure if that's throwing off the process.

Any ideas how to proceed from here?

Altrea wrote:PHP uses plain operating system file operations to access files. So please double check your folder and file permissions for the user Apache is running with.

Thank you for the reply!

Checked file info for all folders and files: all lines (including "everyone") have "read & write".
Checked CHMOD via terminal: all files and folders are 777.

For whatever reason anything outside htdocs folder regardless of permissions being OK and (absolute) paths also being correct I cannot reach the files.

Edit:

Altrea wrote:P.S.: You seem to use the VM version of XAMPP on your Mac OS. A virtual machine is a capsuled system and does have limited access to files outside of this bubble.
I would switch to the installer version.

Oh, wow, so that is what I've been missing! Simply downloaded off the website and did not even know there were another option before I searched specifically for it. I'll give it a try and see how it goes. Does seem logical though, that a VM could cause such issues.

Edit 2:
Yup, after getting the installer version everything works just fine. Too bad the VM version is offered as the default download and I lost so many hours over it but at least now I can move on. Thank you!

Hi,

nucleoest wrote:CHMOD and access rights for logs seem to be fine and not causing this. Also, the paths to files are real (checked times and times again) and working (for example can access via terminal using the same paths). It simply seems that XAMPP is unable to get to anything outside the htdocs folder and after hours of searching I haven't been able to find anything that could help.

PHP uses plain operating system file operations to access files. So please double check your folder and file permissions for the user Apache is running with.

P.S.: You seem to use the VM version of XAMPP on your Mac OS. A virtual machine is a capsuled system and does have limited access to files outside of this bubble.
I would switch to the installer version.

Hi,

I am using XAMPP 8.0.0 and currently testing on MacOS 11.0.1 (though later live version would use an older version of MacOS, still the issue is the same there).

I developed an app on XAMPP 8.0.0 and running Windows 10. Everything works just fine. The app grabs some log files and then does its thing with them. On Windows option the log files were copied to htdocs folder for testing. Now, when I moved the app to the live machine on MacOS, the app works but it cannot reach the files that now lie outside the htdocs folder (admittedly I did not test for a similar situation on Windows but that is not so important because I need this to work on MacOS).

Config (program and log file names changed):

Code: Select all

// live/development specific settings
if(LIVE) {
    // If site in live mode
    define('SPOOLER_LOG_FILE', '/opt/program_name/var/tmp/logfile.log');
} else {
    // If site is in development mode
    define('SPOOLER_LOG_FILE', 'C:/xampp/htdocs/logfile.log');
}

The code breaks when I use file_exist() function to check things before continuing:

Code: Select all

// Get the log file location and Load the log file contents into an array
if(file_exists(SPOOLER_LOG_FILE)) {
    $spooler_log_array = load_tabbed_file(SPOOLER_LOG_FILE);
} else {
    die('LOG NOT FOUND!');
}

Though running load_tabbed_file() function directly doesn't work, either.

Only time when I got the log file to load was when I copied one under htdocs but IRL that is not a solution since I need the code to reach into the program folder where the log files actually are and are updated.

I also tried creating symlinks with no luck as well, which seems a bit odd since it should work the same as as copying the actual file to htdocs that did work but since I know server config/htaccess has some symlinks settings as well, perhaps that could cause this (though config by default seems to support symlinks but I am not very familiar with this topic).

CHMOD and access rights for logs seem to be fine and not causing this. Also, the paths to files are real (checked times and times again) and working (for example can access via terminal using the same paths). It simply seems that XAMPP is unable to get to anything outside the htdocs folder and after hours of searching I haven't been able to find anything that could help.

XAMPP is pretty much in standard configuration, only added access to phpMyAdmin and changed the root password.

Log: /opt/program_name/var/tmp/logfile.log
htdocs: /opt/lampp/htdocs (or /Users/username/.bitnami/stackman/machines/xampp/volumes/root/htdocs as I grab the path via terminal)
And there is another folder I need to access as well with several XML and JPG files but same deal: /opt/program_name/var/jobs/foldername

I feel like slowly going mad over this and pretty sure someone can tell me what is the obvious I am missing here. Here's hoping.

Cannot install xampp-linux-x64-8.0.0-2-installer.run on Ubuntu 20.04.1 LTS 64bit under VMware Workstation 15 Player

sudo chmod 755 xampp-linux-x64-8.0.0-2-installer.run
sudo sh xampp-linux-x64-8.0.0-2-installer.run
xampp-linux-x64-8.0.0-2-installer.run: 1: ELF: not found
xampp-linux-x64-8.0.0-2-installer.run: 5: Syntax error: "(" unexpected

Hallo,
ich habe Probleme bei der Installation von XAMPP unter Linux mit der Distro TwisterOS. Ich habe mir auf der Apache Webseite die neueste Version xampp-linux-x64-7.4.11-0-installer.run runtergeladen. Die .run Datei ist im Ordner pi/Downloads

Dann habe ich im Terminal folgende Befehle eingegeben:

pi@mustermann: cd ~/Downloads
~/Downloads $ chmod 755 xampp-linux-x64-7.4.11-0-installer.run
~/Downloads $ sudo ./xampp-linux-x64-7.4.11-0-installer.run

dann kommt die Fehlermeldung:

./xampp-linux-x64-7.4.11-0-installer.run: 1: ./xampp-linux-x64-7.4.11-0-installer.run: ELF: not found
./xampp-linux-x64-7.4.11-0-installer.run: 5: ./xampp-linux-x64-7.4.11-0-installer.run: Syntax error: "(" unexpected

Mit ls -l habe ich nochmals die rechte kontrolliert:
-rwxr-xr-x 1 pi pi 156416206 Nov 6 13:48 xampp-linux-x64-7.4.11-0-installer.run

Wo liegt der Fehler hier?
Danke schon mal im voraus für Eure Hilfe

lg pietropizzzi