TOPIC: NETWORK-ATTACHED STORAGE
Saving yourself a reboot: remounting any overlooked volumes in Linux
14th September 2024Recently, I got things a little out of order when starting up my main Linux system after an absence. Usually, I start up my NAS first so that the volumes get mounted when I start my Linux machine. However, it happened that I near enough started them together. Thus, my workstation completed it startup without having the NAS volumes mounted. A reboot would have sorted this, but there was another way: issuing the command that you see below:
sudo mount -a
This looked in my /etc/fstab file and mounted anything that was missing as long as the noauto option was not set. Because this was executed after the NAS had completed its own boot process, it volumes were not mounted on my system and fully available for what I needed to do next. If I had wanted to see what had been mounted, then I needed to issue the following command instead:
sudo mount -av
In addition to the a switch that triggers the mounting of missing volumes, there is now a v (for verbose) one for telling you what has happened. Needless to say, all this happens only if your /etc/fstab file is set up properly. If you are adding a new volume, and I was not, it does no harm to mount it manually before updating the configuration file. That should catch any errors first.
Upgrading from OpenMediaVault 6.x to OpenMediaVault 7.x
29th May 2024Having an older PC to upgrade, I decided to install OpenMediaVault on there a few years ago after adding in 6 TB and 4 TB hard drives for storage, a Gigabit network card to speed up backups and a new BeQuiet! power supply to make it quieter. It has been working smoothly since then, and the release of OpenMediaVault 7.x had me wondering how to move to it.
Usefully, I enabled an SSH service for remote logins and set up an account for anything that I needed to do. This includes upgrades, taking backups of what is on my NAS drives, and even shutting down the machine when I am done with what I need to do with it.
Using an SSH session, the first step was to switch to the administrator account and issue the following command to ensure that my OpenMediaVault 6.x installation was as up-to-date as it could be:
omv-update
Once that had completed what it needed to do, the next step was to do the upgrade itself with the following command:
omv-release-upgrade
With that complete, it was time to reboot the system, and I fired up the web administration interface and spotted a kernel update that I applied. Again, the system was restarted, and further updates were noticed and these were applied, again through the web interface. The whole thing is based on Debian 12.x, but I am not complaining as long as it quietly does exactly what I need of it. There was one slight glitch when doing an update after the changeover, and that was quickly sorted.
Later on, I ran into trouble because I had changed my broadband. Because the router address had changed, the system lost its access to the rest of the internet. The web interface also got disable and was issuing 502: Bad Gateway errors. The solution was to execute the following command with superuser privileges:
omv-salt stage run deploy
That took quite a while to run, though. After it completed, I needed to work out what the administrator credentials were. With that done, I could log in and update the network details as needed to restore external internet access. Since then, all has been well.
Using a BASH command to count the files in a directory
12th March 2024As part of my backup workflow, I maintain a machine running OpenMediaVault that I only power up when backups are to be performed. Typically, this often happens when I have new photography images to load, and I have a NAS that acts as an online backup system. The OpenMediaVault machine is a near-offline counterpart to the NAS for added safety.
Recently, I needed to check on the number of image files in a directory from an SSH session because of a need to create a new repository for 2024. Some files from this year had ended up in the 2023 one, and I needed to be sure that nothing from last year ended in the 2024 folder, or vice versa. Getting a file count from a trusted source was a quick way of doing exactly this.
Due to clumsiness with the NAS, I had to do this using the OpenMediaVault machine. While I could go mounting drives on an interim basis, it was quicker to work from a BASH session. The trick was to use the wc command for counting the lines output by an invocation of the ls command. An example follows:
ls -l | wc -l
The -l (as in l for Lima) switch forces wc to count lines, while the counterpart (same letter) for ls forces it to list the contents in long form, one item per line. Thus, counting the number of lines gets you the count of the number of files. The call to the ls command can be customised to add other things life the number of dot files, but the above was enough for my purposes. When the files in both 2023 directories matched, I was satisfied that all was in order.
Halting constant disk activity on a WD My Cloud NAS
6th June 2018Recently, I noticed that the disk in my WD My Cloud NAS was active all the time, so it reminded me of another time when this happened. Then, I needed to activate the SSH service on the device and log in as root with the password welc0me. That default password was changed before doing anything else. Since the device runs on Debian Linux, that was a simple case of using the passwd command and following the prompts. One word of caution is in order since only root can be used for SSH connections to a WD My Cloud NAS and any other user that you set up will not have these privileges.
The cause of all the activity was two services: wdmcserverd and wdphotodbmergerd. One way to halt their actions is to stop the services using these commands:
/etc/init.d/wdmcserverd stop
/etc/init.d/wdphotodbmergerd stop
The above act only works until the next system restart, so these command should make for a more persistent disabling of the culprits:
update-rc.d -f wdmcserverd remove
update-rc.d -f wdphotodbmergerd remove
If all else fails, removing executable privileges from the normally executable files that the services need will work, and it is a solution that I have tried successfully between system updates:
cd /etc/init.d
chmod 644 wdmcserverd
reboot
Between all of these, it should be possible to have you WD My Cloud NAS go into power saving mode as it should, even if turning off additional services such as DLNA may be what some need to do. Having turned off these already, I only needed to disable the photo thumbnail services that were the cause of my machine's troubles.
Setting up a WD My Book Live NAS on Ubuntu GNOME 13.10
1st December 2013The official line from Western Digital is this: they do not support the use of their My Book Live NAS drives with Linux or UNIX. However, what that means is that they only develop tools for accessing their products for Windows and maybe OS X. It still doesn't mean that you cannot access the drive's configuration settings by pointing your web browser at http://mybooklive.local/. In fact, not having those extra tools is no drawback at all since the drive can be accessed through your file manager of choice under the Network section and the default name is MyBookLive too, so you easily can find the thing once it is connected to a router, or switch anyway.
Once you are in the server's web configuration area, you can do things like changing its name, updating its firmware, finding out what network has been assigned to it, creating and deleting file shares, password protecting file shares and other things. These are the kinds of things that come in handy if you are going to have a more permanent connection to the NAS from a PC that runs Linux. The steps that I describe have worked on Ubuntu 12.04 and 13.10 with the GNOME desktop environment.
What I was surprised to discover that you cannot just set up a symbolic link that points to a file share. Instead, it needs to be mounted and this can be done from the command line using mount or at start-up with /etc/fstab. For this to happen, you need the Common Internet File System utilities and these are added as follows if you need them (check in the Software Centre or in Synaptic):
sudo apt-get install cifs-utils
Once these are added, you can add a line like the following to /etc/fstab:
//[NAS IP address]/[file share name] /[file system mount point] cifs
credentials=[full file location]/.creds,
iocharset=utf8,
sec=ntlm,
gid=1000,
uid=1000,
file_mode=0775,
dir_mode=0775
0 0
Though I have broken it over several lines above, this is one unwrapped line in /etc/fstab with all the fields in square brackets populated for your system and with no brackets around these. Though there are other ways to specify the server, using its IP address is what has given me the most success; this is found under Settings > Network on the web console. Next up is the actual file share name on the NAS; I have used a custom term instead of the default of Public. The NAS file share needs to be mounted to an actual directory in your file system like /media/nas or whatever you like; however, you will need to create this beforehand. After that, you have to specify the file system, and it is cifs instead of more conventional alternatives like ext4 or swap. After this and before the final two space delimited zeroes in the line comes the chunk that deals with the security of the mount point.
What I have done in my case is to have a password-protected file share and the user ID and password have been placed in a file in my home area with only the owner having read and write permissions for it (600 in chmod-speak). Preceding the filename with a "." also affords extra invisibility. That file then is populated with the user ID and password like the following. Of course, the bracketed values have to be replaced with what you have in your case.
username=[NAS file share user ID]
password=[NAS file share password]
With the credentials file created, its options have to be set. First, there is the character set of the file (usually UTF-8 and I got error code 79 when I mistyped this) and the security that is to be applied to the credentials (ntlm in this case). To save having no write access to the mounted file share, the uid and gid for your user needs specification, with 1000 being the values for the first non-root user created on a Linux system. After that, it does no harm to set the file and directory permissions because they only can be set at mount time; using chmod, chown and chgrp afterwards, has no effect whatsoever. Here, I have set permissions to read, write and execute for the owner and the user group while only allowing read and execute access for everyone else (that's 775 in the world of chmod).
All of what I have described here worked for me and had to be gleaned from disparate sources like Mount Windows Shares Permanently from the Ubuntu Wiki, another blog entry regarding the permissions settings for a CIFS mount point and an Ubuntu forum posting on mounting CIFS with UTF-8 support. Because of the scattering of information, I just felt that it needed to all together in one place for others to use, and I hope that fulfils someone else's needs similarly to mine.