samba не создает папки на машинах с виндой.

Pусский (Russian) Общий
#1

Как то все работало,и вот сегодня нужно было скинуть пару файлов в виндовую шару(Win 10),
значицца захожу в дольфина(suse 42.2),открываю сеть,общие папки самбы,рабочую группу,
вижу список машин,выбираю нужную, захожу в расшаренную диру,жамкаю пкм чтоб вставить файл
и оппппаааа-пункт «вставить файл» не активен,так же не активен пункт «создать»,
захожу в любую диру в этой шаре-там все активно,т.е. файлы вставляются и создаются,
так же можно создать еще папки, однако если зайти во вновь созданную мной же папку т
о там картина повторяется-«вставить файл» и «создать» снова не активны.
Оке,думаю что глючит шинда 10 захожу на шару с ХР-и все то же самое,аналогичная факня и с 7кой.
I need help…
Версия самбы 4.4счемто.
Пробовал версию 4.5 из репа samba:stable-не помогло,все осталось так же.

smb.conf

[global]	
workgroup = groupname
server string = openSUSE	
netbios name = Andrey	
passdb backend = tdbsam	
#	security = User	
map to guest = Bad User	
usershare allow guests = Yes
#	ldap admin dn = 
#	passdb backend = smbpasswd	
usershare max shares = 100
#	wins server = 
#	wins support = Yes
#	client lanman auth = Yes 
#    client ntlmv2 auth = No
#    preferred master = Yes
#    domain master = Yes
#    name resolve order = lmhosts bcast host wins			
Общая]	
path = /home/white/Общая	
guest ok = Yes	writeable = Yes	
read only = No	
create mask = 0777	
directory mask = 0777

все что закоментированно-попытки решить вопрос,не повлияли на ситуацию никак. В логах из криминального только этот момент

STATUS=daemon 'smbd' finished starting up and ready to serve connections
[2017/01/20 10:24:06.606086,  0] ../source3/smbd/trans2.c:3342(smbd_do_qfsinfo)
  smbd_do_qfsinfo: not an allowed info level (0x201) on IPC$.
[2017/01/20 10:24:06.606858,  0] ../source3/smbd/trans2.c:3342(smbd_do_qfsinfo)
  smbd_do_qfsinfo: not an allowed info level (0x105) on IPC$.
[2017/01/20 10:24:07.753207,  0] ../source3/smbd/trans2.c:3342(smbd_do_qfsinfo)
  smbd_do_qfsinfo: not an allowed info level (0x201) on IPC$.
[2017/01/20 10:24:07.754032,  0] ../source3/smbd/trans2.c:3342(smbd_do_qfsinfo)
  smbd_do_qfsinfo: not an allowed info level (0x105) on IPC$.
[2017/01/20 10:24:14.764497,  0] ../source3/smbd/trans2.c:3342(smbd_do_qfsinfo)
  smbd_do_qfsinfo: not an allowed info level (0x201) on IPC$.
[2017/01/20 10:24:14.765460,  0] ../source3/smbd/trans2.c:3342(smbd_do_qfsinfo)
  smbd_do_qfsinfo: not an allowed info level (0x105) on IPC$.
[2017/01/20 10:24:14.776158,  0] ../source3/smbd/trans2.c:3342(smbd_do_qfsinfo)
  smbd_do_qfsinfo: not an allowed info level (0x201) on IPC$.
[2017/01/20 10:24:14.776952,  0] ../source3/smbd/trans2.c:3342(smbd_do_qfsinfo)
  smbd_do_qfsinfo: not an allowed info level (0x105) on IPC$.

попробовал откатить версию самбы на предыдущую-не помогло. Есть мысли у кого что это за гадость?
Между машинами с виндой папки создаются без проблем,
так же на станции с сюзей виндовые машины могут делать
папки и копировать файлы.
Так же осталась проблема которая тянется у меня еще с
13.1,а именно запрос пароля на доступ в виндовые шары.
Думается что тут какая то засада именнов в винде,.т.к
дома в аналогичной ситуации проблем нет.
Тема которая была начата про suse 13.1
https://forums.opensuse.org/showthread.php/517922-Suse-13-1pae-Сломалась-самба-при-обновке
В общем буду рад помощи о тболее опытных пользователей сюзи.

#2

