Storage Dataset File Permissions Change After Reboot

[sfatula]

I guess I am still new but learning about Scale, still this surprises me. I have a dataset under Storage. My storage pool is tank, and, the dataset is Scripts. Underneath Scripts mountpoint, is a directory keys. That has ssh keys for various scripts I need to run periodically. The Keys directory was permissions 600, as were the keys under it. After a reboot, it changes both the key files and Keys directory to 770, which of course makes my scripts fail since ssh doesn't like that.

I don't understand why it is changing permissions of a datasets contents.

 

[anodos]

I guess I am still new but learning about Scale, still this surprises me. I have a dataset under Storage. My storage pool is tank, and, the dataset is Scripts. Underneath Scripts mountpoint, is a directory keys. That has ssh keys for various scripts I need to run periodically. The Keys directory was permissions 600, as were the keys under it. After a reboot, it changes both the key files and Keys directory to 770, which of course makes my scripts fail since ssh doesn't like that.

I don't understand why it is changing permissions of a datasets contents.

Any permissions change we initiate happens through the filesystem API and actions are logged in the middleware job log. `midclt call core.get_jobs | jq` will pretty-print it.

 

[sfatula]

I don't see it in there. But I've rebooted 3 times, the last 2 times I did one thing after bootup, I changed permissions of the dataset subdirectory and it changed back after reboot. Scary as it makes me wonder if all the persistent storage paths might be changing too.

 

[anodos]

I don't see it in there. But I've rebooted 3 times, the last 2 times I did one thing after bootup, I changed permissions of the dataset subdirectory and it changed back after reboot. Scary as it makes me wonder if all the persistent storage paths might be changing too.

What are the precise steps you are performing? Are you making changes through the webui or shell? If latter what commands are being run? What are exact paths?

 

[sfatula]

So, path is /mnt/tank/Scripts for the dataset mount point, /mnt/tank/Scripts/Keys for the ssh keys directory, and, /mnt/tank/Scripts/Keys/id_home_server for example for a keyfile.

I execute chmod 600 /mnt/tank/Scripts/Keys/id_home_server

Before reboot:

/mnt/tank/Scripts is 775 root:apps
/mnt/tank/Scripts/Keys is 775 root:apps
/mnt/tank/Scripts/Keys/id_home_server is 600. root:apps

reboot

After:
/mnt/tank/Scripts/Keys/id_home_server is 670. root:apps

It appears (to me) that perhaps truenas Scale is trying to make sure as a wild guess that the groups apps has access to the file perhaps?

 

[anodos]

So, path is /mnt/tank/Scripts for the dataset mount point, /mnt/tank/Scripts/Keys for the ssh keys directory, and, /mnt/tank/Scripts/Keys/id_home_server for example for a keyfile.

I execute chmod 600 /mnt/tank/Scripts/Keys/id_home_server

Before reboot:

/mnt/tank/Scripts is 775 root:apps
/mnt/tank/Scripts/Keys is 775 root:apps
/mnt/tank/Scripts/Keys/id_home_server is 600. root:apps

reboot

After:
/mnt/tank/Scripts/Keys/id_home_server is 670. root:apps

It appears (to me) that perhaps truenas Scale is trying to make sure as a wild guess that the groups apps has access to the file perhaps?

Are you using TrueCharts with this or a parent as a HostPath? IIRC TrueCharts (third-party project) will recursively alter permissions on host paths. If this is the case here, you may wish to file an issue with them as it's pretty clearly a POLA violation in my opinion.

 

[sfatula]

Nothing is using the Scripts dataset as a Hostpath, it's merely a place to store stuff for me (root). Well, I say that, the only thing I can think of is I am using Duplicati backup which is a truecharts app. It accesses all datasets for backup purposes, so, tank is a hostpath for it. Perhaps it (Truecharts) is what is causing the issue. Yes, I do not want them to recursively alter permissions.

 

[anodos]

It accesses all datasets for backup purposes, so, tank is a hostpath for it. Perhaps it (Truecharts) is what is causing the issue. Yes, I do not want them to recursively alter permissions.

IIRC I saw TrueCharts doing this in kubernetes logs in a debug. Check under /var/log you can probably get some details. If it's recursively changing perms on /mnt/tank then that's your root cause.

 

[ksimm1]

You can disable this behavior in TrueCharts apps by unchecking the "Automatic Permissions" option for hostpath storage.