Extend the storage of WD MyCloud with external USB hard drive for Mac Users

Home backup solution WD MyCloud provides simple approach to extend the size of storage by attaching additional external hard drive through its USB port. 

First, take a look at what partition format of USB hard drive is supported by WD MyCloud:

My Cloud: External USB Drive Supported File Systems

The table lists the USB drive file systems supported on the My Cloud products.

Note:

exFAT support requires firmware version 2.21.111 and higher exFAT with EFI System Partitions are not supported and will result in "Unable to mount USB device" message

My Cloud device	NTFS	HFS+	FAT32	exFAT
My Cloud	✔	✔	✔
My Cloud Mirror	✔	✔	✔
My Cloud Mirror Gen2	✔	✔	✔
My Cloud EX2	✔	✔	✔
My Cloud EX4	✔	✔	✔
My Cloud EX2 Ultra	✔	✔	✔	✔ *
My Cloud EX2100	✔	✔	✔	✔ *
My Cloud EX4100	✔	✔	✔	✔ *
My Cloud DL2100	✔	✔	✔	✔ *
My Cloud DL4100	✔	✔	✔	✔ *
My Cloud PR2100	✔	✔	✔	✔ *
My Cloud PR4100	✔	✔	✔	✔ *

The best Partition Format of all?

Choosing a partition format for external USB hard drive can be confusing for home users. Consider yourself using Windows or MacOS, the type of filesystem format would have impact on daily backup and the maintenance in case of drive failure. Default format of WD products (external USB hard drive) mostly comes with NTFS partition. Windows users may not aware of such difference until they switch to use Mac computer for home use. 

MacOS doesn't come with stable support (for free, I mean) of READ/WRITE operations to NTFS partition. So, the best bet is to reformat the external drive to HFS+ for better support. If you mainly work on MacOS platform then HFS+ would be your best choice. This takes consideration of easier maintenance and recovery using Apple computer.

People may ask if FAT32 or exFAT would be more appropriate for cross platform support among Windows and Mac computers. FAT32 partition is limit to store files whereas each file has a limit in size less than 4GB. exFAT doesn't have such limit. However, exFAT is not journaled filesystem so the chances of data loss in case of power outage is bigger than journaled filesystem like NTFS and HFS+. We are talking about hard drive running on 24/7 basis.

For reliable choices, we have now limited to NTFS and HFS+. Luckily, nearly all WD MyCloud products support both of these journaled filesystems. For Mac Users, HFS+ is definitely a good choice for extending NAS storage. In case of MyCloud server failure, the chances to recover data from HFS+ partition is higher than that from NTFS partition.

HFS+ is so far the most reliable filesystem with Time Machine support across different MacOS versions. Newer filesystem APFS has just officially supported since Big Sur. Older MyCloud products don't even support APFS. For backward compatibility, HFS+ is still the best choice as storage media.

What about Multiple Time Machine backups on WD MyCloud?

WD MyCloud has builtin support of Time Machine shared folder to accomodate more than one backup at a time. So if you have more than one computer required for home backup, you can opt for the builtin Time Machine feature on WD MyCloud server. The only exception is that you have no control over the size limit of each backup. WD MyCloud uses one single folder for Time Machine Backup for all. When the space runs out, whoever which backup in next operation may start to delete its older snapshots.

If you want more control over Time Machine backup, then you may want to manually create backup image file/folder for use. This way you can set a size limit to the image file/folder. The type of backup image option should be *.sparsebundle which is commonly used by Time Machine operations.

Once external HFS+ formatted drive is connected to WD MyCloud, it will hook up as USB drive and the drive would appear on Finder as new drive. Furthermore, you may protect the drive with password secured access on WD MyCloud web interface. This HFS+ format is just for storage level. If you are considering using APFS or other filesystem, then you should keep reading. We are going to create the actual backup image in its preferred filesystem afterwards.

Manually create *.sparsebundle on network shared drive

For better control over backup size limit, you must create *.sparsebundle image through Disk Utility tool. Click [File] > [New Image] > [Blank Image...] and then select a location on network shared drive to store your backup image.

For backup format, you will have many more options, i.e., Mac OS Extended (Journaled), APFS or even exFAT. This is the filesystem for the actual Time Machine Backup. 

For Image Format, you can simply pick [sparse bundle disk image]. 

For Partitions option, please select [Single partition - GUID Partition Map] for compatibility with Time Machine requirements. 

Finally, you must set the Size to your desired value. The backup image size must be smaller than the total space available on network shared drive. 

