Changing the volume name on an OS6 based NAS (and things you can learn from it)

The following is posted by Sandshark, just an enthusiastic and inquisitive user with no affiliation with Netgear, now or in the past, with no implied or stated warranty.  This information is intended for advanced users only.

I have been experimenting with the task of renaming a volume, and in the process, have learned a lot about how the GUI interacts with the BTRFS volume and sub-volume structure and the file server protocols (SMB, NFS, FTP, etc.).  Frankly, there are few reasons one would need to rename a volume, and the complexity of doing so makes me understand why Netgear didn't include the option in the GUI.  The only reason I can think of is the need to import a volume having the same name as one already on your NAS, which will fail without one name being changed first.  It is a very complex process, so not one to be taken lightly.  I have intentionally made this very top level.  A keystroke-by-keystroke procedure would be massive, and if you are not skilled enough with SSH and the Linux command line to understand the process from this, you should not even think about doing it.  Even if you are, you should explore other options first.  I also recommend that this be temporary.  Do what you need to do, then destroy and re-create the volume or do a factory default to insure everything is aligned.

If you have apps that directly access files and have configuration files or databases, nothing in this process is going to help with those.  I just can’t look into how every app interacts.

I have no "insider information" on how the GUI interacts with the basic Linux BTRFS volume and subvolumes (shares), and a lot of this has to do with making updates to that after doing the relatively simple task of relabeling the BTRFS volume.  Everything is "reverse engineered".  It was all done on a virtual machine running OS6.10.2.  I have yet to do it on a real NAS, it’s not like a VM where you can restore a snapshot and start over if you mess up.  So, there may be something I have missed and there is nothing stopping Netgear from making changes down the line that make it invalid.  Proceed at your own risk.  Before actually making changes, take a look at everything I've said you will need to change and insure it’s all in line with what I've told you to expect.

Where example names are needed, my old volume is data, which is renamed newvol, the sample share is ShareName, and the hostid is.27a1bfb7 (the real one on my OS6 virtual machine).

Before proceeding, insure you have a backup.  If you screw this up, there is a significant chance your only out is a factory default and restore from backup.

Locate the volume label with btrfs  filesystem  show, which will be in the form 27a1bfb7:data.  The leading hexadecimal number, your Linux host ID, will differ, but take note of it and keep it consistent when it’s used below, as I'm not completely sure what part it plays in all this.  It does not appear to be standard BTRFS that the volume name must include it.  I have noted that an imported volume retains its old host’s ID number, so maybe it doesn't matter; but I'm taking no chances.  If you somehow forget to write it down, the hostid command will give it to you.

Relabel the BTRFS volume with btrfs   filesystem  label  /data  27a1bfb7:newvol.  Note that, although re-labeled, it’s still mounted as data.

Examine shares and hidden files with ls  /data  -all.

For each share listed, you need to edit /data/._share/ShareName/afp.conf,  nfs.conf, and  samba.conf and change the embedded share name.

As best I can tell, no changes are needed for iSCSI LUNs or Time Machine shares.  But I don't use iSCSI or Time Machine, so I can only look at the configuration files, I can’t test it.

Edit /etc/systemd/system/multi-user.target.wants/home.mount and /etc/systemd/system/multi-user.target.wants/apps.mount to point home and apps folders to the new volume name (if this is the primary volume).

Examine snapshot configurations with ls  /etc/snapper/configs  -all.

For each numeric entry, edit /etc/snapper/configs/0 , 1, 2, ... and change data to newvol in  SUBVOLUME="/data/ShareName".

It's probably best to simply delete and re-create backup jobs, but you could edit /etc/frontview/backup_jobs.conf to change <src_share_vol>data</src_share_vol> and/or <dst_share_vol>data</dst_share_vol>, as needed for each backup job listed.

Edit /etc/frontview/samba/Shares.conf and /etc/frontview/rsync/Shares.conf and change path = /data/ShareName for every share for proper permissions for SMB and RSYNC.

Edit /etc/frontview/samba/Shares.conf.admin and change [data] and  path = "/data" for special admin privilege to view the main volume in SMB.

If you use NFS, edit /etc/exports and change the volume name everywhere it appears.

If you use AFP, I didn’t identify anything needing a change other than afp.conf for each share under /data/._share listed above, but I have no way to test AFP.

If you have DLNA enabled, edit /etc/minidlna.conf to change the volume name in the media_dir entries.  I do not run DLNA, but I suspect the database must also be updated.  I believe that just running a media scan after the reboot at the end of this process should update it.

