dlandon

I suspect there is a Samba issue that restarting the Recycle Bin clears up because when the Recycle Bin is started, it restarts Samba.

Just try the string "error -9 on ioctl to get interface list". It's been a while since I worked with this, but I believe that will work.

Nothing obvious. Where were you moving folders around?

I've not heard of anyone having this issue. Post your diagnostics so I can have a look.

Yes, but be careful. You should set the UD read only switch so you don't make any changes to the disk and invalidate parity. If you want to write to the disk, you'll have to re-write parity as a write operation to the data disk will invalidate parity.

It's something unique to your system. Can you do the following: Install UD if it is not already installed. Set the "Debug Log Level" in UD settings to "Udev and Hotplug". Let it run for a few minutes and log those udev entries in the log. Post another diagnostics. Turn off the "Debug Log Level". It can be overly chatty. Thank you.

SMBv1 is still supported in Unraid. What was lost was the ntlmv1 security that was removed from Linux. If your device does not require the ntlmv1 security, it will still work. Are you mounting the Unraid shares from the player Public or Private? If Private, what rules are you using?

Correct, the smb-fruit.conf file contains all the fruit settings. My wording may not have been the best. In this situation, there is a log message not seen in internal testing or rc releases and we are trying to understand where it is comming from. The smb-fruit.conf file contains the most common settings used for fruit settings. The uncommented settings are the default settings. The commented settings are optional. The idea is to not have to change the smb-extras.conf file to make any adjustments you might need for your particular system. Changes in the extras file are global and the settings in the fruit file are applied per share.

Keep in mind that Samba is being updated regularly and I would bet that a recent change is affecting time machine. This is a "whack a mole" kind of thing. Samba makes changes and LT has to figure out how to make it work with Unraid after the fact.

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: