bmartino1

what unraid version, what hardware resources. Sound like expecting to much from your compute...

Silicone lottery...

unraid vs truenas

Truenas only has a proper zfs implementation with vdev. in terms of how pools and hardrives should be manged. 

Having helped with scale and there change from core (some of there blocking was due to my workaround and edits... so i left) after bluefin fisaoc on helm...
truenas is constanly breaking things they should be touch as they try to become more unraid like... in the end truenas needs to chose one k3 or k8 not both...

SO yes a diag would be nice as it helps us see what is going on. if you don't have time thanks for trying therir product. as what won't work for you may work for another...

You should try emailing support... As this is a public forum... not much sympathy here...
having tested and ran unraid yes there quite a few things to hate. but it still better then the alternaitves...

Proxmox - VMS (sometimes LXC) we will see due to help scripts and the comunity
Truenas hba HD zfs sytems.. all the way...
Unriad DOCKER!!!

I personlay wouldn't do sub pools on unraid yet. Unraid needs a little more polish in the Web UI for ZFS before I recommend that. They are starting to do better with vdevs on raidz2.
 
Notes:
L2ARC and SLOG require thoughtful tuning to see real benefits. By default, Unraid’s beta ZFS support might not optimize for these; you may need to tweak zfs parameters manually.
ZFS pools don’t have to match the size of your workload perfectly for caching, but over-provisioning cache for workloads that don’t need it can be wasteful.
Monitor performance and scale as needed—your hardware is future-proofed for significant upgrades.
*Its best to keep same type of nvme in a zfs pool this is to keep with same partition blocks and speed.
 
Your Setup Analysis
Main ZFS Pool (HDDs):
You already have a 4x 22TB HDD pool in RAID-Z2, which is an excellent choice for redundancy and resilience for a media server. RAID-Z2 provides two-disk fault tolerance, crucial for large capacity drives where rebuilds take significant time.
Cache Pool Options (NVMe):
The three 1TB NVMe drives are versatile. You could either use them for a simple RAID-Z1 cache pool or leverage ZFS-specific features like L2ARC, SLOG, or a special metadata pool.
 
Key Considerations
 
1. Cache Pool Design
RAID-Z1 Cache Pool:
This is straightforward, provides redundancy, and boosts write performance. This is an easy setup for caching frequently accessed data.
Sub-Pools with Specialized Roles:
L2ARC (Read Cache): Good for speeding up reads of frequently accessed files. Useful if your Plex server or VMs access the same data repeatedly.
SLOG (Write Cache): Useful if you enable synchronous writes, which some workloads (like VMs or video editing) might benefit from. However, unless your workload heavily depends on synchronous writes, this may not be necessary.
Special Metadata Pool: Great for indexing and metadata-heavy workloads, which can significantly boost filesystem traversal and Plex library scans.
 
2. Future Expandability
If you plan on scaling workloads (e.g., hosting more VMs or increasing Plex library size), you might consider adding more or larger NVMe drives to handle L2ARC/SLOG/special pools independently.
Recommendation for Your Setup
Main ZFS Pool:
Stick with your 4x 22TB RAID-Z2 for the HDDs. It balances redundancy and capacity well.
 
NVMe Cache:
If simplicity is key, use a RAID-Z1 configuration for all three NVMe drives as a single cache pool.
If you want to leverage ZFS's advanced features:
Dedicate 1 NVMe drive for a SLOG. Even though your 12600K may not fully stress ZFS synchronous writes, this ensures optimal VM and video editing performance.
Use 2 NVMe drives in a mirror configuration for a special metadata pool and L2ARC. This improves performance for Plex library scans and other metadata-intensive tasks.
Larger/More NVMes:
If you want the most out of ZFS, especially for VMs and heavy video editing workloads, consider adding at least one more NVMe for better separation of SLOG, L2ARC, and metadata pools.
 
 
 

Experiencing the error NzbDrone.Common.Exceptions.SonarrStartupException: Sonarr failed to start: Error creating main database in your Sonarr Docker container indicates an issue with the application's database, which is crucial for its operation. Here's a structured approach to diagnose and resolve this problem:
 
1. Identify the Database Issue:
Corruption: The database file (nzbdrone.db) might be corrupted, preventing Sonarr from accessing or creating necessary tables.
Permissions: Sonarr may lack the required permissions to read or write to the database file or its directory.
 
2. Verify File Permissions:
Access the Appdata Directory:
Navigate to your Sonarr configuration directory, typically located at /mnt/user/appdata/sonarr/.
 
Check Permissions:
Ensure that the nzbdrone.db file and its parent directory have appropriate read and write permissions for the user under which the Docker container operates.
Adjust Permissions if Necessary:Use the chmod command to modify permissions:
chmod 755 /mnt/user/appdata/sonarr/ chmod 644 /mnt/user/appdata/sonarr/nzbdrone.db  
Alternatively, you can reset permissions using Unraid's built-in tools or community plugins designed for this purpose.
WebUI > Tool > Docker Safe PErm
 
Restore from a Backup if you have one...
Locate Backups:
If you have previously configured Sonarr to create backups, they are usually stored in the Backups folder within the Sonarr configuration directory.
Restore Process:
Stop the Sonarr Docker container to prevent any conflicts.
Replace the corrupted nzbdrone.db file with a recent backup.
Restart the Sonarr container and verify if the application starts without errors.
 
4. Rebuild the Database:
Backup Existing Database:
Before making changes, create a backup of the current nzbdrone.db file.
Recreate the Database:
Stop the Sonarr container.
Delete or rename the existing nzbdrone.db file.
Start the Sonarr container; it should generate a new, clean database file.
Reconfigure Sonarr:
With a new database, you'll need to reconfigure your settings and re-add your series.
 
5. Monitor for Recurrence:
Regular Backups:
Set up automated backups within Sonarr to safeguard against future database issues.
System Stability:
Ensure your Unraid server is stable, and consider using an Uninterruptible Power Supply (UPS) to protect against power-related disruptions that could corrupt the database.
For further assistance, consider consulting the Unraid community forums or the Sonarr support channels, where similar issues have been discussed and resolved
 
 
 
By following these steps, you should be able to address the database error and restore Sonarr's functionality.

not much help general toruble shooting...
From the syslog provided...
 
Key Observations
Unclean Shutdown:
The unclean shutdown likely caused the array to trigger an automatic parity check. If there was ongoing disk activity or the disks were not properly unmounted, this might lead to inconsistencies.
Initial Parity Check Issues:
Parity speed dropped to <1kbps, indicating a significant issue, likely related to:
Disk I/O problems.
Disk health issues or pending sectors.
Potential filesystem corruption.
Forced Reboot and Lock-Up:
The forced reboot may have exacerbated filesystem inconsistencies or caused additional stress on the hardware, leading to the lock-up.
Current Status:
After the second reboot, the parity check is running at ~200MB/s, indicating some temporary issues may have resolved, but further checks are necessary.
 
Check Disk Health
Run SMART tests on all drives to identify potential disk issues:
Go to Main > Devices in the Unraid GUI.
Select each drive and review SMART attributes, particularly:
Reallocated Sectors.
Pending Sectors.
Errors in the SMART error log.
Run a short or extended SMART test for each drive.
Look for any failing drives or disks that might be causing I/O bottlenecks.
 
Verify Filesystem Integrity
The forced shutdown might have left filesystems in a corrupted state. Check and repair the filesystems:
Stop the array in the Unraid GUI.
For each disk:
Click on the disk, then select Check Filesystem.
Run the check in Read-only mode first to identify issues.
If issues are found, repeat with the option to repair.
 
Investigate Share and Pool Issues
The logs mention warnings about share configuration:
Share Configuration Warnings:
Some shares (e.g., backups, docker) have files spread across multiple pools (scratch, scratch_old, and apps).
This can cause issues during system startup or array operations.
Action:
Consolidate these files to their intended pools or correct the share configurations in Shares > Your Share > Pool Settings.
 
Monitor Docker and Networking
Docker containers were still operational despite parity issues, but the logs show frequent reinitialization of virtual Ethernet interfaces (vethXXXX), which could indicate network instability.
Action:If you’re using ipvlan:
Ensure no IP conflicts exist between the host and Docker containers.
Consider testing with Docker disabled temporarily
 
Monitor Parity Check Progress
Parity speeds of ~200MB/s are typical for modern systems. Let the parity check complete.
Action if the speed drops again:
Check Main > Array Operation for which disk is being read.
Investigate that disk for potential I/O issues.
 
Protect Against Future Power Outages
Use a UPS (Uninterruptible Power Supply) to prevent hard shutdowns during power outages.
Configure Unraid to shut down gracefully when the UPS battery is low:
Go to Settings > UPS Settings and enable UPS monitoring.
 
 

Thank you. reveiwing diag now:

Yes this is the amd reset bug. you may alos need to fix/set time in bios.

Nov 14 15:00:35 Zoidberg ntpd[1594]: ntp-4 is maintained by Network Time Foundation,
Nov 14 15:00:35 Zoidberg ntpd[1594]: Inc. (NTF), a non-profit 501(c)(3) public-benefit
Nov 14 15:00:35 Zoidberg ntpd[1594]: corporation.  Support and training for ntp-4 are
Nov 14 15:00:35 Zoidberg ntpd[1594]: available at https://www.nwtime.org/support
Nov 14 15:00:35 Zoidberg ntpd[1594]: ----------------------------------------------------
Nov 14 15:00:35 Zoidberg ntpd[1594]: DEBUG behavior is enabled - a violation of any
Nov 14 15:00:35 Zoidberg ntpd[1594]: diagnostic assertion will cause ntpd to abort
Nov 14 15:00:35 Zoidberg ntpd[1596]: proto: precision = 0.040 usec (-24)
Nov 14 15:00:35 Zoidberg ntpd[1596]: basedate set to 2023-05-25
Nov 14 15:00:35 Zoidberg ntpd[1596]: gps base set to 2023-05-28 (week 2264)
Nov 14 15:00:35 Zoidberg ntpd[1596]: initial drift restored to 14.882000
Nov 14 15:00:35 Zoidberg ntpd[1596]: Listen normally on 0 lo 127.0.0.1:123
Nov 14 15:00:35 Zoidberg ntpd[1596]: Listening on routing socket on fd #17 for interface updates
Nov 14 15:00:35 Zoidberg ntpd[1596]: kernel reports TIME_ERROR: 0x41: Clock Unsynchroniz