>>в виндовую шару(Win 10)

так шара на винде или самбе?
права фс у самого каталога шары норм?

#3

С машины на линуксе не создаются папки и не копируются файлы в расшаренные папки на винде.Между машинами на винде все работает.
Т.е. если я захожу в шару на винде с линукса то в корневой папке шары у меня сломалась возможность создать папку или вставить файлы в корневую папку шары,но если зайти в любую уже существующую папку в этой же шаре то пункты “вставить” и “создать” в меню дельфина становятся активными,т.е. я могу создать еще одну папку либо вставить файлы.Однако если я создам папку и зайду в нее то в этой новой папке ситуация повторяется,пункты меню "создать"и “вставить”
в дельфине неактивны вновь.Между виндовыми машинами все работает нормально,т.е.файлы вставляются и папки создаются в любом месте шары.Так же без проблем создаются папки и в шаре на лируксе.Т.е. проблема именно при подключении к винде с линукса.Причем к любой винде-такая ситуация и с 10й и с 7й и с ХР

#4

предлагаю смонтировать шару с mount.cifs и посмотреть права

#5

Если монтирую от рута то есть возможность менять файло и создавать
папки в примонтированной шаре,но под обычным пользователем
все то же самой-неактивны пункты в меню доступа
И мне нужна просто обшая папка под файлопомойку,
без изысков.Странно городить огород из консоли и заходить
в дельфина с рут-правами для того чтоб отправить пару файлов на комп с виндой.
Но виндовых тачках проверил все-доступ в шару для всех,читать и писать в этих
папках можно всем,и между виндовыми тачками проблем нет.
Проблема при доступе именно с линукса на винду.
И с правами было б понятно если бы винда не могла записывать в шару на
линуксе,но ситуация обратная-линукс не может в виндовые шары,хотя виндовые
машины между собой прекрасно все копируют.
Так что я не могу понять с какими правами проблема,
ведь самба не может назначить права винде,т.к. там права самой виндой
и задаются на доступ к папке и возможность читать\записывать в эту папку.
И между виндовыми станциями таких проблем нет,значит с правами на винде
все ок,это какие то новые заморочки самбы как и с паролем.
Но блин,как теперь сделать простейшую файлопомойку то?

#6

вы права посмотрели?

сделайте после маунта ls -la в самой шаре, потом при создании нового файла/каталога (как из-под винды, так из-под линукса), подозреваю - дела в наследовании владельца

#7

Вот порядок действий


linux-suse:/home/white # smbtree -L -N
AKIRA
        \\LINUX-SUSE                    Samba 4.4.2-9.1-0-SUSE-SLE_12-x86_64
                \\LINUX-SUSE\IPC$               IPC Service (Samba 4.4.2-9.1-0-SUSE-SLE_12-x86_64)
                \\LINUX-SUSE\Distr          
                \\LINUX-SUSE\Files              Home Directories
                \\LINUX-SUSE\Torrent            Home Directories
                \\LINUX-SUSE\SSD                Home Directories
        \\KIRAMAC                       MacBook Pro -- Lera
        \\ADMINXP        
                \\ADMINXP\C$                    Стандартный общий ресурс
                \\ADMINXP\ADMIN$                Удаленный Admin
                \\ADMINXP\share          
                \\ADMINXP\IPC$                  Удаленный IPC
linux-suse:/home/white # mount -t cifs //192.168.1.242/share /home/white/test -o user=white
Password for white@//192.168.1.242/share:  ********
linux-suse:/home/white # ls -la /home/white/test
итого 3598500
drwxr-xr-x 2 root  root           0 янв  7 21:03 .
drwxr-xr-x 1 white users       1348 янв 22 17:57 ..
-rwxr-xr-x 1 root  root  2019557376 янв 16  2016 BACEK_Win7PE_HBCD_WinXP.img
drwxr-xr-x 2 root  root           0 янв 16  2016 dmde1.4
-rwxr-xr-x 1 root  root      845486 янв 16  2016 dmde-free-2.10.2.564-win32-gui.zip
-rwxr-xr-x 1 root  root      296925 янв 16  2016 dmde-home-1.40.0-win32-gui.zip
-rwxr-xr-x 1 root  root        6148 апр 17  2016 .DS_Store
-rwxr-xr-x 1 root  root      308683 апр  1  2016 ESWIN_USB_v0.6j_Install.exe
-rwxr-xr-x 1 root  root   453994950 окт  5 19:44 GI_Fly_T2_v6-gi-v4.4.0.48.zip
-rwxr-xr-x 1 root  root      116150 янв 16  2016 mhdd32ver4.6archive.zip
drwxr-xr-x 2 root  root           0 янв 16  2016 mhdd4.6
-rwxr-xr-x 1 root  root   454971576 окт  5 19:53 mx-mr1-g18ref-stb6801_v6-Gi-Spain-v4.4.0.65-1411031737.zip
drwxr-xr-x 2 root  root           0 янв 30  2016 Novicorp WinToFlash Professional 1.2.0007 Final Portable
drwxr-xr-x 2 root  root           0 янв 22 17:43 Remix
-rwxr-xr-x 1 root  root   722429586 янв 16  2016 remix.zip
-rwxr-xr-x 1 root  root       53898 апр  1  2016 seagate diagnostic command.rar
-rwxr-xr-x 1 root  root      615217 янв 16  2016 VCR446Free.exe
-rwxr-xr-x 1 root  root      581215 янв  7 21:03 VTool507.rar
-rwxr-xr-x 1 root  root      579769 дек 24 10:21 wdr6.0.rar

Не получается сделать скриншот с меню дельфина ПКМ,
в данной конфигурации монтирования могу сохдать папку но не могу
вставить файл.
Зы-дома оказца та же фигня теперь…Даже пароль стала просить при доступе
к винде.Чета майнтейеры совсем не проверяют что в репы пихают…
Думаю бкссмысленно ковырять эти авгиевы конюшни.
Как все снести и настроить простейшую файлопомойку?
Как это было на 13.1-13.2?Чтоб Security=share и все.
Дебилизм прилепили какой то-пароли,права…
Как будто контроллер домена дома нужен

#8

ну так это ж в винде проблема, юзайте только шары на самбе)

>>в данной конфигурации монтирования могу сохдать папку но не могу
вставить файл.

кем можно создать, но нельзя вставить, рутом?

#9

kill_it

ну так это ж в винде проблема, юзайте только шары на самбе)

Ага,до обновления все работало,а после стала проблемой винды…
Я бы с радостью юзал только самба шары,но и дома винда нужна,
а на работе подавно.Или теперь для копирования
пары вордовских документов мне полчас подключение к виндовой шаре
организовывать?Ну бред же…

кем можно создать, но нельзя вставить, рутом?

mount -t cifs //192.168.1.242/share /home/white/test -o **user=white**

Рутом можно все,но для этого надо примонтировать из консоли шару да еще и зайти
дельфином под рутом…
В какие “светлые” головы приходят такие фантастические идеи для обновления…
Перепахали все с ног на голову,и самое противное-нет нигде толкового мана
по простейшей файлопомойке…
Я на 13.1 настроил по примеру с smb-conf.ru и все жужжало и пело.
До весны этого года,дома вообще просто конфиг перетаскивал с 13.1 на 13.2 потом на 42.1
и даже на 42.2.
А теперь как хочешь так и д***сь…

#10

от ваших причитаний совершенно никакого толку
создайте файл/каталог и посмотрите права, прям в виндовсе потом посмотрите, наверняка дело во владельце

попробуйте смонтировать с опцией uid=<id юзера white> или forceuid=<id юзера white> и проверить не из-под рута

FILE AND DIRECTORY OWNERSHIP AND PERMISSIONS
The core CIFS protocol does not provide unix ownership information or mode for files and directories. Because of this, files and directories will generally appear to be owned by whatever values the uid= or gid= options are set, and will
have permissions set to the default file_mode and dir_mode for the mount. Attempting to change these values via chmod/chown will return success but have no effect.

   When the client and server negotiate unix extensions, files and directories will be assigned the uid, gid, and mode provided by the server. Because CIFS mounts are generally single-user, and the same credentials are used no matter what user
   accesses the mount, newly created files and directories will generally be given ownership corresponding to whatever credentials were used to mount the share.

   If the uid´s and gid´s being used do not match on the client and server, the forceuid and forcegid options may be helpful. Note however, that there is no corresponding option to override the mode. Permissions assigned to a file when
   forceuid or forcegid are in effect may not reflect the the real permissions.

   When unix extensions are not negotiated, it´s also possible to emulate them locally on the server using the "dynperm" mount option. When this mount option is in effect, newly created files and directories will receive what appear to be
   proper permissions. These permissions are not stored on the server however and can disappear at any time in the future (subject to the whims of the kernel flushing out the inode cache). In general, this mount option is discouraged.

   It´s also possible to override permission checking on the client altogether via the noperm option. Server-side permission checks cannot be overriden. The permission checks done by the server will always correspond to the credentials used to
   mount the share, and not necessarily to the user who is accessing the share.
