dlandon

Ok. You can send them to me through PM.

Post diagnostics.

You are overreacting a bit here. In the last few weeks there have been more than normal updates because of issues users are having that needed to be addressed, but it is definitely not a daily occurance. UD is not the only plugin that does the update notification. The reason UD comes up more often, is that it is active whenever you are on the 'Main' page. When you log in, you are taken to the 'Main' page, hence UD reacts and issues an update notification. Other plugins you have to use the plugin feature. For example the FIle Browser plugin. You have to browse files before it would initiate an update notification. You have several options to deal with the notifications: Update UD. The best solution and it only requires a single mouse click. This is much less a waste of everyone's time vs. complaining here about notifications. Dismiss the notification banner. I believe it will be dismissed for a day. Uninstall UD. Don't use it if the notifications bother you that much. Submit a feature request to Unraid to deal withe notifications differently. The notification system is part of Unraid. UD updates are issued most of the time to address user issues and holding back updates because a few don't like the notifications doesn't make sense for a user with a problem. If I had a problem, I'd want it fixed as quickly as possible and would want a notification there is an update to potentially fix my issue so I didn't have to go looking for the latest release.

You should set up static IP addresses on your servers. On your 'nas' server you are mounting a remote share on the Unraid server: Mar 6 10:58:13 NAS unassigned.devices: Mounting Remote Share '//UNRAID/ISOs'... Mar 6 10:58:13 NAS unassigned.devices: Mount SMB share '//UNRAID/ISOs' using SMB default protocol. Mar 6 10:58:13 NAS unassigned.devices: Mount SMB command: /sbin/mount -t 'cifs' -o rw,noserverino,nounix,iocharset=utf8,file_mode=0777,dir_mode=0777,uid=99,gid=100,credentials='/tmp/unassigned.devices/credentials_ISOs' '//UNRAID/ISOs' '/mnt/remotes/UNRAID_ISOs' The problem is the IP address of Unraid can change and I'm not sure CIFS can handle that cleanly. On the 'nas' server, you have not done any network configuration: # Generated network settings USE_DHCP="yes" IPADDR= NETMASK= GATEWAY= BONDING="yes" BRIDGING="yes"

@Squid You're tough. I'm on it. I'll make some changes to be included in the next UD release.

Good idea. Maybe this works better:

Here is the issue: Apr 18 16:54:49 unRAID unassigned.devices: Mounting Remote Share '//UNRAID/mnt/user/'... Apr 18 16:54:49 unRAID unassigned.devices: Mount ROOT command: /sbin/mount -o rw --bind '/mnt/user/' '/mnt/rootshare/user-pool.rootshare' Apr 18 16:54:49 unRAID unassigned.devices: Successfully mounted '/mnt/user/' on '/mnt/rootshare/user-pool.rootshare'. Apr 18 16:54:49 unRAID unassigned.devices: Warning: Unassigned Devices are not set to be shared with SMB. Doesn't this show in the device Tool Tip? Share not available. Doesn't show 'Share: Yes". And this when you go the device settings? I don't know what else I can do to tell a user to go to the UD Settings and set "Enable SMB Security" to something other that "No'. No means don't share any UD devices using SMB. Why has this changed you might ask? Because of security reasons, SMB is not enabled by default anymore. It used to be that "No" meant share all UD devices Public. That's a really bad idea to default to Public sharing.

I ran a quick test and it did work for me.

I just looked at your log again and see this. This might be your problem depending on this device needing to be visible on the network: Apr 15 21:11:13 Unraid unassigned.devices: Successfully mounted '//192.168.8.25/Backups' on '/mnt/remotes/NAS_Backups'. Apr 15 21:11:13 Unraid unassigned.devices: Device '//192.168.8.25/Backups' is not set to be shared.

CIFS errors like this are generally network issues. Have you made any changes in your network settings or hardware? Each release of Unraid will potentially have an updated version of samba. Every samba update comes with challenges because Microsoft is continually making changes to SMB for security/updates and the samba team has to try to catch up. Do you have the opprtunity to downgrade to see if the issue remians? If it does, post diagnostics again. Let's shift this discussion to the UD forum because this is probably not an Unraid issue.