from previous syslog in diag:

Full trace to see what happened where.
 
 
Given where it is at in the boot process when this happens, yes this is the amd reset bug a known issues casued by amd.... Installing the plugin should fix this issues which essential modprobe calls amdgpu.

You can learn more on that here:
 
amd reset bug
The AMD reset bug is an issue in qemu with many AMD cards. Apparently qemu fails to correctly reset the card on guest shutdown/reboot which causes the card to not be usable anymore until host reboot.
https://vfio.blogspot.com/2015/04/progress-on-amd-front.html
https://www.reddit.com/r/VFIO/comments/5tf62v/who_still_experiences_the_amd_reset_bug/
https://www.reddit.com/r/VFIO/comments/52ij8j/the_amdresetbug_will_it_ever_be_fixedwhere_to/
https://www.reddit.com/r/VFIO/comments/angluw/restart_vs_shutdown_of_vm/
Possible solution:
https://forum.level1techs.com/t/linux-host-windows-guest-gpu-passthrough-reinitialization-fix/121097
https://forums.unraid.net/topic/69373-graphics-card-reset-issue-amd/?tab=comments#comment-635252
https://github.com/inga-lovinde/RadeonResetBugFix

 

Cool, glad that it is working in another port. Yes 1-3 month is a general rule of thum. I woul recomend getting a backup sonner then latter given some earlier errors.

the forum has seen strange ness with usb3.0 ports its best to run unraid usb on usb2.0 ports. I sometimes get a dongle and throw it in the case to the motherbaords usb2.0 headers. https://a.co/d/8YHO8TB

My bet atm is a lose cable of some kind.

Check SATA Controller or BIOS
Some SATA controllers can cause compatibility issues with specific drives or Unraid settings.
Steps:
If using a third-party controller (e.g., PCIe SATA expansion card), try another controller or port.
Ensure the BIOS/UEFI settings are optimized:
Set the SATA mode to AHCI (not IDE or RAID).
Disable features like NCQ if supported by your BIOS.

 
Unraid-Specific Troubleshooting:
Rebuild Disk: If the disk is part of the Unraid array and suspect, consider rebuilding it:
Stop the array.
Remove the drive from the configuration.
Reassign and rebuild the disk.
Disable Turbo Write (Reconstruct Write):
The logs indicate changes in write methods (md_write_method).
Use the Read/Modify/Write mode and observe if errors persist.

This issue occurs because the folder name contains invalid or non-UTF-8 characters, which the Linux terminal cannot interpret correctly. Here's how you can safely delete the folder and its contents:
 
Steps to Delete the Folder
1. Use the ls Command with Escape Characters
Run the ls -b command to display non-printable characters in the folder name:
 
ls -b /mnt/user/Movies/  
This will reveal the exact folder name, replacing invalid characters with escape sequences (e.g., \275).
 
2. Use the Inode Number
Every file and folder has a unique inode number. You can delete the folder by referencing its inode.
Find the inode number:
ls -li /mnt/user/Movies/  
This will display a list with inode numbers. Look for the inode of the problematic folder.
Delete the folder using the inode:
find /mnt/user/Movies/ -inum <inode_number> -exec rm -rf {} + Replace <inode_number> with the actual inode number of the folder.
 
3. Use Wildcards Carefully
If the folder name starts with "8" or another unique prefix, you can try using a wildcard:
rm -rf /mnt/user/Movies/8* *However, this method should be used with caution to avoid accidentally deleting other folders.
 
4. Use rmdir with Tab Completion
Sometimes, the rmdir command works better for problematic folders:
Type rmdir /mnt/user/Movies/8 and press Tab to let the shell auto-complete the name.
If the folder is empty, it will be deleted. If it has contents, you'll need to use rm -rf as described above.

5.My Recomendation...use mc
IF mc/rm didn't work stop the array:
 
6. Verify Filesystem Integrity
If none of the above works, there could be a corruption issue. Run a filesystem check on the disk containing the folder:
Stop the array in Unraid.
Go to Main > Devices and select the disk containing the folder.
Run a filesystem check/repair (e.g., XFS repair).

...

Re. Q1: Does High-Water Allocation Consider the Included Disks?
Yes, the High-Water Allocation method will only consider the disks specified in the "Included Disks" setting of the share. If disks 3 and 4 are the only included disks for that share, the High-Water logic will only apply to those two disks. It will:

1Start by filling the disk with the most free space (among the included disks) until it reaches half of its capacity.

2Then, switch to the next disk with the most free space and fill it up to the same threshold.

3This process repeats for progressively smaller thresholds until all included disks are full.
Key Point: The Excluded Disks setting will also restrict the disks used for the share, ensuring that High-Water ignores those disks entirely.

 
Re. Q2: Manually Managing Files with Disk Shares vs. User Shares
Disk Shares vs. User Shares
Disk Shares: These provide direct access to individual disks (disk1, disk2, etc.). When you manually move or copy files to a specific disk share, you have full control over which disk the data is stored on.

Pros:
Absolute control over file placement.
Avoids any ambiguity about which disk a file resides on.
No need to worry about split levels, allocation methods, or included/excluded disks for that share.
Cons:
If you inadvertently place related files across disks (e.g., parts of a movie folder), this can cause potential issues with file access if you later switch to User Shares.
Disk shares bypass the User Share allocation logic, which could lead to uneven disk usage if not managed carefully.
Harder to manage at scale for large shares with frequent changes.
 
 
User Shares: These are logical shares that span multiple disks based on allocation methods, split levels, and include/exclude settings.
Pros:
Simplifies file management by abstracting physical disk locations.
Dynamically distributes files across disks according to the configured rules.
Works well for large shares with automated or network-based data transfers.
Cons:
Less control over which disk the data is stored on unless you manually configure split levels and allocation.
Requires proper configuration to prevent unintended data distribution.
 
When to Use Disk SharesL
 
Use Disk Shares if you want total control over file placement, for example:
Archival data where you want specific folders/files on specific disks.
Scenarios where the data structure needs to align perfectly with your backup strategy.
 
When to Use User Shares
Use User Shares when:
You don't need granular control over file placement.
You want Unraid to handle file distribution automatically, especially for media libraries like Plex or file servers.
You plan to expand your array or frequently add/modify data.
 
Drawbacks of Disk Shares
Potential for Split-Level Confusion: If you manually place files in a disk share and then try to access them via a user share, you might encounter issues if split levels aren’t configured correctly. For example, files spread across disks may result in incomplete directories when accessed via a user share.
Less Flexibility: As your storage needs grow, manually managing file placement on specific disks can become tedious.
User Share Conflicts: If you're using both disk and user shares for the same data, it can cause problems due to Unraid's "User Share Copy Bug." This happens when you copy/move files between a disk share and its corresponding user share, leading to potential data corruption or duplication.

Best Practice
If you're committed to manually managing file placement and don't need the flexibility of User Shares, Disk Shares can work well.
However, a safer and more efficient approach might be to continue using User Shares with:
Split Level set to control folder hierarchy.
High-Water Allocation to balance disk usage.
Manual file movement only when necessary (e.g., via Midnight Commander or rsync).

When make a backup over a network, you have points of failure. Example when something goes down or unreachable, the backup fails to write and now you have a dead files. So I would have a dedicated folder for app data plugin to backup on unraid itself.

Then,
I would setup a user scirpt plugin to mount the external voumen and copy/rsync the backup.

This way I can inspect and guarantee a good mount, and copy before and after. As the appdata plugin has a rotation, you can also set that to keep 3 backups max so unraid will have a backup on its and a script to copy it off unraid for recovery...

You can even have the script run after appdata is done...

check unraid dns. use 8.8.8.8 or 1.1.1.1 for a test 

go to plugin manul install and copy the link from here:
unriad pulls form github  90% when this happens its a dns issue.

Review post:

To improve your UnRaid server’s performance, especially for Plex, VM operations, and general usage, we can optimize your current configuration based on your hardware setup and some best practices. Here’s a tailored approach for prioritizing Plex, then your desktop VM, and finally Docker/file shares.
Step 1: Optimize Plex Performance
Since Plex is experiencing occasional glitches during transcoding, it could benefit from some tweaks to its transcode directory and CPU allocation:
Transcoding Directory:
Setting the Plex transcode directory to your faster cache drive could significantly reduce latency during transcoding. This helps because your PCIe NVMe cache pool will handle Plex’s temporary transcode files faster than your array or ZFS pool.

/mnt/cache/appdata/Plex-Media-Server/Transcode
 
CPU Allocation:
While pinning 4 physical and 4 hyperthreaded cores to Plex can help, make sure the pinned cores are not overlapping with those assigned to your VM. Also, ensure that the chosen cores aren’t overloaded by other Docker containers.
To help prioritize Plex, you might also try enabling CPU isolation for these cores (in Settings > CPU Pinning) so that only Plex can use them without interference from other tasks.
 
Check Plex Settings:
In Plex settings, ensure you have "Use hardware acceleration when available" enabled (if you have an integrated GPU or a compatible graphics card).
If you’re using ZFS for the Plex media pool, consider its I/O implications. ZFS can be resource-intensive, so ensure that your ZFS pool settings and cache usage are optimized for fast reads.
 
Step 2: Improve Desktop VM Responsiveness
Given that your VM is sometimes sluggish, adjustments to CPU pinning, memory allocation, and disk configuration could help:
Optimize CPU Pinning and Isolation:
Assign 6 physical cores and their hyperthreaded pairs specifically to your VM, ensuring these do not overlap with Plex’s pinned cores.
Try isolating these cores (also in Settings > CPU Pinning) so they’re dedicated to the VM, which can improve performance consistency.
 
