JoeUnraidUser

Try adding the "-l" option to bash and source the ".bash_profile". Example: #!/bin/bash -l source /root/.bash_profile set > /boot/logs/test.log Output: test.log

Is there a documented process of converting the main cache from BTRFS to a ZFS cache? Thanks for any help.

The script trims the Docker logs in the "/var/lib/docker/containers" directory. The script doesn't trim any log files in the "/var/log" directory. You could easily adapt the script to trim the logs in the "/var/log" directory. I am not sure why you are seeing different usage numbers.

".ISdr1c" is a dot file so the script would not see it. Try substituting the following line with the "." Infront of the "*": for dir in "$source"/.*/

Glad you got it fixed. I know some other people had some problems with PUID and PGID being set to 0 which is "root". A PUID of 99 is "nobody" and PGID of 100 is "users" which is the correct way to do it. I also like to set UMASK to 000. If you have any permission problems in the future and need to run the commands to fix them, you don't need to stop your dockers. Just let the commands run and use your dockers as normal.

Is there going to be an automated way to convert the encrypted XFS drive to an encrypted ZFS drive or will we have to move everything off that drive and then move it back again?

To fix the file ownership and permissions for my Dockers I do the following: chown -cR nobody:users /mnt/user/appdata chmod -cR ug+rwX,o-rwx /mnt/user/appdata I set the following settings in each of my dockers to fix ownership and permission problems: PUID = 99 PGID = 100 UMASK = 000 PUID of 99 equates to "nobody", PGID of 100 equates to "users", and UMASK of 000 allows for full access. To fix the ownership and permissions of my array I do the following: chown -cR nobody:users /mnt/disk[0-9]* chmod -cR ug+rwX,o-rwx /mnt/disk[0-9]* To fix the file ownership and permissions on my entire server I do the following: chown -cR nobody:users /mnt/user/appdata /mnt/disk[0-9]* chmod -cR ug+rwX,o-rwx /mnt/user/appdata /mnt/disk[0-9]* You do not have stop your Dockers during the process of fixing the ownership and permissions of the array or the entire server.

I'm not sure why the move didn't work. I used the plugin back when it first came out. I know I did a move and the system didn't crash. I sat there and waited for the move to happen. Maybe something happened to the process. I think the process died in the background during the move. Some files were moved to the new drive, some files were duplicates, and some files were not moved. I just tried the plugin again and I verified the plugin did move the files correctly. So, whatever problem I had back then did not occur again.

It could be a permission setting in your docker configuration. If there is a setting for UMASK, set it to 007. The UMASK would only affect the files created by the docker application. If you created the folders from Windows, I am not sure about why the permissions were set that way. Make sure in the share settings that SMB User Access is set to Read/Write. I have not used Krusader before, however, I was looking at the documentation and it does have the ability to set permissions of files and folders that you create so maybe you could have accidently created them with those permissions.

I have actually had the problem of Dynamix File Manager producing duplicate files on disks in the past. So, I stopped trusting it a while ago. Does it work correctly now?

I am assuming your share is "/mnt/user/Media". If it is not, substitute the name of your share in the command. Run the following from a terminal to fix your file ownership and permissions: chown -cR nobody:users /mnt/user/Media chmod -cR ug+rw,ug+X,o-rwx /mnt/user/Media

I'm not sure about the renaming of files to "[conflicted]", however, never use the "mv" command unless you are really sure what you are doing. It just causes problems. In the future use the program "mc" from the command line to move files between disks and it does not give these problems. You should check it out. Just type "mc" from the command line and it will bring up a very intuitive interface to copy, move, or delete files. Hit tab to go from side to side. You can also right click on files or directories individually to select them instead of moving, copying, or deleting all of them. If you do have problems of duplicate files on disks in the future, use the following script to check for duplicate files on your disks, however, I don't think that is your problem at this time since they do not have the exact same names. UNRAIDFINDDUPLICATES.SH At this point I would do the move again with "mc" and then after that is completed, I would get rid of the "[conflicted]" files or save them off to another directory until you feel comfortable that all your files have been moved.

Is there any advantage to converting the single array drives from XFS to ZFS? If we do convert them to ZFS, would they be faster, slower, or the same speed?

I can't remember but I must have done a New Config to remove the bad drive from that disk assignment and assigned the new disk to that disk assignment and I do remember doing a parity check after adding the disk.

I just replaced the bad drive with the new one and there was no need to rebuild since I had moved all the data off the emulated drive. I just ran a parity check and moved the data back over from the other drives.