CS01-HS

6.12 offers a partial solution with cache-only shares bypassing shfs (if you can restructure your workflow to use them.)

If I remember right 127* doesn't work, you have to use the LAN IP. I've run mine like that for years. I also have these tweaks in config/go: # Put syslogs in system/logs (web ui only allows share root) cp /etc/rsyslog.conf /etc/rsyslog.conf.orig sed -i -e 's/\/mnt\/user\/system\//\/mnt\/user\/system\/logs\//g' /etc/rsyslog.conf # name logs by hostname instead of IP sed -i -e 's/FROMHOST-IP/FROMHOST/g' /etc/rsyslog.conf # Apply changes /etc/rc.d/rc.rsyslogd restart With the corresponding change to logrotate (along with other tweaks) in a user script set to run At Startup of Array – for some reason they didn't work in config/go. #!/bin/bash # update logrotate with non-default syslog location cp /etc/logrotate.d/rsyslog.local /etc/logrotate.d/rsyslog.local.orig sed -i -e 's/\/mnt\/user\/system\//\/mnt\/user\/system\/logs\//g' /etc/logrotate.d/rsyslog.local # add compression sed -i -e 's/missingok/missingok\n compress\n delaycompress/g' /etc/logrotate.d/rsyslog.local # make sure log size doesn't exceed 10MB (setting to 10MB unintuitively allow up to 11MB) sed -i -e 's/size 10M/size 9M/g' /etc/logrotate.d/rsyslog.local # not sure this is necessary /etc/rc.d/rc.rsyslogd restart exit 0

I didn't remake anything as far as I know. This morning I spotted and deleted a leftover NerdPack directory in plugins - I can't imagine I mistakenly cleared templates-user but the timing seems too close for coincidence.

I compared the backup to the boot drive and the only difference is the missing user templates. Copied them over and all's back to normal. Strange.

[email protected]:/boot/config/plugins/dockerMan/templates-user# ls -l total 0 [email protected]: Huh, well that explains it. As it happens I ran the new Appdata backup overnight and they're present in the flash backup... will investigate.

I noticed in /boot/config/plugins a leftover directory from NerdPack, a plugin I'd uninstalled a while ago. It made me wonder if there's a standard method for cleaning up the plugins dir or the flash drive generally. A sort of "based on your settings here's a list files that by default shouldn't be there."

I use it, great plugin. But because it stops my containers for about 15 minutes I only run it weekly. Even if you run it nightly, what I'm proposing would allow a simpler (2 click) up-to-the-minute-it rollback.

Before updating sensitive containers I'll typically stop the container, tar up its appdata dir, then apply the update. This makes it easy to rollback in case something goes wrong. It'd be handy if this process were automated – present a Backup and Update menu option when an update's available, and Rollback and Delete Backup menu options when a backup's detected.

Happened again, my first time with rc3. Failed creation of a new folder on a share from my Mac (possibly duplicate name) produced this in the log (I use syslog sever.) Apr 19 08:25:28 NAS emhttpd: read SMART /dev/sdd Apr 19 08:25:57 NAS emhttpd: read SMART /dev/sde Apr 19 08:34:54 NAS shfs: shfs: ../lib/fuse.c:1450: unlink_node: Assertion `node->nlookup > 1' failed. Apr 19 08:34:54 NAS rsyslogd: file '/mnt/user/system/logs/syslog-nas.log'[9] write error - see https://www.rsyslog.com/solving-rsyslog-write-errors/ for help OS error: Transport endpoint is not connected [v8.2102.0 try https://www.rsyslog.com/e/2027 ] Apr 19 08:34:54 NAS rsyslogd: file '/mnt/user/system/logs/syslog-nas.log': open error: Transport endpoint is not connected [v8.2102.0 try https://www.rsyslog.com/e/2433 ] Apr 19 08:34:54 NAS emhttpd: error: get_filesystem_status, 7380: Transport endpoint is not connected (107): scandir Transport endpoint is not connected Shares inaccessible. Had to stop everything and reboot. I have to treat every file operation over SMB as though it might take down the array. That's a serious inconvenience.

I gave up on unraid time machine (I now use a time capsule) so my comment's not based on experience with the recent versions but it seems to me the later samba versions made MacOS less compatible generally – search doesn't work out of the box, folders don't always refresh when their content changes (which sometimes causes fuse errors that take down the array.) I'd be tempted to blame MacOS but I have an old Raspberry Pi running samba 4.9.5 that works just fine.

I've triggered it a few times with SMB file operations from my Mac client where the folder/file structure was stale. Since then I force a refresh by e.g. navigating down a directory then back up before every SMB move or copy. Tedious but so far it hasn't failed.

Done. I'm getting strange results. It works except for a handful of files which always error out. If I skip them it copies fine. And they copy fine to a standard unraid share. I checked their permissions, etc, no issues. These files might have thrown off my earlier reports of what was or wasn't working. I think you've caught the major issue though, some conflict with the "MacOS interoperability" setting. Thanks for helping me solve it.

Attached. Errors in Windows 10 are consistent now but Mac is fine. Strange. The "Windows" is actually Parallels VM. I thought that might affect it but the same VM writes to standard unRAID shares without issue. In case it's helpful: # smbstatus Samba version 4.17.5 PID Username Group Machine Protocol Version Encryption Signing ---------------------------------------------------------------------------------------------------------------------------------------- 15540 windows users 10.0.1.3 (ipv4:10.0.1.3:49285) SMB3_11 - partial(AES-128-CMAC) Service pid Machine Connected at Encryption Signing --------------------------------------------------------------------------------------------- file_history 15540 10.0.1.3 Mon Mar 27 03:08:49 PM 2023 EDT - - Locked files: Pid User(ID) DenyMode Access R/W Oplock SharePath Name Time -------------------------------------------------------------------------------------------------- 15540 99 DENY_NONE 0x100081 RDONLY NONE /mnt/disks/file_history . Mon Mar 27 15:08:49 2023 nas-diagnostics-20230327-1510.zip

I did and it seems to be working now both on Windows and Mac, thanks. In windows event log I see entries like below referencing the share but maybe they're expected: Are there specific tests you'd like me to run before I restore 'macOS Interoperability' ? EDIT: Darn, I spoke too soon. The copy operation in windows just failed with another entry like the above in the event log.