dlandon

Yes, try to avoid that for fruit settings. The idea is to make a copy on the flash device. When Unraid sees the smb-fruit.conf on the flash, those settings are applied for fruit settings. If the flash copy is not available, Unraid uses the default settings at /etc/samba/smb-fruit.conf. The idea is that the flash settings get applied on each reboot and you customize for your use case. Settings in that file are commented out. You uncomment the settings you think will apply to your situation and restart samba so you can do some testing. We want people to test and give feedback so we can create a set of generic settings as a default. cat /etc/samba/smb-shares.conf. No. Make your changes and restart samba. They will be applied. Remove any settings related to fruit. Other settings in smb-extras.conf can stay. This scheme insures that the fruit settings are applied correctly per share. There is a special case with fat and exfat file systems. Special settings for these devices are applied because those file systems do not support extended attributes and writes can fail. You can't apply fruit settings globally for all shares.

The disk is trying to use the Unraid password/passphrase to open that device. Has it changed since the disk was formatted? You can enter the specific disk password in the UD settings if it is different from Unraid. The disk password cannot be recovered or changed.

It would be better for you to do your MacOS adjustments using the 6.11 scheme. Modifying the smb-extras.conf can cause issues if not done correctly and we'd like to end up with settings we can apply generically in Unraid. Copy the smb-fruit configuration file to the flash device: cp /etc/samba/smb-fruit.conf /boot/config/smb-fruit.conf Then edit the parameters in the /flash/config/smb-fruit.conf file. Those settings will be applied to the shares when samba is started. These settings will also be applied to UD shares. If all of the SMB shares are not set up with the vfs objects = fruit, you'll can have issues. Restart samba after you make changes: /etc/rc.d/rc.samba restart Be sure the MacOS interroperability setting is on in the SMB settings.

When the Unraid api is used to open the luks device, it does not provide any feedback on whether or not it was successful. The following line tells me that your credentials failed and the luks open did not create the /dev/mapper/ device.

If the log messages didn't show, does everything work? Is there a way you can boot in safe mode and see if the log messages still appear?

Yes, I was thinking about it in the reverse fashion like UD would connect to a remote server.

Support for SMBv1 is still in unraid. What is not there is the ntlmv1 protocol as it has been removed from Linux. It would have been better if it was left in Linux and disabled as the default so it could be enabled as necessary, but LT has no coltrol over that. If a legacy device insists on ntlmv1, it won't be able to connect to Unraid, if it doesn't, it should still connect.

Are you using AD or are any of your clients on a domain?

Why are you using the "server min protocol = NT1" in smb-extras.conf limiting SMB to a very old protocol? Unraid will connect with SMB1 with NetBIOS enabled. If your device wants to connect and use the ntlmv1 protocol if will fail because the ntlmv1 protocol has been removed from the Linux kernel. If your device insists on the ntlmv1 protocol, you'll have no choice but to find an alternative.

Yes, that can be normal. You need to take the your issue to the "Theme Engine" forum.

Are all your shares ZFS volumes? What self installed packages are you installing from /boot/extra? Does everything work even with the log messages?

My point is that you might try to apply an update to the STB because of the older SMB protocol. I cannot find any information on the log message you are getting. If everything is working correctly, you can filter those log messages. The Enhanced Log Plugin allows you to filter log messages.

Do not install glibc or glib2. Glibc 2.36 is already installed in Unraid. Installing a different version of glibc causes all sorts of problems like this. root@BackupServer:~# ls /var/log/packages/glibc-2.36-x86_64-3_LT /var/log/packages/glibc-2.36-x86_64-3_LT The log message is misleading. Perl is already installed in 6.11. Remove those packages from /boot/extra/ and reboot.

I think you have a misconfigured docker container writing something at /mnt/disks/133009479092 when the disk is not mounted. Set docker containers to not auto start and reboot. Mount and unmount the disk in question, then mount and unmount it again. See if the error persists. FCP is also warning about several things you need to fix: Sep 24 10:44:05 Skynet root: Fix Common Problems: Warning: preclear.disk.plg Not Compatible with Unraid version 6.9.2 Sep 24 10:44:09 Skynet root: Fix Common Problems: Warning: Share appdata set to use pool skynetcache, but files / folders exist on the hddcache pool

SMB1 is still supported in Unraid. You enable it by turning on NetBIOS.

If you have a UPS, you can get power consumption stats:

The remote server you are mounting the shares from is using the older SMB 2.0 protocol. What is the remote server you are connecting to?

Are you using AD or are any of your clients part of a domain? You should enable "Enhanced macOS interoperability:" for better operation with your Mac.

What Explorer are you talking about?

It appears this might be from clients on a domain accessing Unraid that is not part of the domain.

Where did you enter that parameter?

Post diagnostics.

Are you using AD?

You are using AD?

Why are you using Jumbo frames? Use the default MTU.