It looks to maybe be a networking issue: Apr 17 05:31:41 Unraid kernel: eth0: renamed from veth8c6b04b Apr 17 05:52:53 Unraid kernel: CIFS: VFS: \\192.168.8.25\Backups Close unmatched open for MID:8441542 Apr 17 05:53:24 Unraid kernel: CIFS: VFS: \\192.168.8.25\Backups Close unmatched open for MID:8443211 Apr 17 05:53:56 Unraid kernel: CIFS: VFS: \\192.168.8.25\Backups Close unmatched open for MID:8444803 Apr 17 05:54:27 Unraid kernel: CIFS: VFS: \\192.168.8.25\Backups Close unmatched open for MID:8446309 Apr 17 05:54:58 Unraid kernel: CIFS: VFS: \\192.168.8.25\Backups Close unmatched open for MID:8447662 Apr 17 05:56:32 Unraid kernel: CIFS: VFS: \\192.168.8.25\Backups Close unmatched open for MID:8451591 Apr 17 05:58:06 Unraid kernel: CIFS: VFS: \\192.168.8.25\Backups Close unmatched open for MID:8455817 Apr 17 05:58:37 Unraid kernel: CIFS: VFS: \\192.168.8.25\Backups Close unmatched open for MID:8457093 Apr 17 05:59:09 Unraid kernel: CIFS: VFS: \\192.168.8.25\Backups Close unmatched open for MID:8458260 Apr 17 06:00:11 Unraid kernel: CIFS: VFS: \\192.168.8.25\Backups Close unmatched open for MID:8460857 Apr 17 06:01:45 Unraid kernel: CIFS: VFS: \\192.168.8.25\Backups Close unmatched open for MID:8465455 Apr 17 06:17:34 Unraid kernel: br-379290cfc013: port 1(veth87da490) entered disabled state Apr 17 06:17:34 Unraid kernel: veth48d86f5: renamed from eth0 Apr 17 06:17:34 Unraid kernel: br-379290cfc013: port 1(veth87da490) entered disabled state Apr 17 06:17:34 Unraid kernel: device veth87da490 left promiscuous mode Apr 17 06:17:34 Unraid kernel: br-379290cfc013: port 1(veth87da490) entered disabled state Apr 17 06:17:35 Unraid kernel: br-379290cfc013: port 1(vethee73dfc) entered blocking state Apr 17 06:17:35 Unraid kernel: br-379290cfc013: port 1(vethee73dfc) entered disabled state Apr 17 06:17:35 Unraid kernel: device vethee73dfc entered promiscuous mode Apr 17 06:17:35 Unraid kernel: br-379290cfc013: port 1(vethee73dfc) entered blocking state Apr 17 06:17:35 Unraid kernel: br-379290cfc013: port 1(vethee73dfc) entered forwarding state Apr 17 06:17:35 Unraid kernel: eth0: renamed from veth4507586

Please realize that if you make a change to the settings, the CPU mode be set to "On Demaind" and will not change to "Power Save" until 23:00 hours. UD sets up crons to switch the mode, but doesn't switch the mode if it is in the timeframe when changes are made.

No. Never seen that.

Post diagnostics.

So I am able to reproduce the issue. UD is not making any changes, but now the default seems to be to share, which it is not supposed to do. The default happens when a device is set up and the 'Share' switch is never changed. None of the recent changes should have altered this, but apparently something changed. I'll issue an update sometime today or tomorrow since this is a security issue. It's a security issue because remote shares will be shared without user intervention, as you found out.

UD does not change that setting.

You can't write to /mnt/disks/. From the error message, it looks like your backup is trying to write there instead of /mnt/disks/One_Touch/. That's why you have a permission issue.

UD does not change any settings for sharing. Verify that the "Auto Mount USB Devices?" is set to "No".

Your backup appears to be trying to create a directory at /mnt/disks/, which is a problem. Check your backup directory mapping.

