Per this thread, I have just installed the 4TB internal SSD from my old/faulty Rev B Nucleus in my new Titan.
Roon (1490 on macOS 15.2) seems to be able to see the hardware:
but neither Roon nor I in the Finder can see the contents of the SSD. Nor can I connect to the Nucleus web interface…
Ethernet ports flickering etc…
Anyone any ideas, please?
(I suspect I’m just missing some simple step. Thanks!)
See if this helps when using the appropriate device (i.e., Titan) name…
The Web Interface can also be accessed by:
Typing in the IP Address of the RoonOS Device in a Web Browser
Typing the hostname of the device, for example http://rock , http://nucleus , http://nucleusplus , http://nucleustitan or http://nucleusone
Typing the .local suffix for the device, for example http://rock.local , http://nucleus.local , http://nucleusplus.local , http://nucleustitan.local , or http://nucleusone.local
Thanks, John - No: neither Roon nor I (I get ‘Connection Failed’ in the Finder) can see the Nucleus Titan files.
Is the hard drive formatted properly via the Roon webUI?
He can’t even open the web UI 
But anyway, I happen to know the story and the SSD was previously in another Nucleus and formatted.
@Mark_Sealey is you Mac logged into the home network? And what’s its IP?
iMac is: 192.168.0.170
Titan is: 192.168.0.66
OK so that should work. To be honest it sounds to me as if something might be failing (together with your PM showing that the Finder sees the Titan but then can’t connect either). Though both the built in web server (for the http to the web UI) and Samba (for SMB) both failing seems also weird and somewhat unlikely.
I know this is not what you want to hear. Nor do I, but it’s all that I can think of right now.
I suggest Roon support should take a look (open a new Nucleus Support topic). You sure paid enough for it and had enough Nucleus trouble already.
It looks like you clicked on “Configure Roon OS devices” at the bottom of the Roon desktop UI. Do you not see the same Roon Server (with a purple “Connect” button next to it) on the same page in the UI?
I agree with others that connecting an HDMI cable to your new Titan is a useful troubleshooting tip. Seems likely that the 4TB internal SSD may have been the old/faulty part in your Rev B Nucleus. Perhaps the old server would work fine without it.
Thanks, David!
That’s right.
That’s what I would have expected too. No, just that in the centre of the Roon page.
I was prepared for that this time. Bought this.
But got ‘No Signal’ when I connected it to either HDMI port 
I don’t need to enable anything else for the Titan to show at least something on that HDMI monitor, do I?
I wondered that.
‘No signal’
You using the right port one is audio only.
It’s beginning to look that way, isn’t it
When I log in (which I can consistently do) to the Mac as server and go to Backups, I see that I shall have to create a new SMB share. Is that what you’d expect?
I hear you!
I’ve always been wary of rebooting the Nucleus. But maybe that’d a next possible option.
Is there really no damage just to press and hold the (dimly lit) power button for four seconds, then - when it’s down - press and release again to reboot?
Either A or B is OK?
Menzies,
I can certainly try that. But the grub screws to secure the SSD tray etc are somewhat stiff and for my arthritic fingers will take some time
You’re saying that the the monitor may be not showing anything because the SSD may be faulty, aren’t you?
Safest way to power down, given that I can’t ‘unmount’ (etc) it from the macOS filesystem?
Thanks, Menzies - makes perfect sense.
I’ll try rebooting first and report back if that doesn’t do the trick; then do as you and @Suedkiez say.
It’ll take some time. Very grateful. More later
With very many thanks to @Suedkiez, @anon15113244, @David_Snyder and @jb76, @CrystalGipsy I’m pleased to report that a reboot of the Titan did the trick.
It showed up in the Finder, the web GUI and - eventually, after the updates I needed to apply in the right sequence and maintained over restarts with the consequent need to ignore ‘Can’t connects’ - in Roon itself. I’m back in business.
I was particularly impressed/pleased with how the Roon database restore went because the last time (when I moved from internal Mac storage to my Rev B at the end of 2023) I still had to go in and re-edit many (most?) of the (far fewer) albums’ settings.
This community, and Roon technology (as well as the team who so expertly and expeditiously handled the RMA for me) on top once again
A little postscript for anyone who knows Carbon Copy Cloner, please.
Once things had settled down, I ran CCC’s task to clone all necessary music files in my Nucleus Titan Watched folder to an external hard drive - one which I’ve had as a backup for months.
To my surprise, CCC evaluated (and in many cases actually copied) every file in the Source - Roon’s Watched Folder on my new Titan.
Could that be because the process of Forcing a Rescan or something else associated with installing the SSD from my old Rev B into Titan (so, after all, the paths were different: Rev B and Titan) caused CCC to think that all my music files in the Roon Watched Folder were all out of date and/or newer than those already on the external backup drive etc?
Or that CCC is aware of a Linux/RoosOS touch performed such that it really does see every file as in need of being part of the clone?
I thought about this, but not sure. I’m not sure if CCC considers the path name to the files. If so, a different path name (as you noted already) would most likely make CCC see these as new files. Even if CCC uses file hashes to establish file identity, a different path might nevertheless make it see them as new files even if the hashes are the same.
But if the path name caused it, CCC should re-copy all files in the path, not just some of them. So this doesn’t seem a great explanation, at least not the whole explanation.
The ext4fs file system of Linux offers the recording of an access time stamp, which is updated by touch. Whether it is enabled is an option during the mounting of the file system. Some systems turn it off, which improves read spead and the number of writes on SSDs:
https://wiki.debian.org/SSDOptimization
(Though noatime is known to cause problems with some specific software that rely on access times).
I don’t know the configuration that Roon OS uses for the internal music disc, and I never checked the access times of the files. If it’s enabled, the Roon Server’s accessing of music files would update the atime and it’s possible that CCC uses this for deciding what to back up, too, I guess. Though on the other hand, I wonder if it shouldn’t use the file modification time instead (which is always recorded), because why re-copy a file only because it was accessed. But I’m not a backup software designer and maybe there are reasons.
Thanks very much, @Suedkiez, for those thoughts.
They all make sense, don’t they.
On checking CCC’s log and the metadata for the files on the (macOS) clone this morning, I see that they have ‘done’ something which I wouldn’t expect: Although the clone last night took nearly three hours, each and every file is now showing its original Creation and Modification date… those which mirror exactly the Creation and Modification dates on Titan!
This graphic shows parent folders - but all the FLAC files in each also show the same thing.
It’s either as though what I saw when I was monitoring the clone (many files appeared to have a modification date of January 24 2025 last night with their times corresponding to ‘activity’ by CCC) was CCC putting them in a buffer somewhere for comparison, and that buffer is/was on the Target volume. Or the Finder (I also checked in Terminal: same thing) was displaying some kind of interim state for each file and folder!
Either of those supposition also seems plausible because there were several times last night (this being my first Titan clone) when directories appeared (or were?) literally empty - both in the Finder and at the cli. (They always ‘filled up’!)
It does prompt me to wonder how much of the ext4fs filesystem it would be of benefit for us users to know about.
There is a document somewhere from RoonLabs wisely advising (=instructing) us only to concern ourselves with the ‘InternalStorage’ directory itself. Because RoonOS is not one and the same as Linux and because it’s written specifically to service Roon.
I’m OK with that. But curious for this reason (paths again): when I launched each CCC task last night I had to amend the Source… although I didn’t record the source as it applied to my Nucleus Rev B, it was different: one level lower, I think.
While that almost certainly does explain why CCC needed to ‘update’ things, some sort of FAQ on how Nucleus filesystems are setup would be useful, wouldn’t it?
Do we know that RoonOS runs on Debian?
Yeah, they emphasized that they have rolled their own system, based on the Linux kernel and surely other free software that usually goes into a Linux distribution, but just including what’s necessary and surely with some configurations, such as Linux kernel options, tweaked to their needs.
That would contradict the above to some extent. Though Debian may best be seen as a toolbox from which one can build lots of more specific OSes, but I think Roon OS is different enough that most likely not. To a large extent, being Debian-based is defined by its APT package management system, and for all we know, Roon OS doesn’t use this. (It wipes the primary disk on ever update, as we know from when people manage to copy music to it). And even if something was once started from Debian, once APT is gone, it’s IMHO not Debian in any case. Nor would it make much sense when building something very different.
All of which just means that Roon could have configured any number of kernel or other settings differently than the settings in a general-purpose distro, and we don’t know much about it.
