appdata permissions


Recommended Posts

Hey guys, I replaced my cache SSD recently and several of my dockers have stopped working. After some help from the LS.IO guys on discord, we have figured out my permissions for appdata are all messed up. I prolly did something wrong.

 

What's the procedure to redo those permissions so that appdata is accessible normally again?

Link to comment

I just had a look at my own appdata and, while the majority of files are owned by nobody:users with mode 644, 664 or 666 and the majority of directories are owned by nobody:users with mode 755, 775 or 777, it's by no means universal. Ownerships and permissions are dependent on the docker containers themselves and are subject to the whims of their authors. Often you can configure what user a container runs as and usually the default is nobody but it can be changed and it isn't universal. That's why there's a docker-safe version of New Permissions that leaves them unchanged. Depending on how you backed up your SSD you might find that some of your appdata files are now owned by root. Maybe if you make a list of your dockers and their authors people can help you fill in the blanks.

Link to comment

AFAIK, the two big ones that aren't working are Let's encrypt and Nextcloud. I have the original SSD but I used the procedure in the unraid manual and I set all those shares to not use the cache, shut off docker and VM engines, invoked mover, swapped the drives, reenabled the use of the cache drive and invoked mover again. So the original drive doesn't have appdata folders on it anymore. Man, what else can I do? Im pretty useless when it comes to a lot of this stuff so setting up nextcloud and let's encrypt in the first place was not by any means an easy thing for me to do and I would prefer to not have to do it all over again.

 

Was my procedure for replacing the SSD wrong? Was there a better way to handle this?

Link to comment
1 hour ago, cammelspit said:

After some help from the LS.IO guys on discord, we have figured out my permissions for appdata are all messed up.

 

1 hour ago, cammelspit said:

What's the procedure to redo those permissions so that appdata is accessible normally again?

Just having some fun here, but don't they know what the permissions are supposed to be?

 

Edited by Squid
Link to comment
17 minutes ago, cammelspit said:

I set all those shares to not use the cache

The procedure is correct but that^^ isn't. If you set appdata (and others) not to use cache then the mover will ignore its files. The correct way to do it is to change from Use cache:Prefer to Use cache:Yes. Then the mover will move the appdata files to the array (preserving the permissions).

 

I don't use either LetsEncrypt or Next Cloud but as they are both security-related it's possible that they run as a specific user rather than nobody. Maybe ask in their support threads?

Link to comment

@John_M

Ok, I meant I did indeed set them to 'yes', mover, swap drives, set to 'prefer', mover, now it's all broken.

 

@Squid

Frankly? I have no idea... I'm still kinda sad right now tho. No idea how hard it will be to get everything just right again if I decided to just toss out my current installs of these dockers and start over. THough, following the procedure in the unraid wiki shouldn't have caused this problem I would have thought.

https://wiki.unraid.net/Replace_A_Cache_Drive

I just did what this said to do.

Link to comment

For example, I have this when I look at the files. From what I have read, I don't think I am supposed to have all dashes right? This means I don't have permissions to do anything with the files. I think...

 

image.png.7b24a10ab7ee8e691645f0ac4a9b22f0.png

 

So it all boils down to the fact that mover somehow dropped my permissions on the files. I just need to know how to allow user nobody to be able to read and write these files again. I think I have some idea what's going on I just don't know how to fix it.

Link to comment

Yes. The dashes mean neither read nor write access. However, most of those files have zero length so only the names were copied and not the content. That isn't what mover does. If it can't move a file it leaves it where it is. There must have been some problem with the move - either it was interrupted or the destination was full. Did you confirm that the old cache drive was actually empty of files before you removed it?

Link to comment

Er, you know... I don't think I did. Shit, maybe those missing files are still on the SSD... It's in the server still but fully disconnected since I also added two more 10TB drives to the system and they are preclearing now. The preclear will be done later today so once that happens I can maybe pull the drive out, use a USB adapter and plug it in. If the files are there I can then see about copying them over. Hmm, that might work assuming they are still there.

 

Yeah, I think that is what I am going to do. Hope to god it fixes it. Well, I'll be sure to keep you posted but it seems I can't do anything at all in that area till tonight or perhaps even tomorrow morning. Thanks for the tip.

Link to comment

Had you actually created keys and certificates with LetsEncrypt? The only instance where these files could legitimately be zero length is as placeholders, before the keys have been generated. Maybe they are meant to have no access permissions by default for security purposes. Storing private keys in appdata and readable and writable by the nobody user is not very secure, is it? That would be a question for the relevant support thread.

Link to comment

I believe you have more wrong other than file permissions, however, to fix your appdata permissions for Let's Encrypt and Nextcloud do the following:

chown -cR nobody:users /mnt/user/appdata/letsencrypt /mnt/user/appdata/nextcloud
chmod -cR ug+rw,ug+X,o-rwx /mnt/user/appdata/letsencrypt /mnt/user/appdata/nextcloud

fixAppdataPerms.sh

Edited by JoeUnraidUser
  • Like 2
  • Thanks 1
Link to comment

Whelp, there was data left on the old SSD but unfortunately, it didn't work copying it over. It was only a small snippet of the databases folder for MariaDB and nothing for LE or Nextcloud. All I can assume is running the dockers without their proper data somehow damaged it beyond repair. At this point, the only thing I can do really is just going on ahead and reinstall let's encrypt, MariaDB and Nextcloud again from scratch and try to be more careful next time. Still sucks that the 'proper' procedure outlined in the WIKI was not apparently enough to work properly but I guess if I was more experienced I would have caught the issue beforehand and I wouldn't have had to deal with this problem in the first place. 😢

 

Link to comment
  • 5 months later...
On 11/28/2018 at 5:33 AM, JoeUnraidUser said:

I believe you have more wrong other than file permissions, however, to fix your appdata permissions for Let's Encrypt and Nextcloud do the following:


chown -cR nobody:users /mnt/user/appdata/letsencrypt /mnt/user/appdata/nextcloud
chmod -cR ug+rw,ug+X,o-rwx /mnt/user/appdata/letsencrypt /mnt/user/appdata/nextcloud

 

Running into this issue now too. the chmod for letsencrypt gives the error chmod: invalid mode: ‘ug+rw,ug+X,o-rwx’

Link to comment

try it again.  I repasted into the post for some reason there was a special character pasted in the code.

chown -cR nobody:users /mnt/user/appdata/letsencrypt /mnt/user/appdata/nextcloud
chmod -cR ug+rw,ug+X,o-rwx /mnt/user/appdata/letsencrypt /mnt/user/appdata/nextcloud

 

Edited by JoeUnraidUser
  • Thanks 1
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.