Snapshot created with forward slash (/) in name now cannot delete

[kekoakeakane]

When creating a set of snapshot tasks, I thought it would be a good idea to use the name and path of the dataset in the name of the snapshot. Such as "zpool01/ds01/backups-daily-auto-%Y%m%d.%H%M". When the task ran, it appeared to have created the snapshot as a set of snapshots with these names appeared in the list on the WebGUI. I realized there was a problem when the replication task to the backup FreeNAS server failed with a "snapshot does not exist" error. I finally determined that the forward slash in the name was causing the errors and after more investigation determined that no snapshots had actually been taken. I did this by going into the .zfs directory under each dataset and listing the files. No snapshots existed in the directory. Additionally, when selecting the snapshot in the WebGUI list, the data for the snapshot is also missing. i.e. Date Created, Used, and Referenced information.

The problem I am trying to solve is that these errant snapshots still exist in the list of snapshots in the WebGUI. However, since no snapshots exist, I can't delete them. How can I get these out of the snapshot index?

After more investigation, it appears that the snapshots existentially exist in the file system, but in a way that they cannot be referenced or deleted. See replies below.

 

[JaimieV]

Worth checking if they exist on the command line too - zfs list -t snapshot

If they don't exist, then export/import in the GUI would trigger a re-read of the actual snapshot indexes, but I don't know if it'll clear anything the GUI has cached.

 

[kekoakeakane]

Worth checking if they exist on the command line too - zfs list -t snapshot

If they don't exist, then export/import in the GUI would trigger a re-read of the actual snapshot indexes, but I don't know if it'll clear anything the GUI has cached.

It appears that the snapshots do exist on the command line as well. The output of the command - zfs list -t snapshot also includes the errant snapshots. In that listing, they indicate an amount that they are referencing that is similar to all other snapshots of the same dataset.

What did you mean when you said "then export/import in the GUI would trigger a re-read of the actual snapshot indexes"? How is this done?

Additional question is whether or not these snapshots will hold reference space on the drives? If so, I really need to find a way to delete them.

 

[kekoakeakane]

Just attempted a little more troubleshooting at the shell level.

Attempting to delete the snapshot using - zfs destroy zPool01/ds01/esxi-storage@zPool01/ds01-Daily-auto-20201013.0000-4w results in a could not find any snapshots to destroy; check snapshot names. error.

Attempting to rename the snapshot using - zfs rename zPool01/ds01@zPool01/ds01-Daily-auto-20201013.0000-4w zPool01/ds01@zPool01-ds01-Daily-auto-20201013.0000-4w results in the error - cannot open 'zPool01/ds01@zPool01/ds01-Daily-auto-20201013.0000-4w': trailing slash in name

Which results in the question: "How did freenas get the zfs snapshot command to complete in the first place?"

 

[kekoakeakane]

More troubleshooting. Apparently, the snapshots do exist, but are inaccessible. I have been listing the snapshot folders using the 'ls -al' command. I have just tried the 'ls -A' command and I receive the following result:

ls: zPool01/ds01-Daily-auto-20201013.0000-4w: No such file or directory
ls: zPool01/ds01-Monthly-auto-20201013.0000-26w: No such file or directory

How do I go about deleting these file references?

 

[JaimieV]

What did you mean when you said "then export/import in the GUI would trigger a re-read of the actual snapshot indexes"? How is this done?

Storage/Pools, cogwheel Export/Disconnect drops the pool from the live system. Then Add on the same page to go through 'import an existing pool'. However, since the snapshots exist then don't do that, as it won't help at all.

Unix command line tools get upset with / in filenames (and names of file-like-objects that live in the directory heirarchy). I'm not about to create some snapshots with / in myself, so first thing is to try a backslash in front of the errant /, which in Unix command line 'escapes' the special meaning of the next character, so
zPool01/ds01@zPool01\/ds01-Daily-auto-20201013.0000-4w

Second thing to try is "double quoting" and 'single quoting' the troublesome snapshot names but I don't think that'll work since you have both a real directory / and a fake in-name /.

 

[kekoakeakane]

Storage/Pools, cogwheel Export/Disconnect drops the pool from the live system. Then Add on the same page to go through 'import an existing pool'. However, since the snapshots exist then don't do that, as it won't help at all.

Unix command line tools get upset with / in filenames (and names of file-like-objects that live in the directory heirarchy). I'm not about to create some snapshots with / in myself, so first thing is to try a backslash in front of the errant /, which in Unix command line 'escapes' the special meaning of the next character, so
zPool01/ds01@zPool01\/ds01-Daily-auto-20201013.0000-4w

Second thing to try is "double quoting" and 'single quoting' the troublesome snapshot names but I don't think that'll work since you have both a real directory / and a fake in-name /.

I've tried using every combination of backslash, "double quoting", and 'single quoting' for both zfs destroy and rm commands. Returns "could not find snapshot" or "No such file or directory" errors respectively.

 

[JaimieV]

I hope someone with more command line skills knows how to handle this one.

In the meantime, it would be a good idea to raise this as a bug at https://jira.ixsystems.com/ since having the UI allow / in the snapshot name construction is clearly a problem (and they are simple to filter out in the UI or raise an error for the user to fix).

 

[kekoakeakane]

I hope someone with more command line skills knows how to handle this one.

In the meantime, it would be a good idea to raise this as a bug at https://jira.ixsystems.com/ since having the UI allow / in the snapshot name construction is clearly a problem (and they are simple to filter out in the UI or raise an error for the user to fix).

I have put this in as a bug and it is being reviewed.

Yes. It would be nice if someone who had wizardry style skills on the command line could help with removing these files that "seem" like they are there but can't be manipulated by the file system.

More interesting facts are that the file system "kinda" sees the files. Here is a result of the ll command.

root@FREENAS01[/mnt/zPool01/ds01/.zfs/snapshot]# ll
ls: zPool01/ds01-Daily-auto-20201013.0000-4w: No such file or directory
ls: zPool01/ds01-Monthly-auto-20201013.0000-26w: No such file or directory

I can't be certain, but it appears that these "snapshot files" are not actually "using" any space. i.e. they are not referencing any blocks. This would be a good thing as they would not unnecessarily use up drive space. However, if they are acting as regular snapshots, then I may be left with migrating the server and reformatting these drives to get rid of these snapshots. What a mess.