unRAID Server Release 6.2.0-rc3 Available


Recommended Posts

First time using 6.2? please read the Original 6.2-beta Announcement Post first.

 

Also please review the Announcement posts for previous 6.2-rc releases, especially if this is your first upgrade to 6.2-rc.

 

IMPORTANT

[*]Your server must have access to the Internet to use the unRAID 6.2 rc.

[*]Posts in this thread should be to report bugs and comment on features ONLY.

 

HOW TO REPORT A BUG

Think you've found a bug or other defect?  Ask yourself these questions before posting about it here:

[*]Have I successfully tested this bug with all my plugins disabled (booting into safe mode)?

[*]Can I recreate the bug consistently and have I documented the steps to do so?

[*]Have I downloaded my diagnostics from the unRAID webGui after the bug occurred, but before I rebooted the system?

Do not post about a bug unless you can confidently answer "Yes" to all three of those questions.  Once you can, be sure to follow these guidelines, but make sure to post as a reply on this thread, not as a new topic under defect reports (we track bug reports for beta/rc releases independent from the stable release).

 

INSTALLING AND UPDATING

If you are currently running previous 6.2-beta/rc release, clicking 'Check for Updates' on the Plugins page is the preferred way to upgrade.

 

Alternately, navigate to Plugins/Install Plugin, copy this text into the box and click Install:

https://raw.githubusercontent.com/limetech/unRAIDServer-6.2/master/unRAIDServer.plg

 

You may also Download the release and generate a fresh install.

 

RELEASE NOTES

 

The primary "fix" in this release has to do with symlink and hard link support:

- Fixed a bug in 'mover' script which prevented symlinks from being moved along with other files between cache/array.

