Troubleshooting

At the end of the day, if you've executed the deployment, step by step, as suggested, you should have been able to integrate your remote drives flawlessly into your client system. Durring the course of writing this article, one of the problems I faced was attempting to establish an iSCSI session (Listing 6).

$ sudo /sbin/iscsiadm -m node -T iqn.2000-01.com.synology:MYDEVICE.Target-1.4d9e3bda2ee -p 192.168.1.10 -l
iscsiadm: initiator reported error (19 - encountered non-retryable iSCSI login failure)
iscsiadm: Could not log into all portals

This particular error, alongside any other session-establishing error, will either be caused by a firewall blocking TCP/3260, a mismatch in any of the client-server IQNs, or both. Therefore, one solution will be to check the firewall rules, and another will be to look at the iSCSI target profile located on either the server or client side. The last situation arises mainly when a profile somewhere has been deleted and a re-initiating connection that uses the invalid values is still cached by iscsi.service.

From a client perspective, the file to examine on the 'bookworm' system is /etc/iscsi/initiatorname.scsi, whereas from the server's perspective (and in this case), the file would be located in the SAN Manager (Figure 9). Once any change has been made, it will be necessary to restart the iscsi.service on the client side by invoking either one of the two commands:

$ sudo systemctl restart iscsid.service
$ sudo service iscsid restart

Figure 9: When encountering an iSCSI login failure message while attempting to establish a session on your client, the most common issue will be that /etc/iscsi/initiatorname.iscsi from the client side does not match the Host entry value under the SAN Manager on the server side.

Another fairly common problem you could face is hitting a lock on the mount itself, which makes it impossible to close your newly attached device properly. In the event that you are facing a umount: target is busy error message and cannot find anything (with the lsof command) to kill that will free this lock, you should invoke the /usr/bin/fusermount command paired with the -u switch and followed by the mount path in question. If you have no time to waste, you can unmount ungracefully by adding the -z switch to send a SIGKILL (Listing 7), which will then cause the lock to be released immediately.

$ df -H
Filesystem                         Size  Used Avail Use% Mounted on
tmpfs           411M  1.4M  410M   1% /run
/dev/sda2        27G   13G   13G  50% /
tmpfs           2.1G     0  2.1G   0% /dev/shm
tmpfs           5.3M     0  5.3M   0% /run/lock
tmpfs           411M  193k  411M   1% /run/user/1000
/dev/mapper/BU                     7.9T   29k  7.5T   1% /BU
$ sudo umount /BU
umount: /BU: target is busy.
$ sudo fusermount -zu /BU
$ df -H
Filesystem                         Size  Used Avail Use% Mounted on
tmpfs           411M  1.4M  410M   1% /run
/dev/sda2        27G   13G   13G  50% /
tmpfs           2.1G     0  2.1G   0% /dev/shm
tmpfs           5.3M     0  5.3M   0% /run/lock
tmpfs           411M  193k  411M   1% /run/user/1000
$ lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda      8:0    0    25G  0 disk
|-sda1   8:1    0     1M  0 part
|-sda2   8:2    0    25G  0 part /var/snap/firefox/common/host-hunspell
sdb                           8:16   0   7.2T  0 disk
|-BU                        252:3    0   7.2T  0 crypt
$ sudo cryptsetup luksClose BU
$ sudo /usr/sbin/iscsiadm -m node -T iqn.2000-01.com.synology:MYDEVICE.Target-1.4d9e3bda2ee -p 192.168.1.10:3260 -u
Logging out of session [sid: 15, target: iqn.2000-01.com.synology:MYDEVICE.Target-1.4d9e3bda2ee, portal: 192.168.1.10,3260]
Logout of [sid: 15, target: iqn.2000-01.com.synology:MYDEVICE.Target-1.4d9e3bda2ee, portal: 192.168.1.10,3260] successful.
$ sudo iscsiadm -m session
iscsiadm: No active sessions.
$ df -H
tmpfs           411M  1.4M  410M   1% /run
/dev/sda2        27G   13G   13G  50% /
tmpfs           2.1G     0  2.1G   0% /dev/shm
tmpfs           5.3M     0  5.3M   0% /run/lock
tmpfs           411M  193k  411M   1% /run/user/1000

Conclusion

Whether you have decided to opt for a "miracle" solution provided by a vendor or have built your system from the ground up with equipment of your choosing, the challenges are the same: ensuring data confidentiality, integrity, and accessibility. However, whichever path you chose when sailing the sea of digital sovereignty [6], the same considerations of total capacity, access latency, and ease of integration with the current infrastructure will be of concern. The best thing you can do for the future of your organization is to make sure you build a stack that can be adapted, while still allowing a realistic degree of vendor or community support.

In this article, I paired the highly mature and community-driven Open-iSCSI and LUKS projects with one moderately closed solution from a vendor with some level of adaptability. The conclusion of this setup turned out to be that I was able to pair the best of both world: harmonizing a hardware vendor solution with community-driven software. With the deployment of such a device, I am fully confident that all of my stack, from the device's firmware down to any software needed, will be supported for the next several years.