Support

Akeeba Solo

#28511 Unable to exclude missing symlink

Posted in ‘Akeeba Solo (standalone)’
This is a public ticket

Everybody will be able to see its contents. Do not include usernames, passwords or any other sensitive information.

Environment Information

PHP version
n/a
Akeeba Solo version
n/a

Latest post by on Wednesday, 15 November 2017 17:17 CST

sebtombs
Hi. Thanks for a great product. However, we are having a problem with Solo on a site which has a quirk. The site has a directory symlink which is not accessible by Apache (a feature of the way the hosting provider manages MySQL backups).

I had thought that I should be able to avoid getting a warning by adding the directory to the exclude list, but it doesn't seem to work.

The backup is executed as a cron job.

I get (with sitebase hidden):

Akeeba Solo CLI 2.4.0 (2017-09-12)
Copyright (C) 2014-2017 Nicholas K. Dionysopoulos / Akeeba Ltd
-------------------------------------------------------------------------------
Akeeba Solo is Free Software, distributed under the terms of the GNU General
Public License version 3 or, at your option, any later version.
This program comes with ABSOLUTELY NO WARRANTY as per sections 15 & 16 of the
license. See http://www.gnu.org/licenses/gpl-3.0.html for details.
-------------------------------------------------------------------------------
You are using PHP 5.6.12 (cli)

Starting a new backup with the following parameters:
Profile ID  1
Description "Command-line backup"

Current memory usage: 3.32 MB

Unsetting time limit restrictions.

Site paths determined by this script:
APATH_BASE : <sitebase>/public_html/akeeba
Last Tick   : 2017-09-25 05:00:26 GMT+0000 (UTC)
Domain      : init
Step        : 
Substep     : 
Memory used : 6.57 MB
Warnings    : no warnings issued (good)

...

Lots of good backup lines

...

Last Tick   : 2017-09-25 05:00:43 GMT+0000 (UTC)
Domain      : Packing
Step        : 
Substep     : 
Memory used : 7.64 MB
Warnings    : no warnings issued (good)

Last Tick   : 2017-09-25 05:01:06 GMT+0000 (UTC)
Domain      : Packing
Step        : <sitebase>/vendor/passwordlib/passwordlib/lib/PasswordLib/Random/Source
Substep     : 
Memory used : 7.68 MB
Warnings    : POTENTIAL PROBLEMS DETECTED; 1 warnings issued (see below).
	The symlink <sitebase>/mysql_backups points to a file or folder that no longer exists and will NOT be backed up.


Last Tick   : 2017-09-25 05:01:10 GMT+0000 (UTC)
Domain      : Packing
Step        : <sitebase>/vendor/erusev/parsedown/test/data
Substep     : 
Memory used : 7.69 MB
Warnings    : no warnings issued (good)

...

Lots more good backup lines

...

Backup job finished successfully after approximately 8 minutes 

===============================================================================
!!!!!  W A R N I N G  !!!!!

Akeeba Backup issued warnings during the backup process. You have to review them
and make sure that your backup has completed successfully. Always test a backup with
warnings to make sure that it is working properly, by restoring it to a local server.
DO NOT IGNORE THIS MESSAGE! AN UNTESTED BACKUP IS AS GOOD AS NO BACKUP AT ALL.

===============================================================================
Peak memory usage: 11.33 MB



Does the piece of code that checks whether something actually exists run before the exclude list is considered, or have I somehow got something wrong in specifying the exclude?

The backup restores OK but when the cron output is checked we pick up the warning every time, so it would be good if this could be prevented if possible.

tampe125
Akeeba Staff
Hello,

can you please attach the screenshot on how you are excluding such directory?
Are you completely excluding it, or just its contents?

Davide Tampellini

Developer and Support Staff

🇮🇹Italian: native 🇬🇧English: good • 🕐 My time zone is Europe / Rome (UTC +1)
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

sebtombs
Hi Davide. I thought it was completely excluded - please see screenshot.

tampe125
Akeeba Staff
I'm sorry, but I can't replicate the issue.
I'll talk with Nicholas tomorrow when he gets back in the office.

Davide Tampellini

Developer and Support Staff

🇮🇹Italian: native 🇬🇧English: good • 🕐 My time zone is Europe / Rome (UTC +1)
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

sebtombs
Hi Davide. Any feedback from Nicholas?

All the best,

Mark

nicholas
Akeeba Staff
Manager
Sorry, there was a miscommunication between me and Davide.

I have seen that in the past, a few years ago. I believe that the only way to prevent the backup engine from trying to back up the symlink is having an exclusion filter set up manually for it but as a file. You can do that in the Summary View. Create a new Exclude File filter with the target set to mysql_backups Please note that you may have to disable following symlinks for this to work.

This has to do with the inconsistent file type function results in PHP when you have a symlink whose target is inaccessible. From PHP's perspective it's unclear if it's a broken symlink, an inaccessible symlink and whether it points to a file or folder, leading to much confusion. Let's just say that my hairline suffered because of that.

In any case, if you cannot exclude that it's not the end of the world either. You just have to ignore this one warning.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

sebtombs
Thanks Nicholas. I tried adding the file exclusion and am still getting the warning, as you suspected may be the case.

Just to confirm - to stop symlinks being followed, I need to tick the "Dereference symlinks" box in the JPA format archiver settings?

All the best,

Mark

nicholas
Akeeba Staff
Manager
Just to confirm - to stop symlinks being followed, I need to tick the "Dereference symlinks" box in the JPA format archiver settings?


No. This option tells Akeeba Backup to follow the symlinks as if they were real folders. Since the folder doesn't exist it would cause an error about the folder being unreadable and you'd still be unable to exclude it.

We want symlinks to be treated as symlinks, therefore you need to uncheck (clear) this options.

As for your issue, I'm afraid there's not much we can do about it. As I explained it has to do with how PHP reports this filesystem entity for reasons that ultimately have to do with the filesystem itself. Properly dealing with this issue would require the filesystem reporting information about the symlink target even though it's unreachable by the system user (thus violating security principles). The filesystem correctly doesn't provide that information so PHP cannot provide accurate information about this particular symlink either.

From Akeeba Backup's point of view that's the same as a symlink pointing to an inexistent file/folder, therefore it reports it as such. This precedes filtering since the confusing information returned by PHP is evaluated when generating the file listing which will be used as input to the filtering function. If we don't report these errors to the user then the user does not have a clue when their backup is incomplete because filesystem entities were unreachable. That would be a bug.

So from a security and trust perspective everyone is doing the right thing. Unfortunately that leads to a persistent warning because your host elected to do something absolutely silly (create an unreachable symlink inside your web accessible root) instead of doing the logical thing of storing private log files in a folder outside the web root. Well, there's nothing you or we can do except ignore that warning - and quite possibly have a talk with the people responsible for the existence of that symlink, explaining to them that it's pointless and troublesome, so can they please kill it with fire.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

System Task
system
This ticket has been automatically closed. All tickets which have been inactive for a long time are automatically closed. If you believe that this ticket was closed in error, please contact us.

Support Information

Working hours: We are open Monday to Friday, 9am to 7pm Cyprus timezone (EET / EEST). Support is provided by the same developers writing the software, all of which live in Europe. You can still file tickets outside of our working hours, but we cannot respond to them until we're back at the office.

Support policy: We would like to kindly inform you that when using our support you have already agreed to the Support Policy which is part of our Terms of Service. Thank you for your understanding and for helping us help you!