#11

**kill_it

**

и проверить не из-под рута

Смонтировал же от имени обычного пользователя.

прям в виндовсе потом посмотрите

В винде пользователь вообще один-администратор.
В свойствах шары указано что можно изменять файлы по сети(щас на ХР проверяю)
с макбука и андроида все работает на винде а с линукса нет.
Каким образом линукс вдруг стал учитывать разрешения винды?
Шара на винде(т.е. права на нее)рулятся самой виндой же,причем тут какие то
права самбы?
Я вас не совсем понимаю-как на винде проверить разрешения и владельца папки.
Там для файлопомойки есть вариант один-ВСЕ.То есть доступ на чтение и запись для всех.
Если можно-подскажите команды.
https://paste.opensuse.org/79671209
Раньше все из дельфина монтировалось без заморочек,консолей и прочей шелухи.

#12

Вот запись что получается при подключении
к винде через дельфина

https://youtu.be/t9Cje92Bm_M

#13

>>если зайти в любую уже существующую папку в этой же шаре то пункты “вставить” и “создать” в меню дельфина становятся активными,т.е. я могу создать еще одну папку либо вставить файлы.Однако если я создам папку и зайду в нее то в этой новой папке ситуация повторяется,пункты меню "создать"и “вставить”
в дельфине неактивны вновь

на 57 секунде вы создаете каталог в подкаталоге, чему верить?

>>Я вас не совсем понимаю-как на винде проверить разрешения и владельца папки.

пкм - свойства - безопасность - дополнительно - владелец

>>Смонтировал же от имени обычного пользователя.

mount не монтирует от обычного пользователя, по-ходу он у вас с suid битом

#14

kill_it

на 57 секунде вы создаете каталог в подкаталоге, чему верить?

Однако тут же в созданую мною папку я не могу вставить файл.
Это нормально?

пкм - свойства - безопасность - дополнительно - владелец

Не имеет значения кто владелец,т.к. дано разрешение на полный доступ для всех.
Что подтвержадется тем что такая проблема только с линукса-
доступ с мака,андроида и винды между собой без проблем.

mount не монтирует от обычного пользователя

Монтировал под рутом само собой,просто если монтировать так

mount -t cifs //192.168.1.242/share /home/white/test

То пользователь не может ничего-ни создать,ни вставить,может только рут в дельфине запущенном от рута.
Если же монтировать вот так

mount -t cifs //192.168.1.242/share /home/white/test -o **user=white**

То повторяется ситуация как в видео.
На работе mount -t cifs вообще не работает…Обновил самбу до 4.5.3 называется…
Дебилизм…

suse-white:/home/white # mount -t cifs //192.168.100.6/E /mnt/test         

Использование:
 mount -lhV]
 mount -a [options]
 mount [options] --source] <source> | --target] <directory>
 mount [options] <source> <directory>
 mount <operation> <mountpoint> <target>]

Mount a filesystem.

Параметры:
 -a, --all               mount all filesystems mentioned in fstab
 -c, --no-canonicalize   don't canonicalize paths
 -f, --fake              dry run; skip the mount(2) syscall
 -F, --fork              fork off for each device (use with -a)
 -T, --fstab <path>      alternative file to /etc/fstab
 -i, --internal-only     don't call the mount.<type> helpers
 -l, --show-labels       show also filesystem labels
 -n, --no-mtab           don't write to /etc/mtab
 -o, --options <list>    comma-separated list of mount options
 -O, --test-opts <list>  limit the set of filesystems (use with -a)
 -r, --read-only         mount the filesystem read-only (same as -o ro)
 -t, --types <list>      limit the set of filesystem types
     --source <src>      explicitly specifies source (path, label, uuid)
     --target <target>   explicitly specifies mountpoint
 -v, --verbose           say what is being done
 -w, --rw, --read-write  mount the filesystem read-write (default)

 -h, --help     показать эту справку и выйти
 -V, --version  вывести номер версии и выйти