Optimize Disk Usage for VM:
Since your VM is on a dedicated 2x256GB SSD ZFS pool, verify that ZFS settings (like compression or deduplication) are configured for best performance rather than data redundancy or compression. Excessive ZFS processing for a VM disk could affect latency and throughput.
If ZFS performance is still an issue, consider moving the VM disk image to your faster NVMe cache pool and see if it improves responsiveness.
 
RAM Allocation:
With 64GB of RAM, 16GB should be ample, but check that the VM isn’t using swap or hitting memory limits. Adjust the VM's RAM allocation slightly upward (e.g., 20GB) if you notice memory-related bottlenecks in the UnRaid logs.
 
Step 3: Docker and File Share Optimizations
With Plex and the VM prioritized, we can optimize Docker and file shares for overall performance:
Docker Containers on Cache:
Having Docker containers (especially Plex) on your NVMe cache will improve their response times. Ensure appdata and Docker system share settings are set to “Prefer: Cache” to keep these files on the cache pool for faster access.
Tuning ZFS for Data Pool:
ZFS can be memory-intensive, so adjust arc_max to limit the ARC (adaptive replacement cache) size and avoid high memory usage. Limiting ZFS cache to around 8-10GB should leave ample memory for other services.
File Shares:
Since your server is equipped with 10GbE, ensure you’re using SMB tuning settings that optimize throughput. In the Settings > SMB section, set:
 
smb edits: min protocol = SMB2 aio read size = 4096 aio write size = 4096  
Step 4: Network Check
Given you’re on a 1Gbps LAN but the server is using 10GbE, check that the network path isn’t introducing latency:
Check MTU Settings:
Ensure both your 10GbE NIC and your switch are set to the same MTU size, ideally 1500 (or up to 9000 if your network supports jumbo frames). Mismatched MTUs could cause packet loss or latency, affecting streaming and general access.
Step 5: Monitor Performance
After applying these optimizations:
Use UnRaid’s Dashboard:
Check CPU and memory usage on the dashboard while streaming or running the VM to ensure resource allocation is balanced.
Review Logs:
Periodically review UnRaid and Docker logs for error messages or throttling notices. This can provide insights if further adjustments are needed.

in truth, I'm not sure how to shrink the array... I have done so in the past on older unraid 5... mby boot to a live ubuntu os and use disk to shrink a partition... other data on forum
https://docs.unraid.net/legacy/FAQ/shrink-array/
 
 

Your plan is well thought out and covers the essential steps for both shrinking the array and expanding the cache pool. I’ll walk through your questions and provide a few tips to help streamline the process and ensure a safe transition.
 
Part 1: Shrink Array
Choosing the Shrink Method
Both methods you listed are valid, but there are pros and cons to each:
 
Method 1 (Remove Drives Then Rebuild Parity):
This is simpler in terms of steps and will likely be faster because it avoids the need to zero out the drive.
However, since it requires a complete parity rebuild, there is a brief period where parity protection is lost, leaving your array vulnerable until the rebuild completes.
 
Method 2 (Clear Drive Then Remove Drive):
This method maintains parity throughout the process by zeroing out the drive, allowing you to safely remove it without a parity rebuild.
Although it has more steps and may take a bit longer, it offers more data protection since parity is preserved throughout the process.
 
Recommendation: Method 2 is generally safer, especially if you’re concerned about data integrity and have the patience to go through the extra steps. However, if you’re comfortable with a temporary parity loss and want a simpler process, Method 1 is a viable choice.
 
Steps for Shrinking the Array
Here’s a refined approach based on your steps:
Use unBalance to migrate data from the drive you’re planning to remove. Verify the data has been fully transferred by spot-checking a few folders.
Run Method 2 if you want to maintain parity. Otherwise, go with Method 1 for a quicker process.
Final Check: After shrinking, verify the array is operational with the remaining drives.
 
Part 2: Expanding the Cache Pool
Your expansion plan looks mostly accurate, but let’s address some specifics to ensure it goes smoothly.
 
Steps to Expand the Cache Pool
Add the First 500GB SSD:
Shut down the server, insert the first 500GB SSD, and then boot up.
In UnRaid, add the new 500GB SSD to the cache pool. Since this is a Btrfs pool, it should automatically balance across both drives in a RAID1 configuration, providing redundancy.
Start the array and let the pool balance. This might take some time depending on the amount of data in the cache.
 
Replace the 250GB SSD with the Second 500GB SSD:
Shut down the server again, swap the 250GB SSD for the second 500GB SSD, and boot up.
In UnRaid, assign the new 500GB SSD to replace the missing slot in the cache pool.
Start the array and allow the pool to balance again.
 
*Note: As you pointed out, you may need to stop and start the array for UnRaid to recognize the new SSD size properly. Keep an eye on the cache pool status during the balancing process.
 
Verifying the Cache Pool
After both SSDs are in place and the balancing is complete, double-check that the cache pool is now showing the correct RAID1 configuration and 500GB capacity. This can be done in Main > Cache Pool or by looking at the btrfs stats to confirm redundancy.
 