For further security, you can select Encryption like 128/256 bit encryption and set your password.

Once you create *.sparsebundle image successfully. A new drive linked to this image will appear on Finder.

Tell Time Machine where to find the new backup location

You can set destination with Time Machine command line like this:

$ sudo tmutil setdestination /Volumes/YOUR_TIMEMACHINE_BACKUP_DRIVE

Make network shared volume automatically mounted

To make the mounted volume surviving at the next boot time:

1. Go to System Preferences
2. Click Users and Groups
3. Select your user and then click Login Items
4. Click the + button and then choose the blank image (.sparsebundle) created in step 1 above
5. Repeat step 4 and choose the target volume so it will be mounted automatically.

Ref.:

The way to manage multiple copies of Time Machine Backups is different than builtin setup of TimeMachineBackup shared folder on WD My Cloud.

Creating sparsebundle image manually on NAS share drive gives flexibilities and control over image size for each backup. 

Configure time machine backup on Samba drive:

https://manjaro.site/how-to-configure-time-machine-to-backup-to-samba-shared-folder/

Repair sparsebundle on NAS backup:

https://www.garth.org/archives/2011,08,27,169,fix-time-machine-sparsebundle-nas-based-backup-errors.html

https://expobrain.net/2016/12/10/fix-corrupted-time-machine-spase-bundles/

https://macmanus.nl/2014/01/31/fixed-use-terminal-to-repair-corrupt-sparsebundle-file/

Limit the size of time machine sparse bundles:

https://community.wd.com/t/how-can-i-limit-the-size-of-the-time-machine-sparse-bundles-on-the-mbl/55021/6

Time machine backups on external USB drive attached to WD My Cloud:

https://support-en.wd.com/app/answers/detailweb/a_id/19225

https://community.wd.com/t/how-to-expand-disk-size-for-time-machine-backups/230284/2

https://community.wd.com/t/usb-port-for-time-machine-backup/266335

Installing Composer on OS X Mavericks with XAMPP for Mac installed

Composer is a popular tool for the dependency management in PHP. It lets you declare dependent libraries for each particular project.

Let's have a quick look on what have installed so far on the development machine:

OS X Mavericks
XAMPP for Mac installed and configured properly (A running instance)
Hombrew installed and configured (Try brew doctor to tackle any problem before you start)

Steps as follows:

Assuming default installation path of XAMPP for Mac package installed as usual, please change into the directory where PHP executable resides:

$ cd /Applications/XAMPP/bin/

Check the version of PHP:

$ php --version
PHP 5.4.30 (cli) (built: Jul 29 2014 23:43:29) 
Copyright (c) 1997-2014 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2014 Zend Technologies

Now we know PHP version is 5.4. Let's remember this for use in next couple of steps.

If you try to install Composer with brew command now, you may end up with an error like this:

composer: Missing PHP53, PHP54, PHP55 or PHP56 from homebrew-php. Please install one of them before continuing

Error: An unsatisfied requirement failed this build.

The likely cause is that we are using PHP within XAMPP package whereas brew cannot detect its presence without installing its own PHP engine.

Supposing XAMPP package is installed properly, we can simply add the path /Applications/XAMPP/bin/ to $PATH environment variable to the end of the file ~/.bash_profile . If it doesn't work then another to get around this would be installing a new version of PHP package using brew command.

[OPTIONAL] So which version of brew's PHP engine to install? It's better match the version of PHP within XAMPP, i.e., 5.5.

[OPTIONAL] Let's install PHP54 package by using brew command:

$ brew install php55

Once finished, start installing Composer with brew commands like these:

$brew update;brew tap homebrew/dupes;brew tap homebrew/php;brew install composer

It includes the actions of updating and tapping the right repository for downloading Composer's source.

When brew's package for Composer is installed successfully, we can carry out next step to create composer.phar file within XAMPP's bin directory.

$ sudo php -r "eval('?>'.file_get_contents('https://getcomposer.org/installer'));"

We must execute the command as root privilege to avoid permission denied error.

When done, we can try composer command within /Applications/XAMPP/bin/ directory.