One of your UD disks is having problems, but it is not the one in question: Apr 16 20:02:04 unRAIDpvr ntfs-3g[17149]: ntfs_attr_pread_i: ntfs_pread failed: Input/output error Apr 16 20:02:04 unRAIDpvr ntfs-3g[17149]: Failed to read of MFT, mft=27 count=1 br=-1: Input/output error Apr 16 20:02:04 unRAIDpvr ntfs-3g[17149]: Could not decode the type of inode 27 Apr 16 20:02:04 unRAIDpvr ntfs-3g[17149]: ntfs_attr_pread_i: ntfs_pread failed: Input/output error Apr 16 20:02:04 unRAIDpvr ntfs-3g[17149]: Failed to read index block: Input/output error Apr 16 20:02:05 unRAIDpvr ntfs-3g[17149]: ntfs_attr_pread_i: ntfs_pread failed: Input/output error Apr 16 20:02:05 unRAIDpvr ntfs-3g[17149]: Failed to read of MFT, mft=27 count=1 br=-1: Input/output error Apr 16 20:02:05 unRAIDpvr ntfs-3g[17149]: Could not decode the type of inode 27 Apr 16 20:02:05 unRAIDpvr ntfs-3g[17149]: ntfs_attr_pread_i: ntfs_pread failed: Input/output error Apr 16 20:02:05 unRAIDpvr ntfs-3g[17149]: Failed to read index block: Input/output error Apr 16 20:02:05 unRAIDpvr kernel: Buffer I/O error on dev sdb1, logical block 786459, async page read Apr 16 20:02:05 unRAIDpvr kernel: Buffer I/O error on dev sdb1, logical block 1178, async page read Apr 16 20:02:05 unRAIDpvr kernel: Buffer I/O error on dev sdb1, logical block 786459, async page read Apr 16 20:02:05 unRAIDpvr kernel: Buffer I/O error on dev sdb1, logical block 1178, async page read Apr 16 20:09:43 unRAIDpvr unassigned.devices: Refreshed Disks and Configuration. Apr 16 20:12:05 unRAIDpvr ntfs-3g[17149]: ntfs_attr_pread_i: ntfs_pread failed: Input/output error Apr 16 20:12:05 unRAIDpvr ntfs-3g[17149]: Failed to read of MFT, mft=27 count=1 br=-1: Input/output error Apr 16 20:12:05 unRAIDpvr ntfs-3g[17149]: Could not decode the type of inode 27 Apr 16 20:12:05 unRAIDpvr ntfs-3g[17149]: ntfs_attr_pread_i: ntfs_pread failed: Input/output error Apr 16 20:12:05 unRAIDpvr ntfs-3g[17149]: Failed to read index block: Input/output error Apr 16 20:12:05 unRAIDpvr kernel: Buffer I/O error on dev sdb1, logical block 786459, async page read Apr 16 20:12:05 unRAIDpvr kernel: Buffer I/O error on dev sdb1, logical block 1178, async page read I would do the following: Unmount the disk. Click on the check mark icon for the disk and run a file system check. Reboot if that doesn't work. Is there a chance you removed the disk before it was unmounted?

Post diagnostics.

Because the developer was having a bad day and had to do several updates to get things right.

No offense taken. The notification system comes from too many users not updating and we end up providing support for a problem an update resolves.

If anything is done that is "Bleeding Edge", a beta version is developed for testing. UD had a beta version setup for 6.12 testing because of all the changes that needed to be made. The updates to the beta version were daily for a while. That would have been way too much for the normal user. That setting is how often Unraid will go out and check all plugins for updates and notify the user. The UD plugin has a check built in whenever the UD page is enabled (clicking on 'Main' will enable the UD page) to be sure the user knows an update to UD is available. Many other plugins do the same thing. The UD updates are generally in the two week time frame. When problems arise, an update will be published to solve an issue. Generally minor issues are kept back until a more appropriate time. I'm sorry this is such an inconvenience to you, but as I said you can update the plugin or dismiss the update banner until you are ready to install the update.

Click update and the banner will go away.