QNAP NAS Community Forum

After removing two iSCSI targets the corresponding disk space was not freed:



The system protocol:


How can I delete the lost iSCSI target files?

Regards,
Markus

Kindly post the output of

doktornotor wrote:Kindly post the output of

Code: Select all

df -h

Or check it again in 24 hours?

If QNAP can't make that work in real time, they might as well remove it from Firmware. Useless "pretty" screen anyway. Your advice to check it from the command line is indeed the correct approach.
People seem to expect that output to be "real-time", so that screen is useless in any language because it is historical....

doktornotor wrote:Kindly post the output of

Code: Select all

df -h

df says:
Thanks,
Markus

Okay, thanks, I found the lost files:

Yeah, there's a wonderfully hidden GUI to remove those, behind the "Un-mapped iSCSI LUN List" button

Hi doktornotor,

that was exactly what I did before removing my LUNs. Nevertheless: the disk space wasn´t freed. I assume it´s a GUI issue.
I had to manually delete the files in /share/MD0_DATA/.@iscsi.img.
Unfortunately I have no time and no second device to reproduce this problem.

Regards,
Markus

Have a similar case - however the file space is freed up, but the usage is still shown in the Disk Usage list and the graph. The ubiquitous vs_refresh did not help...
...removed the LUN container file... note the 100 GB free'ed space - however it's still listed as a LUN and the pie does include it, too...
Something QNAP there...

I presume this was a thin provisioned LUN.

Has anyone tested if the volume, actions, reclaim option have any effect on the space reporting?

I also removed everything one-by-one in the web admin interface... starting with the virtual disk pointing to the target, and the target and the LUN.
However, I noticed that the space on the raid was not freed.
So I emptied the network recycle bin and again nothing.
I checked the disk usage in resource monitor and sure enough it is still listed there.

I can see it in /share/MD0_DATA/.@iscsi.img
iSCSI-MUSIC_LUN-4e19ea97.000 512,000Mib
virtual_lun0 1,024Kib

I was thinking to just delete these two files...
What shoudl I do?

Please any ideas? Some of you had this problem before. Thanks

I just noticed something very strange.
In control panel>storage manager>iscsi>Advanced ACl
I noticed there is a 'default policy'.
I can only add or edit this policy.
When I edit this policy, I see the name of the LUN which I deleted earlier today (which still physically exists on my QNAP).
The policy entry 'MUSIC_LUN' can be edited but cannot be removed.
This is also a bug IMHO because the LUN has been deleted.

Anyway I am going to upgrade to the latest firmware tonight and see if there have been any changes (4.1.3 atm).

Ok I think I fixed it.

>>>MAKE BACKUPS BEFORE YOU START MODIFYING FILES!!!!

--------------------------------------------------------------------------
THE CONFIG FILES
-------------------------------------------------------------------------
I found the BOGUS still lingering OBSOLETE data in the following files.
/mnt/HDA_ROOT/.config/iscsi.conf
/mnt/HDA_ROOT/.config/iscsi_trgt.conf

QNAP OS should have cleaned these files when I deleted the LUNs.
Unfortunately the LUNs were still in there. Even LUNs which I deleted years ago were in there! The strange thing is that a very old LUN which was mentioned in these files, does not exist as a physical file and I am wondering if the file was correctly removed from the machine with an older version of the firmware. Maybe the newer firmwares have been broken a bit? IDK.

>>>>Finally, this file I left untouched as it had no mention of my particular LUNs. /mnt/HDA_ROOT/.config/iscsi-init.conf

Below is what I left in my /mnt/HDA_ROOT/.config/iscsi.conf (yours MAY DIFFER be careful)
[iSCSISetting]
Enable = TRUE
iSCSIPort = 3260
[iSNS]
biSNSEnable = FALSE
iSNSServer =

Below is what I left in my /mnt/HDA_ROOT/.config/iscsi_trgt.conf (yours MAY DIFFER be careful)
[iSCSIPortal]
bServiceEnable=FALSE
servicePort = 3260
initiatorBitmap00 = 00000001
bISNSEnable = FALSE
ISNSIP =
targetIQNPrefix = iqn.2004-04.com.qnap:ts-509:iscsi.
targetBitmap00=00000000
LUNBitmap00 = 00000008

[init0Info]
initiatorIndex = 0
initiatorIQN = iqn.2004-04.com.qnap:all:iscsi.default.ffffff
initiatorAlias = Default Policy
initiatorTargetBitmap00=00000000
initiatorLUNBitmap00 = 00000008

[InitiatorKey]
iqn.2004-04.com.qnap:all:iscsi.default.ffffff = 0

[TargetKey]

[LUNKey]

Now, when I go to In control panel>storage manager>iscsi>Advanced ACl the 'default policy' is empty as it should be since I have 0 Luns configured. GOOD!

--------------------------------------------------------------------------
THE LUN FILES
-------------------------------------------------------------------------
My LUN is in here /share/MD0_DATA/.@iscsi.img
the name of the 500MB file is /share/MD0_DATA/.@iscsi.img/iSCSI-MUSIC_LUN-4e19ea97.000
After the above mods, I deleted the file which no longer shows as a LUN in disk usage. GOOD!
>>>>I did not delete the file /share/MD0_DATA/.@iscsi.img/virtual_lun0 (maybe it is necessary for the system)

I will empty the recycle bin, reboot and check the disk usage again to see if the free space is returned.

Sure enough, after the reboot, the space was RETURNED ! )))
It will be noticed as an increase in free space in the web interface resource monitor/disk usage.
So earlier when I deleted the LUN and fixed the conf files, the LUN was removed from disk usage, but not reported elsewhere in another category. essentially taking up space out of the 'free space' category without reporting it.
Now the space is redeemed.

The above operations were done when running TS509 firmware v4.1.3

Hi All,

Although this thread is old, the solution is (now) simple.

In the iSCSI settings, under "Target Management" I now have the option "Un-mapped iSCSI LUN list" at the bottem.
When selected, I had the deleted iSCSI LUN visible.
After deleting the LUN from the "Un-mapped iSCSI LUN list" I have the missing storage reclaimed.

This is in version 4.3.3 on a TS-212.