30. Juni 2021 at 17:37 #51377
Which of our images do you use? Please check the debug info at the bottom of the Settings/Reboot page to see if you are using our Stretch or Buster image. If you are using an older image (e.g. Jessie or Wheezy), please download a fresh Stretch image and burn it to the SD card. Deleting the mount points should work there.6. Juli 2021 at 12:04 #51420
It does not work in Beta either
what I saw in Firefox is that you call
when I press on first or second button. Maybe mountpoint and path are also needed? Just guessing7. Juli 2021 at 16:17 #51430
I tested the Buster image with a Pi 2 and was able to successfully create and delete mountpoints. Have you made any other adjustments to your system? Were the mountpoints added successfully or was there an error message when adding them? You may need to burn a fresh Buster image to the SD card again if your system is corrupted.9. Juli 2021 at 9:05 #51440
I checked the sdcard – it is not currupted.
Of course burning new image would be an option but as I dedicated lots of time to set it up I would like to avoid doing this again.
for troubleshooting steps you might consider:
1. I deleted the mountpoints in /etc/fstab
2 I added one of them with m2p gui – success
3. I checked /etc/fstab modification date after adding -08:51
4. I pressed delete on the newly added mountpoint in m2p gui at 08:53, for several seconds icon of turning gear apears – then it refreshed – feedbacj no message if removing was succesfull or not – just a refresh where the mountpoint is still present
5. INTERESETING – there were no changes in /etc/fstab but modification time of /etc/fstab changed to 08:53 so the time when I pressed „delete“ in gui
So to me there is no corruption but a bug in the file parsing /etc/fstab
14. Juli 2021 at 2:41 #51462
- This reply was modified 1 year, 2 months ago by polrus.
#### blkid ####
/dev/mmcblk0p1: LABEL_FATBOOT=“boot“ LABEL=“boot“ UUID=“B6BB-0F0E“ TYPE=“vfat“ PARTUUID=“0634f60c-01″
/dev/mmcblk0p2: LABEL=“rootfs“ UUID=“638417fb-7220-47b1-883c-e6fee02f51ac“ TYPE=“ext4″ PARTUUID=“0634f60c-02″
/dev/mmcblk0: PTUUID=“0634f60c“ PTTYPE=“dos“
#### mounted ####21. Juli 2021 at 17:25 #51485
I had a similar issue a month ago. I could not add nor delete mount points.
I’m guessing the problem might be with a kernel upgrade.
It looks like a permissions issue somewhere.
I changed the permissions on /etc/fstab (owned by root) from 644 to 666 and was then successful updating the mount points. I’ll see if I can isolate where the edit is performed to see how max2play modifies the file.
Maybe the modification is not elevating privileges properly?
Edit: The change I mentioned above is not a proper fix due to security concerns.
Edit2: I checked and this page runs under user www-data and does not appear to request a privilege elevation.26. Juli 2021 at 12:27 #51506
I have spoken to our developer again. He says that our plugin uses fstab as a direct source for the entries in the web interface. So if the entries in fstab are deleted, another problem ensures that they are still displayed in the GUI. We can therefore only recommend that you burn the image again if nothing else helps.27. Juli 2021 at 8:35 #51514
as I wrote during the troubleshooting steps I could see that /etc/fstab gets updated by m2p (modification timestamp) but the content of fstab is not changed – so the mountpoint remains.
So if the mountpoint is in fstab of course it is displayed.
So again I’m saying that the script responsible for fstab modification is faulty.
You must be logged in to reply to this topic.