dlandon

Update UD and set the Settings->Unassigned Devices "Force all SMB remote shares to SMB 1v?" to "Yes" and your remote SMB share should mount. Post diagnostics if you have any trouble.

It appears that samba is now defaulted to ntlmv2 security and not ntlm as it has in the past. The samba developers are trying to increase the security of samba and have defaulted to SMB3 and ntlmv2 because they are more secure. Since the 'sec=' parameter is not set in the mount command in UD, it defaults to the samba default setting. The CIFS mount on your remote server may have worked in the past when ntlm was the default security, but with the default to ntlmv2, it won't mount. ntlmv2 is supported on unRAID. It's your remote server that does not accept ntlmv2. Setting the security to ntlm has made the mount compatible with your Windows 2016 server. You may be able to set the Windows 2016 server SMB security and overcome this limitation. If you can I would do that for increased security. I am adding a setting in the Settings->Unassigned Devices so the security can be specifically set and not depend on the samba default. UD will default to the ntlmv2 protocol and you can select ntlm if your remote server does not accept ntlmv2. This will apply to all SMB mounts. In my testing with ntlm as the security setting, I found some mounts would only mount with SMB1, so ntlm is actually more of a security issue than just the ntlm setting. SMB1 is an old SMB protocol, is not very secure, and is going to probably be phased out of samba. I would recommend always using ntlmv2 and try to get the remote server to accept it through a configuration setting or a software/firmware update if possible. EDIT: I've decided a better way to handle the security situation is to force ntlm with the "Force all SMB remote shares to SMB 1v?" when it is set to "Yes". It looks like this is what is happening anyway.

Please try sec=ntlmv2 and let me know if that works.

Please post your diagnostics in this thread. Other people can also review the diagnostics and provide feedback. Your diagnostics are anonimized to remove personal information.

The Diagnostics helps me understand the circumstances that cause you to have to set the security level. What you have done does not necessarily apply to all users. Just because this works for you, does not mean it will work for everyone. I need to understand when to use it.

Please post your diagnostics.

@gfjardim I made changes to UD to handle mounting encrypted disks. rc.diskinfo needs to be updated to handle the parameters UD needs to properly deal with the encrypted disks. You can review the code at the UD github, but to summarize UD needs: $disk['luks'] = $disk['device']; if ($disk['fstype'] == "crypto_LUKS") { $disk['device'] = "/dev/mapper/".basename($disk['mountpoint']); } $disk['target'] = $disk[device]; the disk mounted check on $disk['device'] should work properly to detect the mounted status. Let me know if you need any assistance.

That got it. Thank you.

If you want to keep the preclear plugin installed, go to the Settings>Unassigned Devices and set the "Enable Preclear rc.diskinfo daemon?" to "No" so it is not used to update the UD status. The rc.diskinfo has not been updated to support the UD mounting of encrypted disks. @gfjardim will need to update the preclear plugin.

This is the cron on my server: # Generated ssd trim schedule: 30 5 * * * /sbin/fstrim -v /mnt/cache | logger &> /dev/null Both servers running 2017.04.23a. Ok. I figured out one difference that could affect the decision to include the '-a'. On my backup server I have a UD ssd and that is probably what is used to include the '-a'.

Both servers are the same setup. Cache is an SSD and system share is on cache as 'Prefer' cache setting. Why would there be a difference?

The SSD Trim plugin on my backup server seems to be doing more trim than the cache drive: Dec 30 05:30:02 BackupServer root: /etc/libvirt: 920.7 MiB (965451776 bytes) trimmed Dec 30 05:30:02 BackupServer root: /var/lib/docker: 13.3 GiB (14318682112 bytes) trimmed Dec 30 05:30:02 BackupServer root: /mnt/cache: 474.1 GiB (509044609024 bytes) trimmed I'm not sure how the libvirt and docker loop files got into the trim. My main server with the SSD trim plugin only does the cache drive: Dec 30 05:30:57 MediaServer root: /mnt/cache: 564.3 GiB (605934116864 bytes) trimmed Where can I look to see why this is happening?

Remove it and see if it works.

Do you have the preclear plugin installed?

That's not a very good way to show the log. It would be better to attach the syslog and not include it in the body of the post. UD is not seeing the disk as encrypted and is not opening it with luksopen. Post a screen shot of UD where the drive file system is shown. Right now UD recognizes encrypted disks with the file type 'crypto_LUKS'. Your disk was attempted to be mounted as an xfs disk. UD uses the unRAID keyfile. You cannot enter the passphrase manually.

I've updated the docker to install mariadb 10.3.2 only and not update mariadb beyond that.

There is an issue with the latest mariadb update (10.3.3) releaaed on 12/23 that has caused me some problems. If you have not restarted your ownCloud docker since 12/23 just go into the Docker with this command: docker exec -it ownCloud bash and delete the /etc/my_init.d/20_apt_update.sh file with this command: rm /etc/my_init.d/20_apt_update.sh This will prevent the mariadb update when the ownCloud docker is restarted. If you have restarted the ownCloud docker and it has updated to 10.3.3, then do the following. - Stop the ownCloud docker, click on "Basic View" to change to the Advanced View, then click on "Force Update". - Disconnect your server from the Internet. - Start the ownCloud docker. - Go into the Docker and delete the 20_apt_update.sh file as above. - Restart the ownCloud docker. - Reconnect to the Internet. The ownCloud docker will not update to mariadb 10.3.3. You can check the version of mariadb installed by executing the command: mysql -V while in the ownCloud docker. The version should show as 10.3.2. In the future I will probably not allow the mariadb package to update on startup.

A new version of UD is available. You can now mount array disks that are encrypted. There are some restrictions: The array disk passphrase has to be defined. You cannot enter the passphrase for the disk in UD. The disk can only be mounted if the current array passphrase is the same as the encrypted disk. An array encrypted disk cannot be created with UD.

Not necessarily. I am encrypting a UD disk manually now and I will see what it takes to mount. What I need help with is accessing the key to decrypt the drive. I may be able to find it on my own, but help from LT would be appreciated. EDIT: I think I may have figured it out. I've been able to mount an encrypted disk.

Eventually, but their plate is very full. Don't expect it any time before 6.4 is released. I am in touch with LT and will try to deal with encrypted mounts. Give me some time to work it out.

UD does not handle encrypted volumes.

Yes, that is the issue. The rest works.

@bonienl I need some help with the SMART testing on UD devices. As you can see, I am referencing the drive as /dev/sdg. The SMART reports don't work. I expect it is because the drive is not in the array. What is the answer to this issue?

Doesn't work. Not sure what it will take to fix.

I got out of software development back in 2000 when software development was being outsourced overseas. I am not working in the profession at this time. I've been in the computer/software game since the mid 70s. In fact I just sold an IMSAI computer I've had since then. I guess doing software work is my way of keeping my mind sharp as I age, and I actually enjoy the challenge. Problem is I tend to overload my arse at times.