SkilledAlpaca

As far as I can tell, swapping UBS's has resolved the issue. I will report back if I observe the error again.

Jinxing it by posting, but I replaced the USB Flash Drive UnraidOS was on and I am holding steady at 9+ days of uptime with heavy and normal use. I was originally using a SanDisk Cruzer Fit 16GB (SDCZ33) micro USB. I swapped to a SanDisk Cruzer 128GB USB 2.0 Flash Drive (SDCZ36) I had lying around. A cloud restore to this drive failed. The cloud download was nice as I was able to perform a fresh install of the latest UnraidOS. I then manually moved over a few items for Docker and plugins and it appears to be working without issue. I will mark this thread as solved if the uptime can hold for longer than 14 days with normal use. Edit: Since replacing the USB flash drive, I have resumed all services, added additional containers and not a single crash in 23 days.

Unknown what the issue is at this point. I have rebuilt every single docker container on my Unraid server. Fresh appdata folders for each app, different container versions, and ran only three 'core' containers. This can't be an issue with Docker and something is either fundamentally wrong with my setup or I have some kind of corrupt data that is killing the shfs service. Notably the crashes happen when Plex is about to start play back on media or right as the media playback is ending, but I've used two different Plex containers and the issue is still present. Unraid has been amazing until recently and I'm not sure what else I can do beside attempting to delete literally everything and hope it doesn't happen again. I would really like not to lose multiple years worth of data trying to solve this issue if anyone has any other ideas. The last thing I could try would be disabling the Docker service fully and waiting but then the server gets zero use as it's primary use is media playback. I will probably just going to swap to another product if this can't be solved or figured out because manually rebooting the server every 12 hours to 3 days is not a solution. Edit: This has been an issue for OVER FIVE YEARS now with no solution. https://forums.unraid.net/bug-reports/stable-releases/683-shfs-error-results-in-lost-mntuser-r939/page/8/?tab=comments

This is almost certainly and issue with Plex when it attempts to read any media on the server. I'm going to blow out the appdata/plex folder and start a fresh instance. I wonder if there are some issues with old configurations I tried and didn't clean up properly. Either way, I will be recreating the persistent data folder for now and trying again.

I believe this to be an issue with the Official Plex image. It seems to happen when Plex is reading the media. I have now installed the lscr.io/linuxserver/plex version as a test to see if this issue persists. Still seems to happen upon Plex playback and stopping, but the container swap didn't work. I just swapped out my lscr.io/linuxserver/sabnzbd to binhex/arch-sabnzbd to see if the issue persists.

I have narrowed it down to five + one containers. I ended up setting up a simple nginx:stable container as a canary page that is monitored from another host. Within twenty seconds of the shfs service crashing, I'll get an alert to review. ghcr.io/advplyr/audiobookshelf plexinc/pms-docker lscr.io/linuxserver/prowlarr lscr.io/linuxserver/sabnzbd:latest lscr.io/linuxserver/sonarr nginx:stable It doesn't appear the AppData Backup Plugin is the reason either. The crashes happened on days and times that were not at the temporary once a week backup time. Finally, I've observed (without any backing evidence) when sabnzbd is quickly running through a lot of files, the error seems to follow shortly afterwords.

I am still battling with this problem. I'm slowly narrowing down the containers that are causing this issue and will update further. I do however have a question. Would the Appdata Backup plugin accessing `/mnt/cache/appdata` possibly be the issue? This runs nightly for me, but I don't think I had any issues when I only had minimal critical apps. I've remove that directory for now from it's config and will push the plugin schedule out to every week instead of nightly.

Upgraded to 7.0.1 Going on 3.5+ days of uptime with no crash. Hoping it continues for at least 10 days before I re-enable the following containers one by one and test. ArchiveTeam-Warrior CodeProject.AI_ServerGPU Dozzle beszel-agent beszel The above were not the cause. Edit: I'm currently only running the following containers and testing: immich PostgreSQL_Immich Redis_Immich Apache-Tika-Server gotenberg Redis_Paperless paperless-ngx Plex Transmission audiobookshelf TTVPointsMiner

Issue has presented itself again after 2.5 days of being on 6.12.14 There has to be a way to figure what is causing this issue. What can I do?

Ah good to know, thank you. So if my docker containers and VMs are setup using /mnt/user/<share>, then there shouldn't be any issues? Is that a proper understanding of your statement? I was unaware of how easy rolling back was. I am now back on 6.12.14 and will wait to see if it happens again.

