Unable to delete Dataset on 25.04.1

I have migrated from Core to Community Edition and am unable to delete a dataset in the web GUI, even for newly created datasets.

I’m logged in as root user (migrated from core) and receiving [Errno 13] Permission denied: '/proc/9861/fd/10' error below:

Details:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/middlewared/api/base/server/ws_handler/rpc.py", line 323, in process_method_call
    result = await method.call(app, params)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/middlewared/api/base/server/method.py", line 40, in call
    result = await self.middleware.call_with_audit(self.name, self.serviceobj, methodobj, params, app)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/middlewared/main.py", line 906, in call_with_audit
    result = await self._call(method, serviceobj, methodobj, params, app=app,
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/middlewared/main.py", line 715, in _call
    return await methodobj(*prepared_call.args)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/middlewared/schema/processor.py", line 174, in nf
    return await func(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/middlewared/schema/processor.py", line 48, in nf
    res = await f(*args, **kwargs)
          ^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/middlewared/plugins/pool_/dataset_processes.py", line 50, in processes
    return await self.middleware.call('pool.dataset.processes_using_paths', paths)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/middlewared/main.py", line 1000, in call
    return await self._call(
           ^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/middlewared/main.py", line 726, in _call
    return await self.run_in_executor(prepared_call.executor, methodobj, *prepared_call.args)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/middlewared/main.py", line 619, in run_in_executor
    return await loop.run_in_executor(pool, functools.partial(method, *args, **kwargs))
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/concurrent/futures/thread.py", line 58, in run
    result = self.fn(*self.args, **self.kwargs)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/middlewared/plugins/pool_/dataset_processes.py", line 173, in processes_using_paths
    (include_devs and os.stat(fd).st_dev in include_devs) or
                      ^^^^^^^^^^^
PermissionError: [Errno 13] Permission denied: '/proc/9861/fd/10'

Here is the output of zfs list -r -o name,exec boot-pool:

NAME                                                        EXEC
boot-pool                                                   on
boot-pool/.system                                           on
boot-pool/.system/configs-a2e19c264e06446d8804a27c3d55486f  on
boot-pool/.system/cores                                     on
boot-pool/.system/rrd-a2e19c264e06446d8804a27c3d55486f      on
boot-pool/.system/samba4                                    on
boot-pool/.system/services                                  on
boot-pool/.system/syslog-a2e19c264e06446d8804a27c3d55486f   on
boot-pool/.system/webui                                     on
boot-pool/ROOT                                              on
boot-pool/ROOT/24.04.2.5                                    on
boot-pool/ROOT/24.04.2.5/audit                              off
boot-pool/ROOT/24.04.2.5/conf                               off
boot-pool/ROOT/24.04.2.5/data                               off
boot-pool/ROOT/24.04.2.5/etc                                off
boot-pool/ROOT/24.04.2.5/home                               off
boot-pool/ROOT/24.04.2.5/mnt                                off
boot-pool/ROOT/24.04.2.5/opt                                on
boot-pool/ROOT/24.04.2.5/root                               on
boot-pool/ROOT/24.04.2.5/usr                                on
boot-pool/ROOT/24.04.2.5/var                                on
boot-pool/ROOT/24.04.2.5/var/ca-certificates                off
boot-pool/ROOT/24.04.2.5/var/log                            off
boot-pool/ROOT/24.10.2.2                                    on
boot-pool/ROOT/24.10.2.2/audit                              off
boot-pool/ROOT/24.10.2.2/conf                               off
boot-pool/ROOT/24.10.2.2/data                               off
boot-pool/ROOT/24.10.2.2/etc                                on
boot-pool/ROOT/24.10.2.2/home                               off
boot-pool/ROOT/24.10.2.2/mnt                                off
boot-pool/ROOT/24.10.2.2/opt                                on
boot-pool/ROOT/24.10.2.2/root                               on
boot-pool/ROOT/24.10.2.2/usr                                on
boot-pool/ROOT/24.10.2.2/var                                on
boot-pool/ROOT/24.10.2.2/var/ca-certificates                off
boot-pool/ROOT/24.10.2.2/var/log                            off
boot-pool/ROOT/24.10.2.2/var/log/journal                    off
boot-pool/ROOT/25.04.1                                      on
boot-pool/ROOT/25.04.1/audit                                off
boot-pool/ROOT/25.04.1/conf                                 off
boot-pool/ROOT/25.04.1/data                                 off
boot-pool/ROOT/25.04.1/etc                                  on
boot-pool/ROOT/25.04.1/home                                 off
boot-pool/ROOT/25.04.1/mnt                                  off
boot-pool/ROOT/25.04.1/opt                                  on
boot-pool/ROOT/25.04.1/root                                 on
boot-pool/ROOT/25.04.1/usr                                  on
boot-pool/ROOT/25.04.1/var                                  on
boot-pool/ROOT/25.04.1/var/ca-certificates                  off
boot-pool/ROOT/25.04.1/var/lib                              on
boot-pool/ROOT/25.04.1/var/lib/incus                        on
boot-pool/ROOT/25.04.1/var/log                              off
boot-pool/ROOT/25.04.1/var/log/journal                      off
boot-pool/ROOT/Initial-Install                              on
boot-pool/ROOT/default                                      on
boot-pool/grub                                              on

And here is the output for zfs list -r -o name,exec Storage/.system :

NAME                                                      EXEC
Storage/.system                                           on
Storage/.system/configs-a421eaccddb44c098d96b72146b5211d  on
Storage/.system/configs-ae32c386e13840b2bf9c0083275e7941  on
Storage/.system/configs-cadb1ce96f8c4a01a65be3ef8f5cb996  on
Storage/.system/cores                                     on
Storage/.system/netdata-a421eaccddb44c098d96b72146b5211d  on
Storage/.system/netdata-ae32c386e13840b2bf9c0083275e7941  on
Storage/.system/nfs                                       on
Storage/.system/rrd-a421eaccddb44c098d96b72146b5211d      on
Storage/.system/rrd-cadb1ce96f8c4a01a65be3ef8f5cb996      on
Storage/.system/samba4                                    on
Storage/.system/services                                  on
Storage/.system/syslog-a421eaccddb44c098d96b72146b5211d   on
Storage/.system/syslog-cadb1ce96f8c4a01a65be3ef8f5cb996   on
Storage/.system/webui                                     on

This is the permission of the root Dataset:

I know I can still use ZFS Destroy to delete a dataset, but I wonder why it no longer works on the Web interface.

What user are you logging in as in the web UI?

Why are you showing us properties of your boot-pool datasets and System Dataset children?

Folder permissions have nothin to do with destroying ZFS datasets.

This was already posted in the second paragraph of the initial post. The user is root.

Because it’s been requested for the same [Errno 13] Permission denied (although on a different operation) by you on here Here

If it’s not needed for diagnosis, ignore.

Correct. That was a different issue unrelated to deleting datasets in the GUI.


Which dataset were you trying to delete?

Perhaps a non-root admin user needs to be created in order to delete storage datasets with the GUI? It gets nebulous with SCALE/CE.

Any dataset, any old one or if I create a new one with any permission, then I can’t remove it with the GUI and have to do ZFS Destroy -r /Storage/test-dataset

Yes, I’m considering it, but I have some issues with it. With a GUI, it creates the user and expects me to put the admin home directory under my dataset instead of /home, which I prefer not to do. If I do it manually, then there are some quirks with adding an authorised SSH key from the GUI. That’s a different issue I’m considering to find the best solution for. The correct approach would have been to have a feature in place during the TrueNAS Core upgrade process that automatically creates a ready-to-use truenas_admin account for users, allowing them to disable root login and use that account instead.

I might start by creating a config backup file, reinstalling, and then restoring the backup, and going from there. It’s just weird that it started happening a few days after the update, not straight away.

Reinstalled TrueNAS, imported my pool, and restored my configuration.
Created an admin account and logged in as admin.
Same issue, [Errno 13] Permission denied: '/proc/9861/fd/10' when trying to delete dataset from GUI.

Can you unmount the dataset in the command-line and then try to destroy it in the GUI?

zfs umount Storage/mydataset

What is running as pid 9861? cat /proc/<pid>/status (based on whatever pid is reported in error). You’ll have to do this via sudo / root.

It’s now on 9145:

run-httpd, and here is the output:

root@Home-NAS[~]# cat /proc/9145/status 
Name:	run-httpd
Umask:	0022
State:	S (sleeping)
Tgid:	9145
Ngid:	0
Pid:	9145
PPid:	8682
TracerPid:	0
Uid:	2147000001	2147000001	2147000001	2147000001
Gid:	2147000001	2147000001	2147000001	2147000001
FDSize:	128
Groups:	 
NStgid:	9145	394
NSpid:	9145	394
NSpgid:	9145	394
NSsid:	9145	394
Kthread:	0
VmPeak:	    4652 kB
VmSize:	    4652 kB
VmLck:	       0 kB
VmPin:	       0 kB
VmHWM:	    1444 kB
VmRSS:	    1444 kB
RssAnon:	       0 kB
RssFile:	    1444 kB
RssShmem:	       0 kB
VmData:	     196 kB
VmStk:	     132 kB
VmExe:	     112 kB
VmLib:	    2120 kB
VmPTE:	      52 kB
VmSwap:	       0 kB
HugetlbPages:	       0 kB
CoreDumping:	0
THP_enabled:	1
untag_mask:	0xffffffffffffffff
Threads:	1
SigQ:	1/511049
SigPnd:	0000000000000000
ShdPnd:	0000000000000000
SigBlk:	0000000000000000
SigIgn:	0000000000000000
SigCgt:	0000000000010002
CapInh:	0000000000000000
CapPrm:	000001ffffffffff
CapEff:	000001ffffffffff
CapBnd:	000001ffffffffff
CapAmb:	0000000000000000
NoNewPrivs:	0
Seccomp:	2
Seccomp_filters:	3
Speculation_Store_Bypass:	thread vulnerable
SpeculationIndirectBranch:	conditional enabled
Cpus_allowed:	078
Cpus_allowed_list:	3-6
Mems_allowed:	00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000001
Mems_allowed_list:	0
voluntary_ctxt_switches:	672
nonvoluntary_ctxt_switches:	159
x86_Thread_features:	
x86_Thread_features_locked:	
root@Home-NAS[~]# 

That will add a second error on top of [Errno 13] Permission denied:

Try unsetting the app-pool and deleting the dataset, when the pool is unset.
After deleting the dataset you can set the pool for the apps again.

What app is this? It’s odd that root can’t stat the file (this is what is breaking checks).

Indeed, would an app show up as “run-httpd” or would it show as “docker”-something?

For some reason my malware sense is tingling.

Unset the app pool—same error.

You guys put me on the right track.

It’s my Nextcloud Incus container instance. As soon as I stopped it, I could delete the dataset again.
It’s weird because it’s just an Ubuntu LTS container with Nextcloud snap installed and nothing else.

Hmm can you readlink /proc/<pid>/<fd> for the fd that’s causing problems?

Not a malware. Ubuntu is from the container image below:

And Nextcloud is the official Nextcloud Snap package.
I think run-httpd is just part of this Nextcloud snap package.

That explains why the deleting dataset issue started after a few days, because I hadn’t configured this container yet.

Wired that Incus container which in theory should be a contained VM, can mess with the host like that.

Indeed, that is pecuiliar. How did you link the container to the host? Did you give it access to your whole /mnt/tank pool ?

I don’t understand how it could interfere with datasets you literally just created otherwise.

No, Incus does not have any mount to my Storage pool. I didn’t add anything:

It’s using its own storage from inside the VM/container: