External Storage - OCP\Files\ NotPermittedException: Could not create path (AIO 4.0.1)

I can’t see my data in the external storage folder, only the top folders are being shown, but no files.

Running Nextcloud AIO 4.0.1 on Unraid. External Storage is an SMB share on a Truenas VM.

Admin protocol shows “OCP\Files\NotPermittedException: Could not create path” with timestamps fitting every time I’m trying to access the external storage folder.

Ownership/Permissions to the external storage are all set to 33:33 and 770. (33:0 gives the same result)

I’m wondering if this is a Nextcloud error or somehow related to truenas as i set the permissions manually in the shell, which seems to be not supported and “might cause unexpected behaviour”, as they warn in the shell.
Using the Truenas UI to set permissions to sshd:sshd makes all folders in external storage disappear.

After changing ownership from something else to 33:0 or 33:33, I need to remove the external storage and readd it, so the top folders inside the external storage share are being shown.

I don’t know where to keep looking for a solution - does anybody have an idea?


hm… yeah, looks like a permission issue. How is the SMB share mounted? Via fstab? Can you show the fstab entry?

Thank you @szaimen and apologies, I got confused - I didn’t use a SMB mount directly, instead I am mounting the SMB share in unraid and then mapping it to Nextcloud via NEXTCLOUD_MOUNT. I tried to follow the Nextcloud AIO documentation on Github.

Seems I cannot upload the screenshot, maybe a limitation for new forum users?

Then I’m connecting the external storage in Nextcloud Admin panel as a “local” storage, without any credentials and getting a green “check” sign.

I’ve never used fstab before, but isn’t it rather for a VM running NC AIO than for the AIO docker?

Can you show the mount options that you are using there?

I’d love to, but for some reason I cannot upload pics in this forum.

For the mount options: I can’t find the mount config within Unraid, I checked /etc/samba and all conf files there, but the mounts created via gui are not shown there.

Generally the problem with my approach seems to be this:
I wanted to make use of the NEXTCLOUD_MOUNT variable as an elegant way to connect my truenas pool to Nextcloud. Unraid can only access the truenas smb share while the files there are owned by the user who’s user credentials are being used for mounting the smb share. When changing ownership to 33:0 as required from Nextcloud, Unraid loses access to the files, so I suppose these files can’t be provided to Nextcloud anymore.

Is there any workaround to avoid this? There is no user with ID 33 on Freenas, so I can’t just include user 33 to the primary group of my smb share owner (I’m new to permissions, this might be nonsense).

But if I drop that idea of using a Unraid smb mount and map it to Nextcloud via NEXTCLOUD_MOUNT and decide to go for a standard smb mount - there’s still no user 33 in Freenas, so how could freenas allow nextcloud to access the smb share?

Another question connected to this: if I understood this right, the requirement “33:0” refers to ownership “SSHD:root”. While “SSHD” seems to have ID no 33 in some systems, within Truenas SSHD has ID no 22. So would it work if I set ownership within Freenas to SSHD (22) instead of 33? How does ownership/permissions work between systems where user IDs / names are not identical as with SSHD?

This ownership is required no mqtter how the corresponding user/group is named like on your system.

You could try to do that but no idea if that makes it work…

ok, thank you once again for your feedback, @szaimen !
Last question, as I’m thinking of giving up on my original plan to have an additional fast NVMe ZFS share served from Freenas:
Can I just change the NEXTCLOUD_MOUNT destination again while AIO is running already, or can I only do that during initial install and will have to reinstall when changing the mount destination?

You can change the variable by stopping the mastercontainer, removing it and recreating it with changed setting.

Cheers, appreciate it!