Smokes your problems, coughs fresh air.
Sometimes you want to mix users with and without a roaming profile. As found here, you can use Samba’s pdbedit to set the “Profile Path” to empty:
pdbedit -p= leo
Then view the results with:
pdbedit -L -v leo
I logged off the user, performed that change, renamed the directory on the server just in case, and then logged on again. It worked like a charm.
For some reason, after upgrading to the Samba version from Lenny-backports I needed to support Windows 7 profiles, the workstations suffered from severe problems. The entire profile seemed to be read-only, even though they weren’t on disk. I couldn’t change any setting and reverting profile configuration from backups didn’t help. In the end, the only thing that fixed it was recreating the user profile, both server and client side. This was an upgrade from 3.2.5 to 3.4.7.
Another issue I had is that the user database got a new backend and all the users were gone. You can import your existing smbpasswd file with pdbedit.
So, when doing this again, be sure to make workstation and server backups.
Windows 7 kept creating a $RECYCLE.BIN dir on the network share. This in itself is merely annoying, but there were also errors resulting from it. Whenever a file would be deleted, this message would appear (translated from dutch): “The recycle bin is damaged, do you want to delete the contents?” Everything froze until that question was answered.
Samba has an option “veto files” which can be used to stop the creation of that directory. Put this in each share’s section in your smb.conf:
veto files = /*$RECYCLE.BIN/
The slashes are not directory separators in this case. Also, I don’t know if the preceeding * is necessary, but it does no harm.
Because I wanted to be able to give Windows 7 machines access to our domain controller, I needed to upgrade samba to 3.4 from lenny-backports. Because the database backend changed, a consequence of this was that the user database was empty; it didn’t migrate it.
pdbedit has an option to import the old smbpasswd file:
pdbedit -i smbpasswd:/etc/samba/smbpasswd
That should take care of it. I didn’t test it this way though, because I already fiddled with the user database by creating new users by hand. I imported one user with which I still had problems correctly this way, but I don’t know if importing this database from the start would have prevented all my errors.
Newer samba versions no longer have a human readable password file. To see the passwords, use pdbedit. Do “pdbedit -w -L” to get a classic password file layout.
People are stupid and remove things accidentally. You can partly mitigate that by adding recycle bin functionality to a samba share.
[Our documents] comment = Central storage for all our documents path = /home/smb guest ok = yes writeable = yes browseable = yes force group = samba create mask = 0660 directory mask = 0770 ; recycler vfs object = recycle:recycle recycle:subdir_mode = 0770 recycle:repository = .recycle ; directory name recycle:keeptree = Yes recycle:touch = Yes recycle:versions = No recycle:maxsize = 100000000 ; 100 metric million bytes
The action is hooked on the delete action. Pressing shift-delete won’t prevent files from being moved to the recycler, which is good.
You can then make a cron job which throws away old files:
# Every day at 6am 0 6 * * * root find /home/smb/.recycle/ f -mtime +5 -delete > /dev/null
When you mount a samba share without unix extensions enabled, you can set a GID, UID and permissions (on the client machine, at mount time) so you can adjust it to let non-root users use it.
Mounting FAT works this way as well. But there is a big difference. Where new files on a FAT file system are created according to the permissions you set at mount-time, new files on a SAMBA share have their permissions determined by the umask. However, when you unmount and remount the share, the permissions are changed to what they were set to at mount time.
This is very annoying behavior, because when you have files that belong to root:smbusers and you copy a file, it still belongs to root:smbusers, but when your umask is 0022, it will no longer be group writable and it has become a read only file.
I think this is a bug in the SMBFS/CIFS file system driver.
I noticed when I did ‘du -hs’ on a sambamount, I got a disk usage that was unrealistically high. I did some research, and it appears that Samba rounds off file sizes to whole MB units, to optimize for windows clients:
And btw, why is samba rounding the minimum size up to 1MB ?
An optimisation for Windows clients. If we do this they allocate actually run faster against a Samba server (based on tests done by a NAS vendor).
© 2025 BigSmoke
Theme by Anders Noren — Up ↑
Recent Comments