Bug 4747 - swat rewrites fields incorrectly
Summary: swat rewrites fields incorrectly
Status: RESOLVED WONTFIX
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: SWAT (show other bugs)
Version: 3.0.25
Hardware: Other Linux
: P3 normal
Target Milestone: none
Assignee: Samba Bugzilla Account
QA Contact: Samba QA Contact
URL: https://bugs.launchpad.net/ubuntu/+so...
Keywords:
Depends on:
Blocks:
 
Reported: 2007-06-27 02:41 UTC by Soren Hansen
Modified: 2013-09-02 12:54 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Soren Hansen 2007-06-27 02:41:13 UTC
From the Ubuntu bug:

When SWAT re-parses the config file after making changes, it parses and displays
some of the fields incorrectly. This has a nasty side-effect: if you change a
different field, and then click "Commit" again, the broken, incorrectly parsed
values get committed to the smb.conf file, potentially breaking your Samba
configuration.

Here are the fields I've found with problems:

All mode and mask fields assume that the field will be in the format 0###. If
you want directories to be created with the sguid bit, for example, and enter in
2777, it will commit this value to the conf file and then read it back in as
02777, which breaks Samba's interpretation of that config entry.

All entry fields (or, at the very least, admin users, read list, and write list)
misinterpret user and group names with spaces in them. You should be able to put
in entries like '@group name', and indeed, SWAT will translate it to that format
if you put in something like @"group name", but when SWAT reads these back in,
it translates them to: '@group, name'.

There's probably others, but these are the ones I run into most frequently.
Comment 1 Björn Jacke 2013-09-02 12:54:53 UTC
swat is removed in 4.1