dlandon

That's a lot cleaner also. NFSv4 might be better at handling this situation.

The unmount is failing with a mount timeout: Apr 9 17:21:52 unRAID unassigned.devices: Unmount cmd: /sbin/umount -fl '10.253.0.2:/mnt/user/ricketts' 2>&1 Apr 9 17:22:22 unRAID unassigned.devices: Error: shell_exec(/sbin/umount -fl '10.253.0.2:/mnt/user/ricketts' 2>&1) took longer than 30s! Apr 9 17:22:22 unRAID unassigned.devices: Unmount of 'ricketts' failed: 'command timed out' The '-fl' option does a force lazy unmount on a NFS mount. The idea is to force the unmount even if the remote server is off-line. It appears that is not working and by all the research I've done, it is supposed to. I don't have an answer.

Use a Docker for ownCloud.

Maybe this will help: https://www.thomasmaurer.ch/2019/09/how-to-enable-ping-icmp-echo-on-an-azure-vm/

That would be best. A diagnostic a week later doesn't really help.

Several things I see: Apr 1 13:29:12 unRAID kernel: eth0: renamed from veth47e1ca0 Apr 1 22:00:32 unRAID rsync[13809]: connect from 192.168.0.12 (192.168.0.12) Apr 1 22:00:32 unRAID rsync[13810]: connect from 192.168.0.12 (192.168.0.12) Apr 1 22:00:37 unRAID rsyncd[13809]: name lookup failed for 192.168.0.12: Name or service not known Apr 1 22:00:37 unRAID rsyncd[13809]: connect from UNKNOWN (192.168.0.12) Apr 1 22:00:37 unRAID rsyncd[13810]: name lookup failed for 192.168.0.12: Name or service not known Apr 1 22:00:37 unRAID rsyncd[13810]: connect from UNKNOWN (192.168.0.12) Apr 1 22:00:37 unRAID rsync[13854]: connect from 192.168.0.12 (192.168.0.12) Apr 1 22:00:42 unRAID rsyncd[13854]: name lookup failed for 192.168.0.12: Name or service not known Apr 1 22:00:42 unRAID rsyncd[13854]: connect from UNKNOWN (192.168.0.12) Apr 1 22:00:42 unRAID rsyncd[13854]: rsync allowed access on module backups from UNKNOWN (192.168.0.12) Apr 1 22:00:44 unRAID rsyncd[13854]: rsync to [email protected] from UNKNOWN (192.168.0.12) Apr 1 22:00:44 unRAID rsyncd[13854]: receiving file list Apr 1 22:00:44 unRAID rsync[13924]: connect from 192.168.0.12 (192.168.0.12) You need to stop your rsync if the remote goes off-line. It's spamming the log. You are using NFSv3. MFSv4 is more robust. Upgrade to 6.10 and enable NFSv4 in UD Settings. I don't see any UD unmount attempts in the log. There isn't an Unraid shutdowon in the log.

Post your diagnostics.

It's generally configurable on the remote server.

The remote server must respond to a ping or UD thinks it is off-line and marks the share as off-line.

Solution several posts up.

Edit the ownCloud Docker template and select php 7.3 or 7.4. 7.4 would be preferrable to prevent this in the future.

Good. NFSv4 is much more robust.

What version of Unraid are you using? If 6.10 are you using NFSv3 or NFSv4?

Are you using Jumbo Packets?

When it happens again, check the disk ball. If is is grayed out, the remote server is not responding to a ping and UD thinks it's off-line.

When the remote server goes off-line, the check for the size, used, and free fails and zeroes are returned. That's why you see the 0 bytes for size. This is generally due to a remote server going off-line or a network issue. Post diagnostics the next time it happens before you reboot.

It doesn't appear that there is anything for me to fix here. You need to understand how the age days work. In your case, aging files 4 days it is actually aging files older that 4*24 hours ago and not 4 calendar days ago. If the cron runs at 3:00 AM, any files older that 4*24 hours ago will be removed. If there is a file that was deleted 4 days ago at 3:30 AM, it would not be aged at 3:00 AM because it is less that 4*24 hours ago, even though it was deleted 4 calendar days ago. If you want better granularity, then run the cron every hour. This will remove any files older that 4*24 hours ago every hour.

Or use UD Preclear to clear off the disk.

Also try uninstalling and re-installing UD Plus after you reboot if the CA warning persists. It's possible the .plg is corrupted.

I noticed something in your diagnostics that might be a sign of a flash problem. unassigned.devices-plus.plg - 2021.12.12 (Unknown to Community Applications) CA flagged that plugin as unknown because it had trouble getting information from the .plg file on your flash. I would suggest making a backup of your flash and then reboot and let Unraid run a flash check when it starts back up.

No. Works for me. Show me a screen shot of your file activity settings.

This normally happens when there aren't enough notify watches, but there is generally a log entry saying there aren't enough. Try using the 'Tips and Tweaks' plugin and increase the "Max Watches 'fs.inotify.max_user_watches':" value and then starting file activity.

There is an easier way of doing this. Give the disk an alias name and use that name to mount/unmount the disk: /usr/local/sbin/rc.unassigned mount name=MusicBk /usr/local/sbin/rc.unassigned umount name=MusicBk

It's a suggestion, not a requirement. There's really no reason to use the recycle bin on those shares because they are not user shares. I ran a test last night on the latest release of the plugin and it didn't delete the aged files. I'm testing again tonight with a change I made that I believe was causing the issue. It seems to be intermittent, so I'll be running my tests for several nights to be sure I've in fact got it.

The log of deleted files are files deleted in the shares, not files deleted from the Recycle.Bin folder by the plugin command. I am testing one thing I don't like in the script, but I'm not sure it is affecting the removal of aged files. The aged files are determined by the 'find' command, not what 'stat' shows. The age days of 4 would I think be files that are over 4 days old, not exactly 4 days old. I think you might be over analyzing this.