Setup: Czkawka docker container on TrueNAS. Czkawka is a great deduping app, extremely fast.
Complaint: Czawka works fine when it comes to detecting duplicate files, except it cannot delete any of them: Failed to delete file <file_name_and _path>, reason Permission denied (os error 13)
Looks like there’s a permission issue. I did some investigation, and learned that I may need to change the ownership of the directory that Czkawka acts on, so that Czkawka can make changes to that directory. The big question is, however, to what user should I change the directory? Presumably to whatever user who owns Czkawka, right? Now, how do I find out what user owns Czkawka? The answer might be this:
admin@nas1:/etc$ ps aux | grep czkawka
1000 1153807 0.0 0.0 133792 42224 ? Ssl+ 20:32 0:04 /usr/bin/czkawka_gui
admin 1240699 0.0 0.0 3744 1536 pts/1 S+ 22:41 0:00 grep czkawka
So it looks like the user ID is 1000, right? What is the user … moniker though? Can I change it to 1000? Here’s what pstree says:
admin@nas1:/etc$ pstree
systemd─┬─asyncio_loop─┬─login───bash───pstree
...
├─containerd-shim─┬─cinit─┬─Xvnc
│ │ ├─czkawka_gui───9*[{czkawka_gui}]
Interestingly, cat /etc/passwd | grep 1000 does not return anything.
Also note that the directory that Czkawka acts on is used primarily by NextCloud.
Anyway, I’d appreciate some help. Many thanks!
Can you change the Czkawka app to run under the UID 3000? For some reason, SCALE’s first created user defaults to 3000, rather than 1000, as most other systems do.
Thanks. How would I go about doing that though? Is this (see below) what you have in mind?
And what would the
Group ID be?
Not familiar with how SCALE handles that with its Apps, but that looks like where you would configure it.
Perhaps both set to 3000.
Thanks. It turns out that the user in Czkawka is handled by means of environment variables, so I made the requisite changes in the container config:
Now querying the owner of the Czkawka process shows me, which is nice:
admin@nas1:/mnt/NextCloud$ ps aux | grep czkawka
dad 1799206 12.4 0.1 271792 78956 ? Ssl+ 12:14 8:13 /usr/bin/czkawka_gui
admin 1845456 0.0 0.0 3744 1408 pts/4 S+ 13:21 0:00 grep czkawka
Nevertheless, Czkawka still does not have write access to the folder. So I looked up the folder ownership, and it shows this:
admin@nas1:/mnt/NextCloud$ ls -latr
total 10
drwxr-xr-x 5 root root 5 Mar 7 10:58 ..
drwxr-xr-x 3 root root 3 Mar 7 16:39 .
drwxrwx--- 4 www-data www-data 8 Mar 7 16:59 data
… namely the www-data built-in user. The question is, now, should I change the owner of this folder to myself? But that might end up breaking NextCloud, wouldn’t it?
It appears that the easiest procedure would be to run Czkawka as this www-data user, however Czkawka just would not run as www-data! What to do?
Perhaps for that dataset, you’ll need to add an ACL entry to grant “dad” read-write permissions?
1 Like
Thanks. Sounds enticing! How would I do that though? 
Lemme guess: go to “Datasets,” select the dataset in question, go to “Permissions,” click on “Edit,” and make the requisite changes, right? Would that, however, (1) add a new ACL, or would it (2) change the existing www-data ACL (which is something I do not want to do!)?
It depends. What are you looking at? Do you see a page that allows you to add more ACL entries? Or does it look like a page to change basic Unix permissions?
You could make a (recursive) snapshot for the dataset, to be safe.
Then Set ACL.
You can pick the “Restricted” preset.
It should retain the same @owner and @group as “www-data” and “www-data”, with typical full control and modify permissions.
Then add a new ACL entry for the user “dad” and give it Basic “Modify” permissions, or however SCALE presents these options for the ACL manager.
1 Like
Gosh, I don’t really know what I am doing, so please bear with me!
Here’s where I got so far (and the official instructions are not very helpful unfortunately):
As you can see, I added a couple of new entries for user dad and for the admin group. Not sure if they are both needed, or just admin would suffice (note that dad is a member of admin). Anyway, one question is, would I have to change the “Owner” and “Owner Group” as well (under the “ACL Editor” heading above)? As far as I am concerned, this dataset can keep its owner, as I want to be as non-intrusive as possible.
Also, should I select Apply permissions recursively? What does it even mean to have certain permissions for the dataset that do not apply to all its folders inside? 
Probably. Otherwise the files and folders will not have the needed write permissions. Is it a large dataset with many files?
Don’t think you need to.
That doesn’t look like the ACL editor I had imagined.
Here’s what the official instructions say about “Apply permissions recursively”: (Optional) Select Apply permissions recursively, below the list of access control entries, to apply this preset to all child **datasets**[!].
Note that there they speak about child datasets(!), not about “directories and files in the current dataset” (see screenshot below)! So which is it? I myself am inclined to believe the former.
Anyway, it’s a mess, and thanks for sticking w/me!
The official Docs have always been all over the place. This wouldn’t be the first time. 
Applying permissions recursively should stay within the dataset. The tooltip says as much.
With Core, this is how it functions:
To also apply to child datasets, you would need to select “Traverse datasets” or “Apply to children”, which only appears after you select the recursive checkbox.
I would guess it’s the same for SCALE.
1 Like
Anyway, I tried to apply the settings illustrated in the screenshot below, and I got an error like this: Named (user or group) POSIX ACL entries require a mask entry to be present in the ACL.
What fresh hell is this now? What “mask entry” would that be?
There’s no option to use NFSv4-style ACL?
NFSv4 ACLs are simpler in general. If you click dropdown for entry type there’s a mask entry. If you’re planning to use POSIX1E you’ll need to define both ACCESS (non-default) and DEFAULT entries for UGO + MASK + any other groups.
1 Like
Thanks. How do I switch to NFSv4 ACL though? Can I convert the current dataset to NFSv4 without destroying the data? So far I can’t see an option anywhere in the “Edit ACL” window.
Alright guys, I finally fixed it, and your help was invaluable–help for which I am very grateful! On my way to arriving at a solution, I stumbled onto an inordinate number of bugs all over the place, though mostly related to TrueNAS environment for apps. So many bugs, in fact, that I lost count. 
I will attempt to list a couple of the most egregious ones in this forum later on. For now, here’s what has been happening:
- The best advice in this saga was to switch to NFSv4 ACL(!), which looks to have made things much simpler. As such, I had to …
- completely remove any and all specks of NextCloud from the machine, including the user data dataset(!), which means that I had to transfer almost 1T of data to … somewhere else. Thankfully, my LAN is 10Gbps, so that took less than 300 days; I guess you could call that a complete raze NextCloud-wise;
- I then built a new dataset following instructions from this; the most important change was that the new dataset was to be built with an
Apps preset, which, among others, makes it an NFSv4 ACL dataset, and gives the apps user “modify” credentials;
- Finally, all it took now was to run Czkawka as this
apps user, and Bob’s your uncle!
Now, when you look at it, it looks fairly simple, but it took me two full days of agony to get there.
Again, thanks to all who replied!