- Added proper support for hard links in both shfs (limetech's user share file system) and the mover script.

 

The latter required us to write a custom 'move' utility that invokes 'rsync' as before, but also keeps track of multiply-linked files in order to handle them correctly.  That is, when a file with 2 or more hard links is encountered by 'mover', we go ahead and copy the file and then delete it on the source (if successful copy).  But since there are multiple links, the file is not really deleted (it's name is just removed from the directory).  Later when we encounter a subsequent link to this file, instead of copying it, we recreate the hard link in the target, and then delete that file on the source.  Eventually after all references to the file have been processed in this manner, the storage of the file on the source is actually released.

 

As usual, any files that are "in use" (meaning open by some process or loopback-mounted) are skipped (not moved).

 

unRAID Server OS Change Log
===========================

Version 6.2.0-rc3 2016-07-27
----------------------------

Base distro:

- php: version 5.6.24 (CVE-2016-5385, CVE-2016-6207)

Management:

- added "make bootable" script and syslinux for Linux clients
- emhttp: ignore case in parsing http header fields
- md/unraid: correct detection of new non-precleared disk(s) added to array
- mover: add hard link support
- mover: fix symlink support
- shfs: add hard link support

webGui:

- correctly handle symlink location display when browsing user share
- show reboot notice when a unRAID OS update applied and awaiting a reboot
- show warning for Server Name when it doesn't meet NetBIOS standards

Link to comment
  • Replies 190
  • Created
  • Last Reply

Top Posters In This Topic

Spun up a fresh install of rc3, when creating user shares they're not displayed in the Shares tab.  They're created OK, can be seen as shares from Windows, and visible from Docker, etc, but just no shares available in the webui.

 

Check if you have an adblocker running and whitelist the GUI.

 

Link to comment

Spun up a fresh install of rc3, when creating user shares they're not displayed in the Shares tab.  They're created OK, can be seen as shares from Windows, and visible from Docker, etc, but just no shares available in the webui.

 

I am not having any trouble viewing shares in the shares tab

Link to comment

Spun up a fresh install of rc3, when creating user shares they're not displayed in the Shares tab.  They're created OK, can be seen as shares from Windows, and visible from Docker, etc, but just no shares available in the webui.

 

Check if you have an adblocker running and whitelist the GUI.

 

Derp.  That's it.  I've moved from Chrome to Firefox recently, and didn't have the server whitelisted.  :D

Link to comment

Getting the following error when I am trying to update a docker, was getting it under RC2 as well, just upgraded to RC3 today.

 

Error: layers from manifest don't match image configuration

 

This is a known issue Ash, the root cause was fixed in RC2, but you need to delete your docker.img and redownload your containers in order to fix the issue now.

Link to comment

Hmm, how do I do that? Its just one docker I don't really care about, I could just delete it. Sounds like more work than its worth.

 

Thanks

 

Go to settings then docker and disable the service.  Delete the docker.img from wherever it resides, restart docker service, go to community applications, previously installed apps and pull the container again.  Five minutes work tops.

Link to comment

- added "make bootable" script and syslinux for Linux clients

 

At long last - acknowledgement that not everyone has a machine running Microsoft (or even Apple)!

 

Surprisingly we've gotten only a couple requests for that over the last few years.  I revamped our internal development machine recently and a small part of that was moving from grub to syslinux so half of the r&d work for the make bootable script was already done as part of that revamp.

Link to comment

- added "make bootable" script and syslinux for Linux clients

 

At long last - acknowledgement that not everyone has a machine running Microsoft (or even Apple)!

 

Surprisingly we've gotten only a couple requests for that over the last few years.

 

Probably because most Linux users are technically savvy enough to perform the required operations manually.

 

I revamped our internal development machine recently and a small part of that was moving from grub to syslinux so half of the r&d work for the make bootable script was already done as part of that revamp.

 

Whatever the stimulus, it's a welcome addition!

Link to comment

 

Surprisingly we've gotten only a couple requests for that over the last few years.  I revamped our internal development machine recently and a small part of that was moving from grub to syslinux so half of the r&d work for the make bootable script was already done as part of that revamp.

 

Most people have access to a real OS as well as linux.  :P

Link to comment

- added "make bootable" script and syslinux for Linux clients

 

At long last - acknowledgement that not everyone has a machine running Microsoft (or even Apple)!

 

Surprisingly we've gotten only a couple requests for that over the last few years.  I revamped our internal development machine recently and a small part of that was moving from grub to syslinux so half of the r&d work for the make bootable script was already done as part of that revamp.

 

The requests may be minimal, mainly because it's clearly documented that it only works on Windows/Mac... and most people have access to either... but I am thankful that it now supports linux... I just setup 2 unRAID servers for friends, and I would have rather used the linux script ;)  So thanks!

 

Link to comment

Is there any way (or will there be in the final release of 6.2) to prevent the automatically created shares (ie. appdata, domains) from being recreated after each upgrade once they've been deleted?

 

They haven't been created for me on RC3.  But I have got other locations specified where I want appdata and domains stored.

Link to comment

Is there any way (or will there be in the final release of 6.2) to prevent the automatically created shares (ie. appdata, domains) from being recreated after each upgrade once they've been deleted?

 

They haven't been created for me on RC3.  But I have got other locations specified where I want appdata and domains stored.

Rather than deleting the shares just go and change them to not be exported

 

Sent from my LG-D852 using Tapatalk

 

 

Link to comment

Is there any way (or will there be in the final release of 6.2) to prevent the automatically created shares (ie. appdata, domains) from being recreated after each upgrade once they've been deleted?

There are 4 predefined shares: appdata, domains, isos, and system.

 

The name 'appdata' is actually taken from Settings/Docker/Default appdata storage location.  If you change this from

/mnt/user/appdata

to, e.g.,

/mnt/user/local-data

It will actually try to auto-create the 'local-data' share when Docker starts the first time.  If the location you specify is not a user share, eg,

/mnt/disk1/some-share

Then it does not auto-create anything.

 

The 'domains' and 'isos' shares are handled in the same manner.  'domains' is taken from Settings/VM Manager/Default VM storage path, and 'isos' is taken from Settings/VM Manager/Default ISO storage path.

 

The 'system' share is defined in two places: Settings/Docker/Docker storage location and Settings/VM Manager/Libvirt storage location.  If  you don't like the 'system' user share being auto created you have to change both of those paths.

 

Assuming you change all the paths, and delete any predefined shares that might have been created before you changed all the paths, then there should no longer be any further auto share creation.

Link to comment

Can someone clarify for me what I should be doing for Docker and VMs in reference to the shares? It was my understanding that I should map docker .img and appdata to a disk directly and not use user share as it can cause issues, is this correct? Or should I use user share and create hard links? I'm confused now ha. I'm not using a cache drive btw.

Link to comment

Can someone clarify for me what I should be doing for Docker and VMs in reference to the shares? It was my understanding that I should map docker .img and appdata to a disk directly and not use user share as it can cause issues, is this correct? Or should I use user share and create hard links? I'm confused now ha. I'm not using a cache drive btw.

While LT states that hardlinks do now work on user shares it is still a new feature with not a lot of evidence as of yet as to the stability or usability of that feature.

 

For the immediate future you'll be safest putting docker appdata directly onto a disk share.

 

Sent from my LG-D852 using Tapatalk

 

 

Link to comment
Guest
This topic is now closed to further replies.