GiulioCD

Just to clarify I'm using the latest beta build v7.1.0-beta1 not v7.0.1. EDIT According to the console output after running this command I get the following repeated multiple times : SA xattrs: 80 bytes, 1 entries I believe this is proof that the dataset is in fact using xattrs=sa. This alleviates my concern, thanks for the commands.

Thank you for the detailed response. A lot of the information you provided is extremely useful and I will take note of it. As for the issue, it would seem that upgrading pools to ZFS 2.3.0 will cause this behavior : I will proceed to close this issue but I want to thank you for the detailed response.

Hello I'm looking for help on this issue I've experienced on Unraid 7.1.0-beta.1 whilst using ZFS. I have a ZFS pool consisting of 8 SSDs in a RaidZ1 configuration. When I setup the pool I had set the xattr property to xattr=sa. However after updating Unraid to 7.1.0 beta 1 and updating the ZFS pool to the latest version, this property seems to always be set to xattr=on regardless of my attempts to change it. Find below the transcript of me attempting to change the property using the console. root@Servername:~# zfs get -r xattr poolname NAME PROPERTY VALUE SOURCE poolname xattr on local poolname/dataset xattr on local root@Servername:~# zfs set xattr=sa poolname root@Servername:~# zfs get -r xattr poolname NAME PROPERTY VALUE SOURCE poolname xattr on local poolname/dataset xattr on local root@Servername:~# As you can see, even though the command appears to work no change is made to the pool or dataset properties. Any help would be greatly appreciated. EDIT I have created a new topic under the bug reports section for prerelease versions of Unraid. If deemed necessary I will remove this post as to not have duplicate posts.

Hi, I've experienced a problem with this deployment and was wondering if anyone has experienced anything similar. I also posted a bug report on Homebox's Github issues. https://github.com/sysadminsmedia/homebox/issues/588 The issue is as follows: Attempting to open a document from an item leads to a 404 page. After examining the DB file, the path under the document appears to be correct. However, Homebox is unable to retrieve the file. All files are still present on the disk and no modifications have been been made to the DB in the last 2 weeks. Homebox is running in a Docker container on Unraid 7.0.1. Database item Example: Item ID: d6fe9ea1-7c9c-42aa-9a01-7c940dea2a52 Attachment ID: d78b071a-752d-47e6-a1bc-fcacb3cb96f6 Group ID: 21cbe24a-beb5-4974-bb65-0f38a59df6d1 Document ID: dd3b3cc9-6ff4-40e4-8d6b-afe8f9780438 document_attachments: dd3b3cc9-6ff4-40e4-8d6b-afe8f9780438 item_attachments: d6fe9ea1-7c9c-42aa-9a01-7c940dea2a52 path: /data/21cbe24a-beb5-4974-bb65-0f38a59df6d1/documents/4615bcbc-9ece-4bd7-9841-9657104f53ba.pdf It is not clear why the issue happened therefore it is difficult to provide steps to reproduce the issue. However, all I have done is created multiple items. Categorized the items under particular locations. Created parent and children items. Attached documents like photo, manual, receipt, etc. Save the changes. Waited ~2 weeks prior to accessing a file. Received error 404 when attempting to access the file. If anyone has any experience with something similar happening or if you can recommend something I can try to fix the problem it would be greatly appreciated. Thanks EDIT When adding a new attachment to an existing item I'm still presented with a 404 when attempting to view it. However the item is successfully added to the DB and to the path for the documents. Upon deleting the attachment the file is successfully removed from the DB and from the path on the file system. EDIT 2 (SOLUTION) I was able to resolve the issue by logging out and logging back in. Perhaps the session was invalidated previously thereby denying access to the attachments. Everything is now working as it should.

UPDATE 3 For reference my UPS model is GX1500U-FC. I have installed the Network UPS Tools (NUT) for UNRAID plugin and disabled the APC UPS daemon. With this plugin installed the issue appears to be mostly resolved. The system will successfully shutdown around 95% of the time. I've been running the plugin for 1 month and have only had 1 occurrence where the system stayed on. I will leave this topic open for any additional information that I collect, I will update accordingly.

UPDATE 2 Unfortunately the issue still occurs on my system with "nowatchdog" added to my Syslinux Config. I have not been able to diagnose this issue further but like I said in my previous post I believe it is associated with the UPS. The issue still occurs on Unraid 7.0.0-beta.2. If anyone else encounters this issue I would appreciate if you guys can post what UPS you're using an how it's connected to the system since it may shed some light on why this issue occurs on certain system configurations.

UPDATE I've fixed the issue by adding "nowatchdog" to my Syslinux Config. Leaving this here for anyone else who might run into this issue.

Hey, I've been having trouble with my system shutting down properly ever since I built it, and I would appreciate some guidance on diagnosing the issue. Occasionally (~1 in 4 times), my system will remain powered on after shutdown. The operating system and network adapter are offline, but the computer fans, drives, and RGB lighting remain on. This forces me to power off the system by holding the power button for 10 seconds. From what I gather from the syslog, it appears to be an issue related to apcupsd, but I'm not certain. I've tried stopping the array before clicking the shutdown button in the UI, but that hasn't resolved the issue. I've performed a memory stability test on my RAM, and the result was a pass. Additional information: The system is connected via USB to a Cyberpower 1500VA UPS. CPU: Intel i7 8700K Motherboard: Asus ROG Crosshair Formula X RAM: (2x32GB) G.Skill 3600Mhz Unraid version 6.12.10 I'm open to any suggestions people might have for troubleshooting and hopefully solving the issue. Thanks for the help in advance. syslog failed shutdown.txt syslog-previous Successful Shutdown.txt