I messed up permissions. Big time.

[Unhol]

I had permissions set up, they worked. I did something that made them stop work. That something was remove the IX apps folder from the dataset.

Now I can't SMB as admin, nor any user. I can't even grab the files with filebrowser. It simply doesn't have access. I have snapshots enabled, will they most likely fix this issue?

I only want to access the files so I can back them up and then rebuild the whole dataset, since it's a mess and a half. In the screenshot there's the permission errors. It should be Root everywhere. Isn't there any way to fix this?

 

[Unhol]

If I were to use the snapshots, is there any specific one I'd need to rollback? Here's all of them. It's the first time I've had to resort to snapshots and rollbacks.

 

[chuck32]

Don't rollback any snapshots. Go to the Shares Tab and post a screenshot of the ACL settings for your shares your cannot access. Let's work from there.

If you can proceed without further guidance, basically what we're going to do is, verify the users that should have access are still listed with the appropriate permissions, if not add them, and then apply the permissions recursively.

As long as you have access to the GUI this is nothing that can't be salvaged.

Typically the owner and group is root, why did you change that?

 

[Unhol]

After a full night of sleep, I managed to force myself into the files. For the people that messed up like me, I managed to give myself ROOT access by experimenting around (My own user) first from the credentials tab, then the shares one. Needed to give myself the ROOT group in credentials, enable all SUDO. After that, set permissions to that specific root user in ACL.

This wasn't however the only step I did. I also did

Code:

sudo chown (my user name):root /path/to/directory/

on the WHOLE DATASET. This managed to change the user, but the group still had no permissions. I was able to work just with the user, leaving the group behind.

From there, I was able to access all the data. I don't know if chown was required, it most likely was, since I tried giving myself root yesterday and I was not able to access files at all.

I wasn't able however to copy the data, there was one empty folder that had access OVER ROOT. I just skipped it and now I'm able to copy all of the data.

Here's the error I've been getting before my actions:

This error would happen if some user DIDN'T have root access.

I have no clue how this could even happen, simply by removing the apps folder from the dataset, but it did. A simple thing like that caused the whole dataset to have only root access.

 

[Unhol]

Typically the owner and group is root, why did you change that?

I didn't, that's the issue. I bet the apps that were installed on that dataset caused that change somehow. Might be something I did, but I'm not certain how that happened.

 

[Unhol]

My current plan is to rip/copy all of the data on a local drive, destroy that dataset, build a new one, import all the data and done. Shouldn't be too complex... hopefully without more issues.

 

[chuck32]

Personally I would have preferred to set the permissions via the GUI. Some edge cases I stand by my post, that you could have and still can fix the ACLs without the need to destroy anything.

Also the error message gave you the clou, probably your user you used to access the data (did you use admin for SMB?) didn't have the execute permission. The execute permissions enabled changing directories.