#########
 
Final Checks and Considerations
You’ve done an excellent job preparing, with comprehensive backups, pre-cleared SSDs, and data redundancy. Just a few final points:
Verify Backups: Ensure the AppData backup and the flash drive backup are recent and verified, as these will be essential in case of any issues during the migration.
Check Docker and VM Configurations: After completing the process, double-check Docker and VM configurations to ensure they’re utilizing the expanded cache pool correctly.
Monitor System Stability: Keep an eye on the system logs and overall server performance for a few days after the transition to catch any potential issues early.
These steps should ensure a smooth transition and improved redundancy in your UnRaid setup

pm is secure on the forum looks like you found your solution. yes if unraid under main says it needs to format them please format them inthe web UI

Thank you for posting the diag will take a lok soon to see other disk log error...
Quick glance at post ... you may need to wipe the disk in another os or in unraid and let the unraid web ui format the disk.

stop the array and go into maintenance mode. Unriad docs:
https://docs.unraid.net/legacy/FAQ/check-disk-filesystems/#:~:text=run xfs_repair-,Start the array in Maintenance mode%2C by clicking the Maintenance,mount any of the drives.
 

https://docs.unraid.net/unraid-os/manual/storage-management/

as it looks like your preformatted the disk else where.

 
This issue can arise in Unraid when adding a new disk, especially if the disk isn’t pre-cleared, formatted correctly, or if there's a mismatch in expected filesystem types. Here’s a troubleshooting checklist:
1. Verify Disk Format and Status in Unraid:
Go to Main -> Array Devices and check the status of the added disk.
If the disk status shows “Unmountable: Unsupported or no file system,” it might need to be formatted or partitioned correctly.
2. Formatting the Disk:
If the disk has not been formatted, Unraid should offer an option to format it under Array Operation. Select the disk and format it as XFS or Btrfs based on your requirements.
Warning: Formatting the disk will erase any data on it.
3. Reboot Unraid Server (if needed):
Sometimes, a reboot can help Unraid recognize the filesystem correctly. After the reboot, check if the disk mounts properly.
4. Check for Disk Errors:
Go to Tools -> Diagnostics and generate a report to check if there are any issues with the disk hardware or connection.
5. If You Intend to Use Btrfs, Ensure Compatibility:
If you specifically need Btrfs, ensure the disk has been formatted using the Btrfs filesystem.
Tools -> File System Check: Run a Btrfs filesystem check to identify and correct any minor filesystem issues.
6. Clear and Re-Add Disk if Needed:
If the issue persists, try removing the disk from the array, pre-clearing it, and re-adding it. Sometimes starting with a blank disk can help with compatibility issues.
If all else fails, posting diagnostics on the Unraid forums can provide more insight into the error message specifics and help from other users.

Ok i wil try:

 
Summary
Check file system encoding: Ensure UTF-8 is used.
Database: Ensure utf8mb4 encoding is properly set.
PHP Settings: Ensure PHP uses UTF-8 by default.
Nextcloud config: Enable 'filesystem_check_changes' => 1.
System Locale: Set server locale to es_ES.UTF-8.
Docker Locale: If using Docker, set locale environment variables.


As It looks like the issue with Nextcloud's files:scan --all command picking up files with Spanish characters (like ñ, í, ó) relates to incompatible encoding. Here are some steps you can take to resolve this:

You ned to use UTF-8...
1. Check File System Encoding
Make sure the file system where Nextcloud is running supports UTF-8. Encoding issues often arise when the file system uses a different character encoding.

 
2. Database Encoding
Ensure that your database is set to support utf8mb4 character encoding. You have 'mysql.utf8mb4' => true in your config, which is good, but you should also verify that all the tables in your database are using the utf8mb4 charset.

login to your mysql with your 
'dbuser' => 'xxxxxx', 'dbpassword' => 'xxxxxxx', 
*as your database tables may not have been created with the utf8mb4...

You can run the following SQL command on your database to verify the character set:
SHOW TABLE STATUS WHERE `Collation` NOT LIKE 'utf8mb4_%';

If any table uses a different collation, consider converting it using:
 
ALTER TABLE table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
 
3. PHP Configuration
Ensure that your PHP environment is configured to handle UTF-8 characters. You can adjust your php.ini to make sure:
default_charset = "UTF-8" Restart the PHP and web server services after making changes.
 
4. File Scanning Configuration
Consider trying to adjust the encoding in your Nextcloud instance. You might want to add the following line to your config.php:
'filesystem_check_changes' => 1, This will force Nextcloud to recheck the files regularly, potentially addressing encoding issues for existing files.

####################################

5. Locale Settings
since you have:

'default_language' => 'es',
'default_locale' => 'es_ES',
'force_language' => 'es',

Make sure the system locale of your server is also set to es_ES.UTF-8. You can configure it by running:
locale-gen es_ES.UTF-8 update-locale LANG=es_ES.UTF-8 ^- Unraid settings as well...
Go to Settings > Display Settings....
Restart your server after applying these settings.

since using docker set exra varabiles...

in docker compose you would add:
 
