So, my NAS promted me to tell me that a firmware update was available and, upkeeping with the latest versions, I decided to go ahead and do the update via the web browser. Seems painless ...
After the update, at first glance things seemed okay, but after a while I noticed something very badly wrong. None of my SMB shares were availble, and nothing I tried worked to resolve the problem. Looking at the services page, SMB was disabled, and wouldn't enable!! Yep, that's all my music, videos, family photo's, work data - POOF!!
I enabled the SSH access (took me a few hours to get that service to enable as well!!) and after looging into the NAS via SSH (and a fair ammount of Googling) I notice every sigle file/folder on the NAS is now owned by both user:guest and group:guest. (See below screenshot of the Samba files)
I'm now rebuilding my NAS (47 hour resync on the volume) before I can put my data back on the device. So what's my point?
People use thier NAS device as, guess what, a storage device for thier personal data. How can Netgear release such a rubbish firmware update that technically bricks a device?
C'mon Netgear, get your house in order. It's not rocket science to test your release in a lab environment before releasing it into the public! As for the support, why would I pay you to support a device you broke in the first place?!?
You didn't told us which is the ReadyNAS OS software version that your NAS was running before the upgrade request to download and install latest ReadyNAS OS 6.9.0...also doing preliminary checking - through SSH - of most important log files would be helpful to understand what happened during/after the update (and Yes...knowing where to look for is important to have a smooth start...ranting isn't helpful).
From the timestamps, the NAS was running 6.8.1 and prompted an update to 6.9.0.
As for what happened next, who knows. What I can say is, the NAS worked fine before, and after the update doesn't!
But hey, here's the question: why woud the /var, /sys, /etc directories need to be owned by guest? They wouldn't. If the config files for these services isn't owned by root (or at least admin) then none of the services will work.
Apology for the rant, but yeah, after what should be a simple a update, needing to spend a week on data recovery does tend put you in a bad mood 🙂
Only App I run on the NAS is Plex Media (had it running for years) to stream Music/Video around the House. It runs seemlessly in the background, with little (if any) effort needed to maintain.
Only other App I've looked at is Rsyslog to see if I can make any use of it. Rsyslog was installed from the NAS app store and, after checking, removed because I can't make any use of it.
If this were App related, then suppose fundementally the question would be how did an App get into the Netgear App store that has the potential to not only break the NAS, but change the permissions on every single file/folder on the device? Surely they're tested to make sure they don't introduce such critical vulnerability before being released?
If not App related, then the point still stands re Firmware update.
Similar to firmware, as and when Plex notifies me of an update I install it so Plex would have been running the latest version.
Thing with Apps, I use the NAS to store kids school work, my contract work, family photos etc as well as Music/Video's etc. So I tend to avoid installig apps unless I think I can make use of them. Hence Rsyslog.
How possible is it to get hold of a RN104 running 6.8.1 and install Rsyslog to observe the behaviour, if nothing else to validate the App?
The thread you post is from July 2017, we're in November 2017. IF LogAnalyser is such a big problem, why is it still availble?
ofc, the last thread doesn't take into account the previous 2 threads posted, unless the assumption is everyone is bricking thier NAS' by installing LogAnalyser?
Given the suggestion that this could stem from an application problem, and seeing as I already the data backed off my NAS, I've done some testing.
1. I've downloaded the official Firmware recorvery tool, and built a USB recovery disk using firmware 6.9.0. 2. Using the USB boot menu, I've reinstalled the firmware, and also (for good measure) completed a factory reset of the NAS. 3. I've logged into the NAS, and completed the 'New' setup wizard.
After completing the above, the NAS has a default setup, and a series of default shares (Videos, Pictures, Documents) and checking the permissions of each - Anonymous and Everyone are allowed Read/Write access and the folder owner is user:guest/group:guest.
Again, for good measure, I created a 'Test' share and the same permissions are alocated to each new share created. As a new install, with no Apps, this means that the permissions problem has nothing to do with an App changing the permissions, but a fundemental problem with the permissions temaplate being used.
Seems somehow, the permissions template has been used to reset the file/folder permissions during it's last firmware update.
Worth noting that, after reinstall and factory reset, the permissions on the system config and system folders (/var, /etc, /sys etc) is root:root which I beleive is correct.
I understand your original case was bad, but FWIW I'm on 6.8.1 and when I create a share it defaults to guest:guest. If you go to Settings for the folder (gear icon in front view to right of folder) and select the File Access tab you can change the ownership. I think the create share feature is working as designed.
Thanks gsm1212. I genuinly appreciate the input of people, but I think this topic has gone slightly off track. Agree, per default behaviour, when a new share is created it's owned by guest/guest.
The purpose of the post was to raise awareness of the fact that, following (what should be) a routine upgrade to 6.9.0, things stopped working. I didn't install any Apps, I simply downloaded the firmware and applied it via the NAS Web session.
My experience is similar to others (from googling seemingly quite a few) in so much that SMB shares seem to spontaneouly stop working. There's plenty of examples of people coming across these issues because permissions have been incorrectly applied. Maybe some of them installed a dodgy App, maybe some of them didn't.
The elephant in the room seems to be the reason why, the permissions template used for creating new shares, is somehow being applied and over writing the permissions for system files/folders.
Admittedly, I don't know enough to know why this would happen but what I do know is this:
/var /sys/ /etc /run /opt are all examples of system folders that contain various libs and config files which will break any Linix distro if not owned by root. After completing a firmware update, all these folders were owned by guest:guest
Again, for good measure, I created a 'Test' share and the same permissions are alocated to each new share created. As a new install, with no Apps, this means that the permissions problem has nothing to do with an App changing the permissions, but a fundemental problem with the permissions temaplate being used.
I understand your original issue (linux system folders having the wrong owners).
I don't see how the test share results relate to that; it seems to me you have simply confirmed the default behavior for OS 6 systems.
