Zfs invalid name

TrueNAS General
1

Hello,
I upgraded from 25.04.2.4 to 25.10 RC1 and I am facing the following problem:
In Datasets I have the error: Failed to load datasets:
[EZFS_INVALIDNAME]: zfs_open() failed - cannot open ‘BigData2/Data/xxxx (xxxx)’: invalid character ‘(’ in name.
How can I rename this?
Thank you

2

With the zfs rename command?

1 Like
3

I try this option:
cannot open ‘BigData2/Data/xxxx (xxxx 2017)’: invalid character ‘(’ in name
I renamed it with winscp, removed it (
but the error persists:
failed to load datasets
[EZFS_INVALIDNAME]: zfs_open() failed - cannot open…

4

You need to log in to a shell in your TrueNAS as root and use the command line. Specifically the zfs rename command.

Something like this:

zfs rename 'BigData2/Data/xxxx (xxxx)' 'BigData2/Data/xxxx'

If you have a share defined on that dataset you need to deactivate or remove that first.

1 Like
5

This is what I tried from the beginning:
zfs rename ‘BigData2/Data/xxxx (xxxx)’ ‘BigData2/Data/xxxx’
The result is: invalid character ‘(’ in name
How do I disable this share in CLI?

6

Does it matter that every example yo3 has posted has curly quotes while pmh is using straight quotes?

7

Good point: It does matter if OP’s keyboard plays the same trick when typing shell commands in.

8

It’s appearing to me that the version of ZFS in 25.10 is more restrictive on dataset names than the one in 25.04. Try reverting to 25.04, renaming the dataset there, then going back to 25.10.

I don’t think it does–that looks like Discourse formatting rather than OP’s entry.

“This is a test”

"This is a test"

In both of those, I typed the same (straight) quotes, and the same quotes appear for me in the editor. But in the preview window, the version that isn’t preformatted text shows curly quotes.

2 Likes
9

Someone can also try without quotes and instead use escapes?

zfs rename BigData2/Data/xxxx\ \(xxxx\) BigData2/Data/xxxx
10

I am not sure how it was possible to get parentheses in the dataset name in the first place.

Looking at the code and the blame list it looks like it hasn’t been allowed for ages, if ever:

Is there a way to pick a name that somehow bypasses that namecheck function? Strange.

11

My guess is that there is no such dataset. Please check using zfs list in the shell if you have really have such a dataset.

I suspect that you have some TrueNAS configuration that references a non-existent dataset. Check your task configuration (snapshot tasks, cloud sync tasks, …) if you have anything that relates to that phantom dataset.

2 Likes
12

This is the solution: reverting to 25.04, renaming the dataset there, then going back to 25.10!
Thank you

2 Likes
13

I don’t know how it was possible, but I found backup configurations in it from the FreeNas 9.5 era!

14

I ran into the same problem today after upgrading to 25.10RC:

[EZFS_INVALIDNAME]: zfs_open() failed - cannot open 'pool/foo & bar': invalid character '&' in name

For me, SMB won’t start because of it even though it’s a valid Windows character.

I couldn’t view the “Datasets” page either.

15

We’ve fixed this for 25.10.0. It’s related to us swapping out backend library we use for managing ZFS.

1 Like
16

That’s great! In my case, foo & bar/ was a directory at the root level of a dataset, not the dataset itself.

It doesn’t error on another 25.10RC system that has no SMB shares from that dataset. I’m excited for 25.10.0 to see if this’ll be fixed ;).

17

Is where we’re working on it. No README yet, but functionality slowly expanding. The key focus has been on thread-safety and performance. Once we get it fully written / integrated a lot of backend operations (and correspondingly UI ops) will get much faster.

1 Like
18

That’s fantastic! Glad to see you guys putting a lot of work into improving the UI!

It’s already a big step up from CORE which was originally a nice reskin of FreeNAS.

Glad to see you’re improving the speed because yes, it’s slow (omg snapshots…), especially on my system that has 204 drives!

19

There will be some benefit to handling huge numbers of snapshots from a library perspective, but the performance of handling this info on large systems is complex.

There are different iterator functions zfs_iter_snapshot, zfs_iter_filesystems, etc, that take a particular ZFS dataset (filesystem, zvol) as an argument. They then proceed to issue a series ZFS ioctls to essentially go next → next → next and build out ZFS dataset handles (snapshot, filesystem, zvol) based on what the kernel module returns. How quickly that process completes depends on what information you’ve requested.

If you only need basic information (name, type, createtxg, origin), then it’s fast. Once you step beyond that it takes more time to return. Since we’re talking O(n) here, if n is small, the difference between the two (and loading) is slow. If n is large then the difference ends up being substantial. So the real way to speed up snapshot enumeration is to have less of them per-dataset or request less info from the backend APIs. Note that due to the way libzfs is designed (via callbacks) implementing pagination in backend is not practical. There may be some performance improvements to be had for UIs consuming libzfs indirectly by redesigning parts of libzfs, but that’d be a very big lift.

1 Like
20

Thanks for explaining that! Gives me some idea of the upcoming changes ;).

Also tells me the limitations. CLI tools always make it tough to write APIs unless you hook into zdb directly and basically rewrite chunks of ZFS.