We can go through your ACL settings or you start from scratch (but wouldn't that also include setting permissions?).

I can't imagine that deleting ix-applications screwed up your permissions. Did you also delete the system dataset? As far as I'm concerned the ix-applications dataset isn't related to the permissions. And also I'm not sure if the latter only holds information on the SMB permissions. Some people here, me included seem to leave smb as it is and change the file permissions (ACL).

 

[anodos]

The error message looks like you did a manual "chmod 770" or such on the /mnt/DOM_DATA_ALL. This will break access (not just SMB) for all non-root processes. There are unfortunately some prominent youtube howtos that quite ignorantly say to do this. What is the output of stat /mnt/DOM_DATA_ALL?

 

[Unhol]

Personally I would have preferred to set the permissions via the GUI. Some edge cases I stand by my post, that you could have and still can fix the ACLs without the need to destroy anything.

Couldn't. That's the root directory. I can't change anything in there via GUI. I tried multiple times setting permissions the right way, I did them over 20-40 times just to make sure I did not do anything wrong, nothing was working at all

The error message looks like you did a manual "chmod 770" or such on the /mnt/DOM_DATA_ALL

I didn't. No command was done prior to everything breaking apart, besides installing some apps in that directory and removing them after. After removing them, everything broke.

I might also add, that specific directory had the apps folder fully corrupted. There were several permanent files with errors. Writing to the drive would cause even more errors (Chcksum). Now when I removed that file fully, no Chcksum, at all, even under heavy writes.

Also the error message gave you the clou, probably your user you used to access the data (did you use admin for SMB?) didn't have the execute permission. The execute permissions enabled changing directories.

In fact execute was enabled. Everything regarding read/write/execute was enabled, hell, even sudo was enabled and I still couldn't gain access through any user other than root. Only granting root to some user (through groups) made everything click.

We can go through your ACL settings or you start from scratch (but wouldn't that also include setting permissions?).

I think it's better to start over. The setting permissions should be already set, only would need to correct ACL on the new dataset. If I would need to re-do the settings, it's no big deal. There's 4 users in total with only 1 shared directory. I already have the full copy of the data on there on my local PC (Isn't much, about 500-600GB)

I can't imagine that deleting ix-applications screwed up your permissions. Did you also delete the system dataset? As far as I'm concerned the ix-applications dataset isn't related to the permissions. And also I'm not sure if the latter only holds information on the SMB permissions. Some people here, me included seem to leave smb as it is and change the file permissions (ACL).

Yeah, I did not think anything would break too, yet it did. There wasn't any system dataset on there as far as I know. Apps like filebrowser from truenas also stopped working. It couldn't and still can't gain access to that directory at all. I also just leave SMB and configure ACL, this dataset was configured through ACL without any code from my side or anything. One issue I noticed, Immich was not able to create additional storage on that dataset, so that might've hinted at some problems already.

stat /mnt/DOM_DATA_ALL

Code:

admin@truenas[~]$ sudo stat /mnt/DOM_DATA_ALL
[sudo] password for admin:
  File: /mnt/DOM_DATA_ALL
  Size: 6               Blocks: 24         IO Block: 512    directory
Device: 0,59    Inode: 34          Links: 6
Access: (0700/drwx------)  Uid: ( 3001/   tomek)   Gid: (    0/    root)
Access: 2024-02-28 13:07:11.783179189 +0100
Modify: 2024-03-26 02:24:39.381464484 +0100
Change: 2024-03-26 03:21:53.513018239 +0100
 Birth: 2024-02-28 13:07:11.783179189 +0100
admin@truenas[~]$ 

 

[anodos]

Code:

admin@truenas[~]$ sudo stat /mnt/DOM_DATA_ALL
[sudo] password for admin:
  File: /mnt/DOM_DATA_ALL
  Size: 6               Blocks: 24         IO Block: 512    directory
Device: 0,59    Inode: 34          Links: 6
Access: (0700/drwx------)  Uid: ( 3001/   tomek)   Gid: (    0/    root)
Access: 2024-02-28 13:07:11.783179189 +0100
Modify: 2024-03-26 02:24:39.381464484 +0100
Change: 2024-03-26 03:21:53.513018239 +0100
 Birth: 2024-02-28 13:07:11.783179189 +0100
admin@truenas[~]$

There's your problem. You (or an app you've granted access to /mnt/DOM_DATA_ALL) has performed chmod 0o700 on /mnt/DOM_DATA_ALL. This breaks access for all users who aren't `tomek`. Run the command chmod 755 /mnt/DOM_DATA_ALL to restore execute to your other users.

You have to manually run chmod from shell because our backend prevents changes on permissions to that path (specifically to avoid these sorts of problems).

 

[Unhol]

I've already fully cleared and destroyed the pool, but thank you for the answer! This will help in case some app breaks access again.

 

[anodos]

I've already fully cleared and destroyed the pool, but thank you for the answer! This will help in case some app breaks access again.

There are unfortunately some poorly-vetted apps (especially in third-party repos) that can perform unexpected operations to change permissions on "host paths". Whenever possible, you should avoid setting pool mountpoints as host paths for apps (create dedicated datasets for this).