dlandon

Download and post the UD log.

The "//" are correct for UD mounts.

Let UD lookup the server and share. When you add an SMB share click on the "Search for Servers in WORKGROUP" button to lookup the servers on your network. Select the server and then click on "Load Shares" and select the share. Enter any credentials and add it to UD. There may be an issue with UD when entering the IP address. I'll have a look.

Use the server and share lookup in UD when mounting SMB shares and you won't have this problem typing it in manually.

Look at the UD log and see why it doesn't mount.

I don't have any idea. How about posting some diagnostics to help troubleshoot?

Done.

Enter this at the command line: /usr/local/emhttp/plugins/recycle.bin/scripts/rc.recycle.bin empty This will empty the recycle bins on all shares.

You need to let me know what packages need to be installed.

Done.

Done. Update to the latest Docker. Because of including these packages and building a new Docker, the latest nightly build of LMS was included. The change log is here. No major changes.

I think that is a great idea. Permission granted.

I finally settled on this: It's more descriptive of the operation being performed - "Format and Partition", not just "Format". And the warning is about the partition not being compatible. The format is not really the problem as @johnnie.black posted earlier. Technically correct now.

I agree. One of the main reasons I continue with it is because it is so damn useful to me. I keep a disk mounted to do daily backups (using a scheduled User Scripts script) and I have USB drives I plug in to create on and off site backups. Quite nice to just plug in a USB drive and have it fire off a script to do a backup and then let me know with a notification it is done. I know a lot of people are mounting UD disks for VMs and Docker use. I don't do that, but I can see the value of UD in that case. I won't abandon UD, but eventually I expect LT will have pick up the UD functionality and include it in unRAID. It has become a "must have" plugin. I finally got to that point with the powerdown script. It was becoming very difficult for me to keep up with the changes, and it was time for LT to clean up the powerdown process. They did it and it works much better than the powerdown plugin.

Better?

Correct, but the uninformed user is warned ahead of time that the disk is not going to be compatible with the array. Whether or not it's technically the format or the partition is not really important because the format operation in UD does the format and partitioning in one operation and the user is given notice ahead of time.

Adding this to the format dialog: Couldn't be any clearer than that. It's not a matter of disagreeing. I think the feature would be useful, just not in the UD plugin.

UD Help text: Note: A disk formatted in UD is not compatible with the array disk format and cannot be added to the array. Users are forewarned. Yea, I know you'll tell me no one reads the help. UD formats the disks in the format most compatible for the disk and file system. It is not doing some bizarre format. And, yes I do not care to invest the time in understanding the unRAID partitioning and formatting commands.

When I said it was not worth my time, I meant that I invest what little spare time I have to features that are useful to a wider crowd. I don't have the time to invest in features that a small group of users will benefit from when there are other answers - i.e. proper backups. I do not get paid for any of this work, and I get no benefit from the license fee that LT charges. If there is a shortcoming in unRAID, then you should be lobbying LT for the feature. I'm sorry you feel that I didn't take your ideas seriously, but trying to sell me on this with all your reasoning does not change the fact that I just don't think it appropriate for UD to format disks for the array.

This appears to be an edge case that would not be worth the investment in time on my part to implement. I feel that it is outside the scope of what UD was designed to do. Using UD is not the proper way to prepare a disk for the array. I could see a lot of support come up when users try to perform the odd gyrations you describe here. Your process might be fine for you, but it is rife with potential errors by the casual user. When replacing a disk in unRAID, just install it and let it rebuild. Why use unRAID and then don't trust it to rebuild a disk? Use dual parity for a multiple disk failure situation. If you need this capability desperately, ask LT to add a feature to format a new disk not in the array to be array compatible.

This has been asked before. Why would someone want to format a disk in UD for the array? This is not what UD was designed to do.

I've issued an update to UD that turns the diskinfo from preclear back on. When the preclear plugin is installed, there is a background daemon that preclear uses for disk information to cut down on disk queries. UD also takes advantage of this diskinfo. This was done because a preclearing operation can appear hung, or stop completely when there is too much disk query activity on the preclearing disk. UD now checks to be sure the rc.diskinfo daemon is running before using the diskinfo.json file for disk status. If the daemon is not running the diskinfo.json file will not be current and shouldn't be relied on. There were also a duplicate mounting attempt on ntfs disks with issues like an unclean shutdown, or a hibernated disk. The ntfs mount is successful in these cases, but the disks will be mounted as read only. This has apparently changed in the latest release of Linux and/or the ntfs driver. In the past when there was an error from these situations, the disk would not be mounted and UD would have to mount the disk read only. UD now checks that the disk is actually mounted and won't try another mount unless it actually did not mount. Let me know if you have any issues with mounting ntfs disks.

I think I've sorted it out. I'm sure it was caused from my mounting an already mounted disk. The result I am getting from the unclean shutdown disk mount is: Jul 08 15:02:51 Mount failed with error: The disk contains an unclean file system (0, 0). Metadata kept in Windows cache, refused to mount. Falling back to read-only mount because the NTFS partition is in an unsafe state. Please resume and shutdown Windows fully (no hibernation or fast restarting.) I always assumed in UD that this was a mount failure, but in fact the mount is successful and the disk is mounted read only. I then tried to mount the device read only, but it was already mounted. It seems that the ntfs mount has changed and a disk in this situation is now mounted read only, when in the past it would fail to mount with this condition and I then mounted it read only myself. I'll post an update to UD that will fix this situation.

I think it's on my side. UD mounted the drive with the unclean shutdown, and then decided to try mounting it again after it was already mounted. Hold on this issue for the moment. I believe it is on my end.

When I mount a particular disk the rc.diskinfo daemon stops once in a while. It's hard for me to reproduce. I can see the daemon has stopped by ls /var/run/. This disk does have an unclean shutdown flag set on it. The log in UD says the mount command failed, but it still mounts. I'm trying to understand that. I'm not sure it has anything to do with the rc.diskinfo daemon stopping. I also uninstalled and then re-installed preclear once and the rc.diskinfo daemon did not start. Again this is not consistently happening. Is there a way to capture a log or something that will show why rc.diskinfo has stopped?