Majyk Oyster

You found the issue, even though I already checked and missed it. I have around 12 TB of free space available to this share, and didn't check any further, but for some reason one of the disks had just under 500 GB of available space, which is the minimum free space I set. It was enough for unraid to trigger the limit. Everything is back to normal, thanks a lot !

Thanks for looking into this ! Yes, I get this message : The Downloads field specifies a directory '/downloaded' that exists, but is not writeable. Here's the configuration of "/downloaded" and PUID/GUILD in docker : PUID 1000 refers to my main user, GUID 100 to group "users".. I've tried "chmod -R username:users /mnt/user/Downloads/slsk" and "chmod -R nobody:users /mnt/user/Downloads/slsk". Permissions are set to 777 by default, I didn't touch this. Deleting the "/downloaded" path brings this error : The Downloads field specifies a non-existent directory '/downloaded'. Adding an "/incomplete" path pointing to a folder with the same permissions as "/downloaded" doesn't do anything, no extra error in the log and slskd still fails to start. The command execution : docker run -d --name='slskd' --net='bridge' --pids-limit 2048 -e TZ="Europe/Paris" -e HOST_OS="Unraid" -e HOST_HOSTNAME="hostname" -e HOST_CONTAINERNAME="slskd" -e 'SLSKD_REMOTE_CONFIGURATION'='false' -e 'PORT'='5030' -e 'SLSKD_UPLOAD_SLOTS'='10' -e 'SLSKD_UPLOAD_SPEED_LIMIT'='1000' -e 'SLSKD_SLSK_USERNAME'='username' -e 'SLSKD_SLSK_PASSWORD'='maybeAnActualPassword' -e 'SLSKD_SLSK_DESCRIPTION'='Boredom won'\''t get me tonight' -e 'SLSKD_SLSK_DIAG_LEVEL'='None' -e 'SLSKD_USERNAME'='username' -e 'SLSKD_PASSWORD'='maybeAnActualPassword' -e 'PUID'='1000' -e 'PGID'='100' -l net.unraid.docker.managed=dockerman -l net.unraid.docker.webui='http://[IP]:[PORT:5030]/' -l net.unraid.docker.icon='' -p '5030:5030/tcp' -p '5031:5031/tcp' -p '50300:50300/tcp' -v '/mnt/user/appdata/slskd/':'/app':'rw' -v '/mnt/user/Music':'/shared':'ro' -v '/mnt/user/Downloads/incomplete':'/incomplete':'rw' -v '/mnt/user/Downloads/slsk':'/downloaded':'rw' 'slskd/slskd:latest' edfc4f529fc65aecd5dcd1cacf06eefd4dcafa163b4ccef2648eac0be3ff6a8c The command finished successfully! The log just after the execution : The Downloads field specifies a directory '/downloaded' that exists, but is not writeable. /incomplete path generates no error, while having the exact same permission : drwxrwxrwx 1 nobody users 10 Sep 26 17:47 incomplete/ drwxrwxrwx 1 nobody users 4.0K Sep 28 01:37 slsk/ No idea where to look next.

I have the same issue. slskd was working fine for months, and it stopped working today. I haven't changed a thing. No idea what's the issue.

Despite reading the previous posts on the issue, then reading https://hub.docker.com/r/realies/soulseek/, my downloaded files are still owned by root:root. What I am doing wrong ? My user ID is 1000, its group is 100, which points to the group "users". I set both PUID and PGID as variables to the container. I don't understand this comment. Everywhere I look the PUID and PGID are indeed in capital letters. Switching to lowercase didn't change anything. I'm pretty sure this is trivial, but I can't put my finger on it. Any inputs appreciated !

Thanks for the replies ! 🍻 Here's what the history looks like : I'm running another parity check right now, we'll see. I have no idea why the elapsed time differ, looks like they run at the same time or something. Can't tell which would be right. I only have backups of a small portion off the array, the critical stuff. I'm going to check this, and hope for the best for the media library. I'm indeed using XFS, I'm looking into the File Integrity plugin right now.

