I have a strange problem with a “COMMIT”. On the router I have configured multiple user accounts, all of them have admin permission level. After starting the router, user “admin1” can make configuration changes and can make “COMMIT”, next user “admin2” logs in on the router, and also makes changes to the configuration and can also be “COMMIT” them. After that if user “admin1” re-log on the router and make changes to the configuration, will not he could to “commit” them.
After the command “commit” receives the error “Failed to generate committed config”. In the log-stdout.log cfg error appears:
cp [/ opt / Vyatta / config / tmp / new_config_5493] → [/ opt / Vyatta / config / tmp / tmp_5493 / work]
cp in-> tw failed [boost :: filesystem :: copy_file: Permission denied:“/opt/vyatta/config/tmp/new_config_5493/.unionfs/firewall/name/FW-In/rule/20/action/node.val_HIDDEN~”,“/opt/vyatta/config/tmp/tmp_5493/work/.unionfs/firewall/name/FW-In/rule/20/action/node.val_HIDDEN~”]
User “admin2” can still make configuration changes and “COMMIT” them, but only this user, other users have error after “COMMIT”.
I use vyos version:
Version: VyOS 1.1.0
Description: VyOS 1.1.0 (helium)
Copyright: 2014 VyOS maintainers and contributors
Built by: maintainers@vyos.net
Built on: Thu Oct 9 22:27:26 UTC 2014
Build ID: 1410092227-af6433f
System type: x86 64-bit
I have experiencing the same issue. One user has created a configuration entry and when another user attempts to edit they receive the “failed to generate committed config” message and there is a permission denied entry in the cfg-stdout log.
The node.val_HIDDEN file is owned by the original user with user r+w permission only.
Even when the original user deletes the config entry, commits and saves, the other user still can’t re-add the configuration value!
I have this SAME problem once creating a scheduled task to edit the config file.
this is a permission issue. the strange thing is ownership of config.boot is set to root, with the perm group set to vyattacfg this seems to be the default.
perms are set at 775.
nothing lets you commit until you reboot, at that point it starts to work.
i’ll try to login as root instead of default users to see if it takes. (scheduled tasks run as root)
you cannot commit if logged in as root. however if any user OTHER than the default user makes an edit it seems to be affected till reboot.
That is because, unionfs-fuse has wrong file permissions in the temporary mounted filesystem…
in configuration mode
vyos@drake-fw# df -h in the last line will show you unionfs-fuse cd to that mount point and list the files, you will see that they dont belong to you…
soln.
first you have to be in run mode $
Go to the folder /opt/vyatta/config/active
and list the files
vyos@drake-fw$ ls
drwxrwxr-x 10 pedagus vyattacfg 200 Feb 13 08:59 .
drwxrwxr-x 4 pedagus vyattacfg 100 Jan 27 09:41 …
drwxrwxr-x 5 pedagus vyattacfg 100 Feb 13 08:59 .unionfs
drwxrwxr-x 15 pedagus vyattacfg 300 Feb 13 08:59 firewall
drwxrwxr-x 5 pedagus vyattacfg 100 Feb 13 08:59 interfaces
drwxrwxr-x 4 pedagus vyattacfg 80 Feb 13 08:59 nat
drwxrwxr-x 3 pedagus vyattacfg 60 Feb 13 08:59 protocols
drwxrwxr-x 5 pedagus vyattacfg 100 Feb 13 08:59 service
drwxrwxr-x 11 pedagus vyattacfg 220 Feb 13 08:59 system
drwxrwxr-x 3 pedagus vyattacfg 60 Feb 13 08:59 vpn
as you can see the user “pedagus” is the owner of the running configuration, either you have to change them to your user or you have to switch to that user.
“switch to pedagus”
vyos@drake-fw$ sudo su - pedagus
pedagus@drake-fw$ conf …
or
“change the owner to your own”
vyos@drake-fw$ sudo chown -R vyos /opt/vyatta/config/active
vyos@drake-fw$ conf …
sorry for my older answer, it was not fully working…
While this is true, it’s not the root cause of the issue. It’s not the fact that the current active config has the owner set as something other than your current user exactly, which it can be as the group permissions on these files (vyattacfg) would also allow the configuration to be updated (config running as vyattacfg), but the fact that the use of the unionfs-fuse filesystem generates a number of files which are set as read/write only for that user; it’s these files that cause the issue (look at the permissions in the .unionfs directories generated when values are changed).
This shows the issue nicely, and once the config has been commited the file(s) causing the issue are written the active config.
This was resolved in Bug #403 (http://bugzilla.vyos.net/show_bug.cgi?id=403) and will have been in the 1.1.2 release. What version are you seeing this in, is it definitely 1.1.3?
Could you give me an example of the config you’re using to generate this issue, or the steps to recreate this. I’ve just run up a test VM using the 1.1.3 64bit image, configured two users, added and deleted various values, and I’ve seen no issues with either user. This was tested by another couple of users and confirmed to be working at the time I fixed it, so I’d be interested to see if you can still reproduce it.
I was also running into this problem. In my case it was caused by a load-balancing hook-script that i use to redirect some services in the event of a main uplink failure.
the script makes some config changes through /opt/vyatta/sbin/vyatta-cfg-cmd-wrapper - since it seems to be run as root the permissions on /opt/vyatta/config/active are changed to root and subsequent changes with a normal user in cli are failing.
I added a command at the end of the scripts that fix the permissions now.