environment: - LANG=es_ES.UTF-8 - LANGUAGE=es_ES.UTF-8 - LC_ALL=es_ES.UTF-8
In unraid edit docker add varable and ill it in then apply...

if above failes then....

7. File Renaming
If the above methods do not solve the issue, it might be helpful to rename problematic files manually and remove any special characters, as a temporary workaround.

Meaning don't use files with thoese characters...

As explined in my first reply... you don't... 
that to use Duplicati as it doesn’t support SMB directly as a destination, Thats a workaround...

 
here you go:
 
Here's a simple script you can use in the User Scripts plugin to check if the remote share is already mounted, and if not, mount it. This script will check if the mount point exists and, if it’s not already mounted, will execute the mount command.
Script to Check and Mount SMB Share

 
#!/bin/bash # Define variables REMOTE_IP="your_remote_IP" REMOTE_SHARE="your_remote_share" MOUNT_POINT="/mnt/remote_backup_folder" USERNAME="your_username" PASSWORD="your_password" # Check if the share is already mounted if mountpoint -q "$MOUNT_POINT"; then echo "Share is already mounted at $MOUNT_POINT." else echo "Share is not mounted. Attempting to mount..." mount -t cifs -o username="$USERNAME",password="$PASSWORD" //$REMOTE_IP/$REMOTE_SHARE $MOUNT_POINT # Check if the mount was successful if mountpoint -q "$MOUNT_POINT"; then echo "Share successfully mounted at $MOUNT_POINT." else echo "Failed to mount share at $MOUNT_POINT." fi fi
 
Explanation of the Script
Variables: The script defines variables for the remote IP, share name, mount point, username, and password.
Check if Mounted: It uses mountpoint -q to check if the specified mount point is already mounted.
Mount Command: If the share isn’t mounted, it attempts to mount it using the mount -t cifs command with the specified credentials.
Verification: After attempting to mount, it checks again if the mount was successful and outputs an appropriate message.
Adding to User Scripts
Open the User Scripts plugin in Unraid.
Create a new script and paste the above code.
Set the script to run on a schedule that suits your backup needs or run it manually as needed.
This script should help keep the mount active and automate the mounting process whenever it's needed.

this is a known issue... since your runnign beta 2 the mover instance is borken ...

 
Thanks to the people in this thread: https://forums.unraid.net/topic/70783-plugin-mover-tuning/page/59/
Edit your go file at: /boot/config/go and add:
rm /usr/local/sbin/move
ln -s /usr/libexec/unraid/move /usr/local/sbin/move

1. remove of the docker image.
This will remove all the dockers in the docker gui on the web page (DON'T WORRY!) they are still there and the data volumes are still there. As long as your volumes are still set to your disks. Some containers or templates require another path for their settings... if it isn't mapped to a volume/disk, it's in the docker image. (* Looking for squids documentation on this on the forum, he outlines very well )

Ideally. Go to setting > stop docker set to no...

Then delete "docker.img" file. 
Then recreate docker.img I'd recommend using a xfs image version with at least 50 GB or more.
Then start docker.
Next restore previous dockers.
Unraid Web UI > docker tab > bottom left add container. Select a docker you had in the list and click apply, no data should be lost...

Review:

2. auto start with delay
Docker web ui toggle at top right advance view:



As you can see I'm running a 2 docker system for photoprism mysql and the docker photoprism with autostart there is a wait option. I have set my photo prism to wait 10 sec so mysql is up before photo prism to start.

You can setup your dockers with similar autostart to help initial resource load or fix some start issues.

this sounds like a mover issues.

under share settings what is the mover options for the disk that is getting full?

per diagnostics. you using unraid beta 3

per redit for a fix:

 
Edit your go file at: /boot/config/go and add: rm /usr/local/sbin/move ln -s /usr/libexec/unraid/move /usr/local/sbin/move
and run mover after a reboot

 

Your on Unriad 6.12.6 why not update to latest 6 stable 6.12.13

Your Diag is showing a dhcp IP. You should realy set that static.

looks like your using bond and bridgin.
lo               UNKNOWN        127.0.0.1/8 ::1/128 
tunl0@NONE       DOWN           
eth0             UP             
bond0            UP             
br0              UP             169.XXX.XXX.80/16 
virbr0           DOWN           192.168.122.1/24 

I only see 1 interfce, is ther a reson for bond0 on?

testparm samba config:

    bind interfaces only = Yes
    disable netbios = Yes
    disable spoolss = Yes
    host msdfs = No
    interfaces = 169.XXX.XXX.80/16 127.0.0.1

?can you ping your unraid ip 169....

at 1801 it looks like things were up...

then something or you ran a smb restart and it went down...

ct 28 18:07:48 Tower emhttpd: shcmd (2101): /etc/rc.d/rc.samba restart
Oct 28 18:07:48 Tower wsdd2[12010]: 'Terminated' signal received.
Oct 28 18:07:48 Tower winbindd[12031]: [2024/10/28 18:07:48.627647,  0] ../../source3/winbindd/winbindd_dual.c:1950(winbindd_sig_term_handler)
Oct 28 18:07:48 Tower winbindd[12036]: [2024/10/28 18:07:48.627641,  0] ../../source3/winbindd/winbindd_dual.c:1950(winbindd_sig_term_handler)
Oct 28 18:07:48 Tower winbindd[12031]:   Got sig[15] terminate (is_parent=1)
Oct 28 18:07:48 Tower wsdd2[12010]: terminating.
Oct 28 18:07:48 Tower winbindd[12036]:   Got sig[15] terminate (is_parent=0)
Oct 28 18:07:48 Tower winbindd[16559]: [2024/10/28 18:07:48.627765,  0] ../../source3/winbindd/winbindd_dual.c:1950(winbindd_sig_term_handler)
Oct 28 18:07:48 Tower winbindd[16559]:   Got sig[15] terminate (is_parent=0)
Oct 28 18:07:50 Tower root: Starting Samba:  /usr/sbin/smbd -D
Oct 28 18:07:50 Tower smbd[23033]: [2024/10/28 18:07:50.802719,  0] ../../source3/smbd/server.c:1741(main)
Oct 28 18:07:50 Tower smbd[23033]:   smbd version 4.17.12 started.
Oct 28 18:07:50 Tower smbd[23033]:   Copyright Andrew Tridgell and the Samba Team 1992-2022
Oct 28 18:07:50 Tower root:                  /usr/sbin/wsdd2 -d -4
Oct 28 18:07:50 Tower root:                  /usr/sbin/winbindd -D
Oct 28 18:07:50 Tower wsdd2[23047]: starting.

Using a use script or edited smb?

if so i would have you review:

i ususaly use a windwos registry edit to renable guest no passowrod logins..
 
Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters] "EnablePlainTextPassword"=dword:00000000 "EnableSecuritySignature"=dword:00000001 "ServiceDllUnloadOnStop"=dword:00000001 "AllowInsecureGuestAuth"=dword:00000001 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa] "LimitBlankPasswordUse"=dword:00000001 "NoLmHash"=dword:00000001 "everyoneincludesanonymous"=dword:00000001 "restrictanonymous"=dword:00000000 "restrictanonymoussam"=dword:00000001  