Source:
 -L, --label <label>     synonym for LABEL=<label>
 -U, --uuid <uuid>       synonym for UUID=<uuid>
 LABEL=<label>           specifies device by filesystem label
 UUID=<uuid>             specifies device by filesystem UUID
 PARTLABEL=<label>       specifies device by partition label
 PARTUUID=<uuid>         specifies device by partition UUID
 <device>                specifies device by path
 <directory>             mountpoint for bind mounts (see --bind/rbind)
 <file>                  regular file for loopdev setup

Operations:
 -B, --bind              mount a subtree somewhere else (same as -o bind)
 -M, --move              move a subtree to some other place
 -R, --rbind             mount a subtree and all submounts somewhere else
 --make-shared           mark a subtree as shared
 --make-slave            mark a subtree as slave
 --make-private          mark a subtree as private
 --make-unbindable       mark a subtree as unbindable
 --make-rshared          recursively mark a whole subtree as shared
 --make-rslave           recursively mark a whole subtree as slave
 --make-rprivate         recursively mark a whole subtree as private
 --make-runbindable      recursively mark a whole subtree as unbindable

Для более детальной информации смотрите mount(8).

Нихрена уже не понимаю…
Хотя через дельфина монтируется…

#15

Откатил назад самбу.
Новая странность-не работе пофигу как монтировать
хоть так

mount -t cifs //192.168.100.12/share /home/white/test

хоть вот так

mount -t cifs //192.168.100.12/share /home/white/test -o user=white

но доступа из пользовательского дельфина нет.
Однако есть полноценный доступ если запустить дельфина от рута…

Вот так короче все происходит
https://youtu.be/9uVyIu9P96Q

#16

это логично
на стороне линукса у вас смонтировано рутом с uid=0 поэтому и писать может только рут
смонтируйте с опцией uid=<id юзера white> (скорее всего uid=1000) тогда у вас всё в смонтированом каталоге будет принадлежать юзеру white
а вот права на запись берутся от того, какой виндовый юзер был указан при монтировании user=<username>

#17

Возможно и логично,но не логично имея гуй каждый раз монтировать шары через консоль.
Вопрос собсна в этом и заключается-как сделать чтоб стало так как было раньше.
Убрать запрос пароля и возвернуть обычное монтирование щелчком мыши.
Про права на запись-на виндовых машинах к шарам дан доступ для всех-то есть пофигу какой юзер будет указан-писать должно
Сеть простейшая,особо безопасность никчему,паролей на учетки нет.Т.е. обязано работать.Но не работает.

#18

сначала желательно разобраться, почему не пишет, поэтому я пишу в который раз смонтировать с опцией uid=

а вообще, если вам нужна постоянно шара, то смонтируёте её постоянно (лучше через autofs), хотя бы потому что через долфин - это не монтирование, а просмотр каталога и, когда открываете файл, то он предварительно копируется локально, если приложение не умеет протокол smb:/

#19

С опцией попробую уже завтра.
Если можно то приведите команду полностью,чет я в этих дебрях уже запутался.
Постоянно они шибко не нужны,в fstab их запихивать-вероятно что другие компы могут быть выключены в момент загрузки линукса,и будет он висеть пока остальные компы не включатся.
И в целом как то не охота усложнять-копируется файл в /tmp-да и бог с ним,на скорость не влияет.Раздражает запрос пароля
и то что такой беспроблемный дистр коверкают такие мелочи дурацкие…Хотел бы секса-сидел бы на арче или генте,в сюзе же с самого начала все шло более менее легко,интуитивно понятно,
либо решалось относительно быстро.Но 2 застрела с самбой как то портят натюрморт…

#20

посмотртие нужный id:

id white

затем смонтируйте:

mount.cifs //192.168.100.12/share /home/white/test -o user=white,uid=<id>

кстати, какие права у каталога /home/white/test ?

ls -ld /home/white/test

>>в fstab их запихивать-вероятно что другие компы могут быть выключены в момент загрузки линукса,и будет он висеть пока остальные компы не включатся.

для этого есть autofs