$ php composer.phar
   ______
  / ____/___  ____ ___  ____  ____  ________  _____
 / /   / __ \/ __ `__ \/ __ \/ __ \/ ___/ _ \/ ___/
/ /___/ /_/ / / / / / / /_/ / /_/ (__  )  __/ /
\____/\____/_/ /_/ /_/ .___/\____/____/\___/_/
                    /_/
Composer version 1e4229e22aefe50582734964d027fc1bfec16b1d 2014-10-02 11:34:17

Usage:
  [options] command [arguments]...

Then it should be ready for us to checkout new dependent packages within a new or existing PHP project directory.

Mac OS X: Prevent .DS_Store file creation over network connections

Mac user may find it uncomfortable for leaving the trace when opening files or folders on the remote file server. Some hidden files like .DS_Store will be created automatically, sadly, without any acknowledgment to the user.

Here comes the hint to disable this feature on remote storage access (for Mac OS X 10.4 or later only):

To configure a Mac OS X user account so that .DS_Store files are not created when interacting with a remote file server using the Finder, follow the steps below:

Note: This will affect the user's interactions with SMB/CIFS, AFP, NFS, and WebDAV servers.

1. Open Terminal.
2. Execute this command:
   

   defaults write com.apple.desktopservices DSDontWriteNetworkStores true

3. Either restart the computer or log out and back in to the user account.

If you want to prevent .DS_Store file creation for other users on the same computer, log in to each user account and perform the steps above—or distribute a copy of the newly modified com.apple.desktopservices.plist file to the ~/Library/Preferences folder of other user accounts.

Additional Information

These steps do not prevent the Finder from creating .DS_Store files on the local volume, and these steps do not prevent previously existing .DS_Store files from being copied to the remote file server.

Disabling the creation of .DS_Store files on remote file servers can cause unexpected behavior in the Finder (clickhere for an example).

Ref: http://support.apple.com/kb/ht1629

Compiling mod_auth_mysql.so under Mountain Lion OSX 10.8 with XAMPP for Mac (Apache v2.4)

First thing first! Install your favourite Bitnami XAMPP for Mac package:

http://www.apachefriends.org/en/xampp-macosx.html

At the time of writing, the latest version is v1.8.2 which includes newest Apache v2.4 as web server. This is where the problem is and we are going to sort this out and compile new mod_auth_mysql.so.

Make sure you setup XAMPP properly with appropriate passwords created for Apache and MySQL and so on…

!!!REMIND!!!
Before your spiritual work, make sure you stop Apache server so nothing should be affected during the compiling process.

The source code of mod_auth_mysql is a bit old to support Apache v2.4 web server whereas a little bit of extra work is required to get APXS compiling working.

Download C source code of mod_auth_mysql:

http://sourceforge.net/projects/modauthmysql/files/modauthmysql/3.0.0/mod_auth_mysql-3.0.0.tar.gz

Extract the mod_auth_mysql-3.0.0.tar.gz file which gives you a folder called "mod_auth_mysql-3.0.0".

Using Terminal command:

$ cd mod_auth_mysql-3.0.0

You will see the source file named "mod_auth_mysql.c" and we are going to work on it.

Download a patch file within the folder and patch it right there as follows:

$
$ curl http://www.zoosau.de/wp-content/uploads/mod_auth_mysql-300-apache-22.patch

$
$ patch < mod_auth_mysql-300-apache-22.patch

The patch fixes some problems for APXS compiling. For Apache v2.4, we have to do some more editing in the file "mod_auth_mysql.c".

Open up editor for the file "mod_auth_mysql.c":

$ open -e mod_auth_mysql.c

Modify the lines as described below:

==========================================================
LINE 908:
  return r->connection->remote_ip;

Changed to:
  return r->connection->client_ip;
==========================================================
LINE 1273:
const apr_array_header_t *reqs_arr = ap_requires(r);

Changed to:
const apr_array_header_t *reqs_arr = NULL;
==========================================================
LINE 1275:
const array_header *reqs_arr = ap_requires(r);

Changed to:
const array_header *reqs_arr = NULL;
==========================================================

Explanation:

It's a bit technical and requires you to read Apache manual first about new Apache 2.4 which explicitly takes ap_requires() function completely out of core services.

Looking through those forums and finally get something closed to that problem. A possible fix:

http://www.mail-archive.com/pld-cvs-commit@lists.pld-linux.org/msg313889.html

As function ap_requires() is removed from Apache v2.4 API, we can set related reference pointer to NULL in order to skip that problem in mod_auth_mysql.c file.

For the solution of LINE 908, thanks to the blogger on http://cootos.sinaapp.com/?p=94 .

Now comes the actual compiling work.

Reference is here:
http://www.nilspreusker.de/?s=mod_auth_mysql

But we need to modify the paths to port them to those paths in XAMPP for Mac package.

Using Terminal command as follows:

$
$
$ sudo /Applications/XAMPP/bin/apxs -c -i -a -D -lmysqlclient \
 -lm -lz -I/Applications/XAMPP/XAMPPfiles/include/ \
 -L/Applications/XAMPP/XAMPPfiles/include/ \
 -Wc,"-arch x86_64" -Wl,"-arch x86_64" mod_auth_mysql.c

It's a long command which I spilt it into four lines so you may have to recombine them in the text editor before you issue the actual command.

If things are going well, you should see the following output generated by the above command:

/Applications/XAMPP/xamppfiles/build/libtool --silent --mode=compile gcc -std=gnu99 -prefer-pic -I/Applications/XAMPP/xamppfiles/include/c-client -I/Applications/XAMPP/xamppfiles/include/libpng -I/Applications/XAMPP/xamppfiles/include/freetype2 -O3 -L/Applications/XAMPP/xamppfiles/lib -I/Applications/XAMPP/xamppfiles/include -I/Applications/XAMPP/xamppfiles/include/ncurses -arch x86_64  -DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK -no-cpp-precomp -DDARWIN_10  -I/Applications/XAMPP/xamppfiles/include  -I/Applications/XAMPP/xamppfiles/include/apr-1   -I/Applications/XAMPP/xamppfiles/include/apr-1 -I/Applications/XAMPP/xamppfiles/include -arch x86_64 -I/Applications/XAMPP/XAMPPfiles/include/  -c -o mod_auth_mysql.lo mod_auth_mysql.c && touch mod_auth_mysql.slo
mod_auth_mysql.c: In function 'str_format':
mod_auth_mysql.c:891: warning: format '%d' expects type 'int', but argument 8 has type 'long int'
/Applications/XAMPP/xamppfiles/build/libtool --silent --mode=link gcc -std=gnu99 -Wl,-rpath -Wl,/Applications/XAMPP/xamppfiles/lib -L/Applications/XAMPP/xamppfiles/lib -I/Applications/XAMPP/xamppfiles/include -arch x86_64 -L/Applications/XAMPP/xamppfiles/lib -L/Applications/XAMPP/xamppfiles   -o mod_auth_mysql.la -arch x86_64  -L/Applications/XAMPP/XAMPPfiles/include/ -lmysqlclient -lm -lz -rpath /Applications/XAMPP/xamppfiles/modules -module -avoid-version    mod_auth_mysql.lo
/Applications/XAMPP/xamppfiles/build/instdso.sh SH_LIBTOOL='/Applications/XAMPP/xamppfiles/build/libtool' mod_auth_mysql.la /Applications/XAMPP/xamppfiles/modules
/Applications/XAMPP/xamppfiles/build/libtool --mode=install install mod_auth_mysql.la /Applications/XAMPP/xamppfiles/modules/
libtool: install: install .libs/mod_auth_mysql.so /Applications/XAMPP/xamppfiles/modules/mod_auth_mysql.so
libtool: install: install .libs/mod_auth_mysql.lai /Applications/XAMPP/xamppfiles/modules/mod_auth_mysql.la
libtool: install: install .libs/mod_auth_mysql.a /Applications/XAMPP/xamppfiles/modules/mod_auth_mysql.a
libtool: install: chmod 644 /Applications/XAMPP/xamppfiles/modules/mod_auth_mysql.a
libtool: install: ranlib /Applications/XAMPP/xamppfiles/modules/mod_auth_mysql.a
chmod 755 /Applications/XAMPP/xamppfiles/modules/mod_auth_mysql.so

Now it's time to modify a working https.conf for Apache v2.4.

In httpd.conf, find those lines with LoadModule * statements and add the following two statements at the bottom of that section:

#
#
#
LoadModule apreq_module modules/mod_apreq2.so
LoadModule mysql_auth_module modules/mod_auth_mysql.so
#

This make sure the target libraries are called up when Apache starts.

Before you start Apache server again to test if it runs or not, you have one more thing to do. In my experience, Apache server may not start because of libmyqlclient error. This is the case when we have no other MySQL client setup on the Mac before.

All you have to do is creating new symbolic link to let Apache v2.4 find the right library:

$
$ sudo ln -s /Applications/XAMPP/xamppfiles/lib/libmysqlclient.18.dylib \
 /usr/lib/libmysqlclient.18.dylib
$

Now start your Apache v2.4 web server and see if it's running properly. If yes, you are ready to use mod_auth_mysql module again!

Happy coding!!!

PS: Additionally you'll need to make sure PHP Session is working.
In /Applications/XAMPP/xamppfiles/etc/php.ini, you need to uncomment a line like this:

session.save_path = "/tmp"

This should do the trick;-)