You may need to install driver plugin:
 

 
per diag:
your using a realtek nic. and there have been some known issues with that lately with the new kerneal.
driver: r8169
version: 6.1.106-Unraid
firmware-version: rtl8168g-2_0.0.1 02/06/13
expansion-rom-version: 
bus-info: 0000:03:00.0
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: yes
supports-priv-flags: no

why eth0 is down idk, but arcodign to your diag it is off
lo               UNKNOWN        127.0.0.1/8 ::1/128 
tunl0@NONE       DOWN           
eth0             DOWN           
bond0            DOWN           
br0              DOWN           192.168.1.4/24 metric 1 

run:
 
ifconfig eth0 up
you may need to make a user script to auto do this if this is happening at boot. otherwsie somtheing ran or erroer and teh deivce is now down.
Also double check ethernet cord is securly pluged in. that you see link lights on the port / switch-router...

per syslog:
Oct 28 21:10:38 BigNASty kernel: r8169 0000:03:00.0 eth0: RTL8168g/8111g, 40:8d:5c:75:6b:7c, XID 4c0, IRQ 27
Oct 28 21:10:38 BigNASty kernel: r8169 0000:03:00.0 eth0: jumbo features [frames: 9194 bytes, tx checksumming: ko]

the driver is loading... jumbo frames is 10 GB netowrks please check unraid network settings and mtu are st to 1 gb settins so mtu 1500 no jumbo frames

rsync with unraid user plug scripting may be your best bet. you may also want to look into tailscale / twingate as a vpn provider so they can all securly talk to each other as long as there is a data connection.

so if I understand you:
Unraid and desktop(ubuntu) have a sync and share where data is synced between them...

you want a similar sync and access or backup copy on the Laptop.

?Laptop running ubuntu as well?

in terms of guides or other sorry i'm not aware of any. but will gladly help where i'm able.
ATM Unraid has partnered with Tailscale and it is failry easy to setup as a vpn wihtout any portforwaind mess as tailscale is the brokerage server.

ATM I'm using twingate. (My setup has 2 client devices backing up photo medai data) via photsynce over the twingate VPN (simlar to tailscale, as tailscale did work but twingate was easeier and a bit more friendly...)

I can help you come up with secure share, rsynce, copy scripts but would need pathing...

example unrad nfs share is /mnt/user/???what share name???
desktop has what path you want to sync... etc...
 

Well, thats all I have. thanks for trying...

coming back from ubuntu 7 days when one could easily pass a disk drive as a network share...

That tells me that unraid sees the disk drive in its current state, but if its not in the vm at that point the mount failed. I don't know why linux made a mess of temp storage disk drives with dvd writer/blueray writer adaptions... /dev/sg vs /dev/sr and others... linux clearly want something more to do a passthrough. Not sure if this is a unraid thing or issue. 

This is why as mentioned earlier I recommend using the usb atapi device...
go old usb passthrough.

I wish you luck.