Well if you look at you file you have t:\Shows -readonly 192.168.1.116
vs t:\Shows -name:Shows -readonly 192.168.1.114
so the share represents differently to 116 and 114, why would you do that!
Ok I can do that but what would I need to change in both my Pi and Vero to make them work again after the change? Because the Pi works, Darwindesign made an xml toofor that and I don’t know how to replace that.
Just tell me what to change in both of my devices and in the xml and i’ll replace everything with what you just said to make it easier for the future
The path subs cannot be the same since your database is not the same and if you want to preserve your library there is nothing to get around that. It is not really much of a big deal. If you change your exports to be the same, and you are using the same system mounts, then the only thing in the advancedsettings.xml file I posted above that has to get tweaked is the <from> paths and you can get those from your sources.xml file on the 192.168.1.114 machine.
Are you sure? In 116 (the pi) they aren’t named so wouldn’t that screw it up completely?
If not I’ll change it and tell me what to test just to be sure
@darwindesign I figured as much, I could set them both to the same IP like @fzinken says but then I’d need some help changing the xml to work on both.
#
# exports example
#
# please read doc for a list of all options
# drive letters should be in upper case, because file-id returns upper case
# by default (option setting) they are mapped to lower case for clients
# Option -range restricts access to specified address range
# a list of addresses restricts to these clients only
# Option -readonly prohibits create/write/delete
# Option -name:<x> makes folder for clients avalailable as /<x>
# Option -maproot:<uid> maps unix root to specified <uid>
# without it uid root -> uid NOBODY
# Option -alldirs allows clients to mount folder or any subfolder
# Use UNC path specification for access to remote drive
# Hidden volumes without a drive letter can be mounted by volume GUID
#
#C:\ftp -range 192.168.1.1 192.168.1.10
#C:\video -readonly 192.168.1.1 192.168.1.4 192.18.1.23
#C:\server -alldirs -name:server -maproot:0 -range 192.168.1.1 192.168.1.30
#\\router\FRITZ.NAS\SanDisk-U3CruzerMicro-00 -name:fritz
#\\?\Volume{6afa3aa3-1b38-11e6-a140-0000fbaa0005}\ -name:drive1
t:\Shows -name:Shows -readonly 192.168.1.114 192.168.1.116
v:\Movie -name:Movies -readonly 192.168.1.114 192.168.1.116
r:\Anime -name:Anime -readonly 192.168.1.114 192.168.1.116
u:\Movies -name:Films -readonly 192.168.1.114 192.168.1.116
What commands can I use to check if they still work properly?
Thanks @darwindesign I’ll try and change it on both devices.
No. The advancedsettings.xml file on the other machine does not change. You broke autofs so you will have to fix that, but the path sub doesn’t change. This second machine has to use this last advancedsettings.xml file I posted. Your original sources were different so they have to be path subbed to match.
Because I’m very unsure of my networking skills, I have destroyed things that worked fine in the past so I rather ask thrice (even though I know it’s annoying, sorry) than f*ck it up again.
Well I think we are now on a much more stable path with the clean export file on hanewin.
So if you adapt the auto.nfs.shares to the above on both systems and reboot then please test
ls -lah /mnt/Movie ls -lah /mnt/Shows ls -lah /mnt/Anime ls -lah /mnt/Films
And we are good for the next step.
BTW an updated showmount -e 192.168.1.120 can also help to ensure the hanewin side is clear.
If you used that same advancedsetting.xml file on both machines then I highly doubt everything is working. If you want to use the exact same file for both then use this…