Of Unraid. Since there appears to be no way to solve this issue without deleting all data and starting over, hoping it doesn't happen again. This wasn't an issue until I upgraded to 7.0.0 but I could be wrong and only noticed it since then.

Changing the Beszel container was not the fix. Is my only resolution to perform a full and clean reinstall?

I did a more thorough search through my docker containers and noticed that my Beszel Agent was mapped to /mnt/cache/ If I'm understanding this correctly, this might be the issue? If I remap this to /mnt/user/<cache share>, could it possibly this issue? I'll make that change now and test for a few days.

I personally am not using disk shares and all my docker containers are mapped using the /mnt/user/ file paths.

The issue happened again. I've attached the diagnostics. Same error in the syslog. Is there a CLI command that can help me narrow down possible links? tower-diagnostics-20250316-1425.zip

I deleted the files that I know for a fact that I used sym/hard links on under /mnt/user/<share> Unless I'm mistaken on the actual problem here.

I think I got the files that I mapped or linked, but I have no way of knowing without waiting a few days. Is there a way to find them?

Is there a CLI command I can run to verify? Everything I map is under the /mnt/user/<share name>/ I have only accessed the direct disk shares to delete files individually. "I have also set the "Number of fuse File Descriptors" to 813384, which slowed down this issue from happening every day to every few days."

I thought it would be better to make a new thread than attempting to hijack someone elses thread for the same issue I was having. I've attached my diagnostics. On line 3838 in the syslog.txt, I have: Mar 13 21:32:46 Tower shfs: shfs: ../lib/fuse.c:1402: unlink_node: Assertion `node->nlookup > 1' failed. At some point I had attempted to hard link some files from one share to another but I have since deleted those particular files. I have also set the "Number of fuse File Descriptors" to 813384, which slowed down this issue from happening every day to every few days. Is there a way to find or locate the problem? I have no idea what is linked where anymore and I'm getting really tired of having to reboot my server every few days to temporarily solve this issue. If I have to wipe and reinstall, so be it, but I'd prefer to fix this issue first if possible. tower-diagnostics-20250314-0804.zip

Is there an easy way to find and disable these kinds of links? I may have done this accidently and am running into this issue daily.

I would like to add to this as I just solved the issue I was having. My 'docker.img' and 'libvirt.img' on the Unraid "system" share were stored on the array. The system share was set to 'Cache > Array' which caused both of those files to move from the NVME drive onto the array. Disabling Docker and VMs, changing the system share to "Cache < Array", running the mover, and then re-enable both. I personally set the system share to Cache only since it appears only Docker and VMs use it. This has solved my slowness with pulling and updating containers.

Hello, I am having an issue with seeding. I am using I am using ProtonVPN with WireGuard and have followed the steps from Q/A31 on the Github FAQ (https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md). I am not sure what the VPN_USER and VPN_PASS values should be, so I ended up using my Proton OpenVPN / IKEv2 username and password. I have attached the Command Execution and Supervisor Logs. I do not have any issues downloading, only seeding. Thank you in advance for any assistance on this. supervisord.log Command execution.txt

Following since I have the same issues. It used to only be slow and freezing behind my local ssl cert, but now even doing direct IP, Docker comes to a stand still and makes it impossible to do anything on the Unraid system.

Apologies for the necro post but this was one of the few threads I've found that has a solution for deduplication and I wanted to expand on the command above from OP. Mainly just adding the flags from their command so you know what it's doing without blindly running it. jdupes Usage: https://codeberg.org/jbruchon/jdupes#usage jdupes -QrL -X size+=:100000k /mnt/user/<share> -Q --quick skip byte-by-byte duplicate verification. WARNING: this may delete non-duplicates! Read the manual first! -r --recurse for every directory, process its subdirectories too -R --recurse: for each directory given after this option follow subdirectories encountered within (note the ':' at the end of the option, manpage for more details) -L --link-hard hard link all duplicate files without prompting -X --ext-filter=x:y filter files based on specified criteria Use '-X help' for detailed extfilter help size[+-=]:size[suffix] Only Include files matching size criteria Size specs: + larger, - smaller, = equal to Specs can be mixed, i.e. size+=:100k will only include files 100KiB or more in size.

This solved my issue until a fix is implemented from Lime. Thank you very much!