As a newbie to Kicad I like to store the designs on our network drive. As Kicad users dont have to deal with license limitations, all friends what have access in my network should be able to open the Kicad files on network drive or as copy from their on PC. Although there is some disadvantage in access speed, the network drive offers comfortable diffrence backups each night.
After installation, Kicad and its libraries were installed on the local drive. Diffrent location names for Windows and Linux are equalized by Environment Variables like KICAD6_FOOTPRINT_DIR what is local defined at install time. The substitution value depends from operation system for Windows c:… or Linux /usr/share/kicad/…
Later the access is done by ${KICAD6_SYMBOL_DIR}/libname.kicad_sym what expands to
/usr/share/kicad/libname.kicad_sym in runtime.
How to avoid designs what contain Library path like /home/username/… what cannot opened by other users ?
On Linux my drive access is smb://10.10.20.18/data18/jv/job
On W10 before mapping the drive: \\10.10.20.18\data18\jv\job
On W10 after mapping network drive: Z:\jv\job
How to equalize Windows \libname.kicad_sym and Linux /libname.kicad_sym ? I already heard from UNC path names but do not know on how to use for my own network drive in Kicad projects
But you already posted the answer: environment variables. You can define your own user environment variables to expand to the platform specific part of the pathname. Then you would use something like:
${KICAD_USER_SYMBOL_DIR}/part.kicad_sym
which would be the same no matter which platform you are working on. / works as the pathname separator for Windows paths here.
One thing though, URLs like smb://server/path/file may work in browsers, but most Linux applications need a normal pathname. But you are able to mount SMB shares on Linux at mountpoints, giving them normal pathnames. See the man page for mount.cifs (8) or mount.smb3 (8).
Since 6.0, symbols used in the design are stored with the project, which is a great thing. No worries when other users open your project.
The much bigger issue is the libraries. The default KiCAD libraries cannot be edited.
Creating a user-defined library store for all users would probably be the biggest advantage to your plan.
For the moment I stuck for unkown reasons. Assume, my SMB share is already mounted correct (?) Therefore I am using the Gnome File Manager Nautilus to mount “Other Locations” and then entering the Address in “Connect to Server”. It is possible to mount the drive twice with identical contents.
The two possibilities use symbolic server name or its internal IP address what should make no diffrence. ts1200_18 is the name of a Buffalo Terra Station File Server 2 slot model 1200 located in building 18.
There are identical copies from the project folder pbus on remote drive smb://ts1200_18/data18/jv/job/pbus and local drive home/pbus
Both seems to have R/W permissisions what work with Nautilus. Other programms also work well, e.g. we store KeePass KDBX files on network.
With local drive everything works fine. Network drive also works until I like to save any file. The project manager freezes and schematic editor displays an error message. Maybe anybody can see the reason what went wrong ? Bug of gvfs ?
Full expanded file path is like this format:
/run/user/1000/gvfs/smb-share:server=10.10.20.18,share=data18/jv/job/kilib/active.kicad_sym
Version: 6.0.10-86aedd382b~118~ubuntu22.04.1, release build
Many thanks for your hints. Using cifs instead gvfs solved all problems in using Kicad in local NAS multiuser environement.
My mount is now:
jv@JamesWebb:/etc$ sudo mount -t cifs //10.10.20.18/data18 /media/netshare -o username=nas,password=nothing,uid=1000,vers=2.0
I had to play around a little and parameter vers=2.0 is doing the trick. My Buffalo obviously doesnt support SMB3 (or I did not enable?) and its default for the mount command. I am going to modify fstab and moving user/pass into seperate file to make it system permanent. No more complaints about Kicad in this matter. Its working on local drive and remote NAS as well.
