media share set to webroot after 4.2.19 upgrade

[super-poussin]

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

[SergV]

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.

[super-poussin]

Shares.conf is modified by the readynas startup file

[SergV]

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.

[super-poussin]

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

[sphardy]

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

[ranko]

So true Sphardy... Maybe one of te Jedi's could swing by this thread and we can ask them for their input and see if they can point some of the Netgear guys to look at this issue, whilst they still have 4.2.20 in test stage.

[SergV]

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.

It is all correct. Something has changed in 4.2.19. I try to find reason of problem. I try to help S-P and Netgear community. I'm sorry if I have offended.
I think it is usual compatibility problem.

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

I do not know anything about writing add-on for ReadyNas, but there are 2 variants:
1) If add-on use well documented API for creating share, then Netgear should to fix problem.
2) If add-on use some hack or reverse-engeneering information, then S-P should to fix problem. In this case it will be good if Netgear give us some good well-documented API. In any case it is strange for me that there are not any information about webroot in Frontview list of common shares.

[ewok]

I'll take a look later on today/tomorrow and will let you know what I find.

[Bboek]

I have something similair that may help in finding the problem.

I did a completely new install clean with 4.2.19
after the clean install media was found in /media and in /c/media they were equal in content but didn't pay attention to it
since I was building a new system

Then I installed airvideo 2.0 and ffmpeg 1.3 and from that moment onwards the directories had different content
media from root contained the airvideo directory
and /c/media kept the media content

However now I got an annoying message Tue Sep 27 09:44:01 CEST 2011 Unsuccessful mounting ftp share media in the logs

I am a Linux noob, but if anyone could help that would be great,

[super-poussin]

perhaps a temporary fix :

at startup readynas overwrite the Shares.conf with Shares.conf-sav

but the sav file is not correct so what I have done on a unit :

Recreate a correct Shares.conf with all the shares then copy it as Shares.conf-sav then reboot the unit and it's ok

Code: Select all

[backup]
  path = /c/backup
  comment = "Backup Share"
  oplocks = 1
  force create mode = 0666
  create mask = 0666
  force directory mode = 1777
  directory mask = 1777
  admin users = "admin","Administrator"
  writeable = 1
  guest ok = 1

[media]
  path = /c/media
  comment = "Media Server Share"
  oplocks = 1
  force create mode = 0666
  create mask = 0666
  force security mode = 0666
  force directory mode = 0777
  directory mask = 0777
  force directory security mode = 0777
  admin users = "admin","Administrator"
  writeable = 1
  guest ok = 1
  vfs objects = recycle
  recycle:versions = 1
  recycle:repository = Recycle Bin
  recycle:subdir_mode = 777
  recycle:keeptree = 1
  recycle:directory_mode = 777


[addons-config]
  path = /c/addons-config
  oplocks = 1
  force create mode = 0666
  create mask = 0666
  force security mode = 0666
  force directory mode = 0777
  directory mask = 0777
  force directory security mode = 0777
  admin users = "admin","Administrator"
  writeable = 1
  guest ok = 1
  vfs objects = recycle
  recycle:versions = 1
  recycle:repository = Recycle Bin
  recycle:subdir_mode = 777
  recycle:keeptree = 1
  recycle:directory_mode = 777

[webroot]
  path = /c/webroot
  oplocks = 1
  force create mode = 0666
  create mask = 0666
  force security mode = 0666
  force directory mode = 0777
  directory mask = 0777
  force directory security mode = 0777
  admin users = "admin","Administrator"
  writeable = 1
  guest ok = 1
  vfs objects = recycle
  recycle:versions = 1
  recycle:repository = Recycle Bin
  recycle:subdir_mode = 777
  recycle:keeptree = 1
  recycle:directory_mode = 777



[ewok]

This seems to already be fixed in the latest in-house code, and will appear in the next beta.

[ranko]

This seems to already be fixed in the latest in-house code, and will appear in the next beta.

4.2.20 or 4.2.21 ?

[iernie]

Newest beta apparently has this fixed: http://www.readynas.com/forum/viewtopic.php?f=51&t=57193

[T4] Prevent issue where third-party add-ons have the possibility to break Share configuration.

[michelefaccini]

Same issue with 4.2.19...I had to modify the Shares.conf (etc/frontview/samba) and the Shares.conf-sav (etc/frontview/samba)....now almost all my shares appear to be where there were supposed to even after several reboots...Just one question : is it correct that PHP5-5.3.8-rnx86 1.4.1 is under webroot ? Should this addon normally be under addons-config folder ? I have also Transmission which under both addons-config and webroot folders !! Do I have to fix these two anomalies...and how ?