NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
media share set to webroot after 4.2.19 upgrade
Hello,
I have a ReadyNAS Ultra 4 Plus and I just upgraded to RAIDiator 4.2.19.
Now my media share is the same as the webroot share.
I was going to delete and re-add the media share but a dialog box gave
the following warning:
Deleting the selected share(s) will destroy all data the share(s). Are you
sure you want to delete the share(s)?
It sounds like it will delete all the files in the share and I didn't want to do that.
I looked in /etc/frontview/samba and found Shares.conf and Shares.conf-sav
with what appears to be incorrect data (the files are identical)
[backup]
path = /c/backup
comment = "Backup Share"
oplocks = 1
force create mode = 0666
create mask = 0666
force directory mode = 0777
directory mask = 0777
admin users = "admin","Administrator"
writeable = 1
guest ok = 1
[media]
path = /c/webroot <------------------------????????
comment = "Media Server Share"
oplocks = 1
force create mode = 0666
create mask = 0666
force directory mode = 0777
directory mask = 0777
admin users = "admin","Administrator"
available = 0
valid users = "admin","Administrator","nobody"
write list = "admin","Administrator"
I changed the media path in both files from "/c/webroot/" to "/c/media" and
then did a "/etc/init.d/samba restart"
At this point everything was back to mormal, I could see all my media files
in "/c/media" through the media share.
I wanted to make sure my fix would survive a reboot, so I rebooted the NAS.
The trouble came back, Shares.conf and Shares.conf-sav returned to their
incorrect data fill.
Does anyone know the proper way to fix this trouble?
In case it's is relevant, I have the following add-ons installed:
PHP. PHP+Mysql Support
Subsonic. Media Stream Server
Transmission. P2P Client
WordPress. Blog Software
Thanks
Jim
I have a ReadyNAS Ultra 4 Plus and I just upgraded to RAIDiator 4.2.19.
Now my media share is the same as the webroot share.
I was going to delete and re-add the media share but a dialog box gave
the following warning:
Deleting the selected share(s) will destroy all data the share(s). Are you
sure you want to delete the share(s)?
It sounds like it will delete all the files in the share and I didn't want to do that.
I looked in /etc/frontview/samba and found Shares.conf and Shares.conf-sav
with what appears to be incorrect data (the files are identical)
[backup]
path = /c/backup
comment = "Backup Share"
oplocks = 1
force create mode = 0666
create mask = 0666
force directory mode = 0777
directory mask = 0777
admin users = "admin","Administrator"
writeable = 1
guest ok = 1
[media]
path = /c/webroot <------------------------????????
comment = "Media Server Share"
oplocks = 1
force create mode = 0666
create mask = 0666
force directory mode = 0777
directory mask = 0777
admin users = "admin","Administrator"
available = 0
valid users = "admin","Administrator","nobody"
write list = "admin","Administrator"
I changed the media path in both files from "/c/webroot/" to "/c/media" and
then did a "/etc/init.d/samba restart"
At this point everything was back to mormal, I could see all my media files
in "/c/media" through the media share.
I wanted to make sure my fix would survive a reboot, so I rebooted the NAS.
The trouble came back, Shares.conf and Shares.conf-sav returned to their
incorrect data fill.
Does anyone know the proper way to fix this trouble?
In case it's is relevant, I have the following add-ons installed:
PHP. PHP+Mysql Support
Subsonic. Media Stream Server
Transmission. P2P Client
WordPress. Blog Software
Thanks
Jim
78 Replies
Replies have been turned off for this discussion
- So, ideas on a fix or do we have to wait till 4.2.20 (or 4.2.21) is out for them to acknowledge the fault and fix it in later firmware patches, or will it be fixed by a third-party mod?
- No real fix possible on my side regarding samba, the only thing I cand do is what Missin addon is doing :
recrete share in Shares.conf instead of addons/addons.conf
It's in my opinion a temporary fix , and if it's not solved in a new firmware I will be forced to rewrite all the addons :( super-poussin wrote: simple :
Samba is configured to read Shares.conf but also /etc/frontview/samba/addons/addons.conf
......
sonds like samba in 4.2.19 is not reading the addons.conf and do bad things at boot
by default the nas at boot take a look in /c/ and if a directory is not declared as share it add it in Shares.conf but with 4.2.19 it does silly things
In my case:
1) Samba is reading the addons.conf. It is all OK with "webroot" and "addon-config" share
2) Error exists in Shares.conf. (line "path = /c/media" was changed to "path = /c/webroot" for [media] section)
3) I can fix Shares.conf, then restart samba daemon and all will be OK
4) Shares.conf is changed to error state during next reboot, so problem return.
It is look like copy of samba setting is archived somewhere. If samba setting was changed in conf files, but not throw Frontview, samba configuration restored to old value during next boot.SergV wrote: super-poussin wrote: simple :
Samba is configured to read Shares.conf but also /etc/frontview/samba/addons/addons.conf
......
sonds like samba in 4.2.19 is not reading the addons.conf and do bad things at boot
by default the nas at boot take a look in /c/ and if a directory is not declared as share it add it in Shares.conf but with 4.2.19 it does silly things
In my case:
1) Samba is reading the addons.conf. It is all OK with "webroot" and "addon-config" share
2) Error exists in Shares.conf. (line "path = /c/media" was changed to "path = /c/webroot" for [media] section)
3) I can fix Shares.conf, then restart samba daemon and all will be OK
4) Shares.conf is changed to error state during next reboot, so problem return.
It is look like copy of samba setting is archived somewhere. If samba setting was changed in conf files, but not throw Frontview, samba configuration restored to old value during next boot.
will try to find where but I do not understand why if a webroto share is declared and a media share is correctly declared the nas do such things at boot, before it was only adding things in Sahres.conf if they are not declared- a default config file is here : /etc/default/config/etc/frontview/samba/Shares.conf
but with correct default share : backup and media
at startup the nas is looking in :
/etc/frontview/samba/Shares.conf-sav
then try to restore missing shares super-poussin wrote:
will try to find where but I do not understand why if a webroto share is declared and a media share is correctly declared the nas do such things at boot, before it was only adding things in Sahres.conf if they are not declared
Yes, I will try to find, but later.
There is 2 puzzle now:
1) where is "reference" samba setting. (I think I'll find it by using Frontview backup/restore of setting)
2) Who (and where) modify Shares.conf. It is quite possible that install of add-on do it.- Shares.conf is modified by the readynas startup file
super-poussin wrote: Shares.conf is modified by the readynas startup file
I write my question not qute clear. Fixed version:
2) Who (and where) modify Shares.conf in first time and change "/c/media" to "/c/webroot". There was not any "webroot" before installation of transsnission, so it is quite possible that install of add-on do it.- I take a look onf startup file in 4.2.19 and 4.2.18 regarding samba shares
they are different but both produce good code on startup and correctly add missing shares in Shares.conf SergV wrote:
There was not any "webroot" before installation of transsnission, so it is quite possible that install of add-on do it.
Possible, but not correct
S-P has written many addons which create and use the webroot share, all implemented using the same technique and never by updating the Shares.conf file directly (this file is well known to be written to directly by the firmware).
Read back on this thread and you will also see that this issue has been reported with addons that were last updated many months ago, prior to the release of 4.2.19, and the issue has only been reported by those users who have updated to 4.2.19.
Therefore the only common variable is the 4.2.19 firmware; something in this release has changed and somehow corrupts the Shares.conf file and the onus should now be on Netgear to fix this as S-P has already stated
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