Hi folks, Yesterday my beloved dog stepped on the switch of the power strip of my server. After scratching his ears and giving him a treat to show him who's boss, I restarted the server, and launched a parity check. I was relived when I got this message : Event: Unraid Parity-Check Subject: Notice [SAUCISSE] - Parity-Check finished (0 errors) Description: Duration: 1 day, 6 hours, 46 minutes, 53 seconds. Average speed: 144.4 MB/s Importance: warning To my surprise I got this other message 5 minutes latter : Event: Parity Check Tuning Subject: [SAUCISSE] Automatic Correcting Parity-Check finished (2414 errors) Description: Elapsed Time 2 day, 3 hr, 56 min, 1 sec, Runtime 2 day, 3 hr, 56 min, 1 sec, Increments 1, Average Speed 85.6 MB/s Importance: alert I fail to understand the difference in error number. Could you help me with that ? Bonus question : how can I know where/in which files are these 2414 errors ? saucisse-diagnostics-20240503-2010.zip

Hi folks I noticed an error in my unraid logs, appearing every few minutes : May 3 20:03:04 Saucisse kernel: r8169 0000:03:00.0 eth0: Rx ERROR. status = 352cc31c May 3 20:09:00 Saucisse kernel: r8169 0000:03:00.0 eth0: Rx ERROR. status = 352cc37b May 3 20:14:56 Saucisse kernel: r8169 0000:03:00.0 eth0: Rx ERROR. status = 352cc1aa May 3 20:19:44 Saucisse kernel: r8169 0000:03:00.0 eth0: Rx ERROR. status = 352cc07d I tried searching for the few keywords in the messages, all I can tell is it's about the NIC of my server (Realtek r8169). I have no idea what to do next, any idea ? 🥲 saucisse-diagnostics-20240503-2010.zip

I just noticed the exact same message popping in my logs. Allow me to take a seat. saucisse-diagnostics-20240503-2010.zip

Thanks for your inputs. Seems like I had a brain fart. I guess I debugged it when clearing the last disk of my array. I'm updating my previous post.

I did that and more changes a few does ago, you can see it on the previous page. There's so many links pointing at RobJ's initial post, that would be nice if there was a way to mention updates.

Do you need the certificate updated for the Unraid server or for a hosted VM/container ?

When I started replacing my old 3-6TB regular disks with 8 TB NAS ones, shucking was way cheaper. I paid 160€ for my first My Book in early 2020 on westerndigital.com. They're 50% more expensive today. In the meantime it seams like the price difference between a WD My Book and a WD Red decreased a lot, not it's around 10%. I bought my last 3 or 4 8TB drives used, for around 100€. Good thing is all of them except one were very lightly used (less then 100 hours). I'm pretty sure it's almost impossible to find used Reds that fresh. Not sure about the future of shucking, we'll see in a couple years when I need to hoard more data.

I actually have access to an actual certified disk shredder. I work for a managed security services provider, specialized in hosting critical data (for hospitals, health insurances, ministry of defense...). I haven't worked as a sys admin for a while, but my colleagues in the datacenters can turn my drives into coarse powder if need be.

I just watched Spaceinvader One video about the plugin, and I indeed saw that there was an option for multiple cycles (couldn't find it mentioned in the plugin thread). I don't want to sound like I'm arguing for the sake of it, but I just noticed Squid mentioned on the Preclear plugin thread that it was incompatible with Unraid versions 6.9.0+ and should be uninstalled. So there's that. As for the final check for the actual destruction of the data, the fact that "successful" shred commands could actually fail to destruct the data beyond recognition didn't occur to me. I'd have to look into that.

I checked the documentation on that plugin, but if it actually renders the previous data unrecoverable the info eluded me. Zeroing a device doesn't prevent a potentially malicious person from using data recovery tools to obtain potentially private data. The previous magnetic state of the device has to be randomly altered several times to obtain a satisfactory protection.