Rename both of the following performance plot data files, substituting newvol for data:

     /run/readynasd/stats/volume_data_int.rrd

     /var/readynasd/stats/volume_data_int.rrd

Or just delete them, and the system will re-start the plots (which it does a lot, anyway).

OK, so next is to re-name the MDADM RAID array to match the new BTRFS volume name.  For volume 27a1bfb7:data, the MDADM array will be 27a1bfb7:data-0 for the first BTRFS layer, 27a1bfb7:data-1 for the second, etc.  I’m only going to cover a single layer volume because that’s all I’ve done it on, but I believe this should work for multi-layer volumes as well.  I’m not entirely sure this step is necessary, but it keeps things consistent, and inconsistence could lead to issues later.  If you are doing this so a volume you want to import doesn’t have the same name, it’s probably more important.

The first thing is to use lsblk to see what drive partitions are associated with what RAID arrays and volumes.  In the following sample (first drive only), the /data array is md127 and the first partition is sda3:

     sda         8:16   0   64G  0 disk

     ├─sda1      8:17   0    4G  0 part

     │ └─ma0     9:0    0    4G  0 raid1 /

     ├─sda2      8:18   0  512M  0 part

     │ └─md1     9:1    0  511M  0 raid1 [SWAP]

     └─sda3      8:19   0 59.5G  0 part

       └─md127   9:127  0 59.5G  0 raid1 /data

(NOTE:  The drive size in the example is small because this is a virtual machine with virtual drives.)

Now, verify the name of md127 with mdadm  --detail  /dev/md127 where we find a line like this: Name: 27a1bfb7:data-0, confirming what was expected.

In order to re-name the array, it has to be stopped.  And before we can stop it, we have to unmount anything mounted from it.

Use cat /proc/mounts to list all mount points.  The md127 ones should be near the bottom.

One of the thigs we have to unmount is /apps.  Before you can do that, you have to disable iTunes, DLNA, and any apps that might be using it.  Use fuser -m /apps to make sure no process ID’s are listed as still using it.

Unmount the volumes with umount  /data, umount  /home,  umount  /apps and anything else you found mounted from md127 like /var/ftp/ShareName if FTP is enabled or /run/nfs4/data1/ShareName if NFS is enabled.

From this point until you reboot, the GUI is going to complain that your array is inactive.

While we have /data unmounted, rename its mount point with mv  /data  /newvol.

Now, stop the RAID array with mdadm  --stop  /dev/md127.

And then re-assemble and re-name it with

 mdadm  ‑-assemble  /dev/md127  ‑-name=27a1bfb7:data1‑0  --update=name  /dev/sda3.

Then tell the NAS to mount the volume as newvol next time by editing /etc/fstab to change

     LABEL=27a1bfb7:data   /data

          to

     LABEL=27a1bfb7:newvol   /newvol.

It’s finally time to re-boot and let the NAS sort out all that has changed.  Make sure you’ve done everything above before this reboot.  After the reboot, your volume name should show as newvol in the GUI, mdstat, mdadm  --detail, lsblk, etc.  Many things can actually be done after the re-boot if you find you made an error or omission, but it is best to not rely on that.

After the re-boot, some ways to see if you made any mistakes or omissions is to verify the NAS did not automatically add a mount point for /data or an entry for it in /etc/fstab and to go back and look at a lot of the command outputs and edited files.  If you have to go back and fix something, just make sure you remove the /data mount point and entry for it in /etc/fstab before you re-boot again if they were automatically re-created.

Once it all looks right, don’t forget to turn back on any apps you had to stop, iTunes, and DLNA.

I want to emphasize again that there may be things I have missed.  If you find some, please let me know.  But because of this, it is best that this be done for a specific temporary purpose and the volume is destroyed or a factory default is performed after that purpose is served to insure everything gets cleaned up.

Aside from volume renaming, the above also reveals some of the mechanisms through which the GUI, volumes, shares, and data transport mechanisms interact.  If you are having problems with a share, or if one was created “behind the scenes” via SSH without using Netgear’s rn_nlm utility, this will also give you pointers to several things you can check.  Note, however, that a share must be a BTRFS sub-volume within the appropriate BTRFS volume.  If it isn’t, there are many things that may get confused.

If a volume is missing any of the entries in /data/._share, which seems to be the secret to having the GUI show and be able to work with the shares, it’s best to copy from an existing one for another share and edit that instead of trying to create it from scratch.  You can always create a “clean” one by creating a new share via the GUI and setting the options as you’d like or using rn_nlm  -a  share:/data/ShareName (assuming volume is still named data).

All warnings aside, I hope this information does end up benefitting somebody.  But if not, I learned a lot figuring it all out.