2016-06-08 20 views
5

chociaż ścieżka /mnt/my-proj/app/../var/sessions/dev jest dostępny zarówno dla zwykłego użytkownika i www -data Otrzymuję następujący komunikat:PHP7 + Symfony 3.1.0 + Vagrant: Nie udało się zapisać dane sesji

Warning: session_write_close(): Failed to write session data (user). Please verify that the current setting of session.save_path is correct (/mnt/op-accounting2/app/../var/sessions/dev) 

Otrzymuję komunikat powyżej tylko w dev, ale nie w prod. /mnt/my-proj/app/../var/sessions/dev i /mnt/my-proj/app/../var/sessions/prod mają takie same pemissions: 777 .

ścieżka wyżej zamontowany jest w następujący sposób:

# mount -t vboxsf -o uid=1000,gid=33,umask=000 my-proj /mnt/my-proj; 

Co robię źle?

Czytałem poniższe posty, ale nie mogli znaleźć rozwiązanie dla mnie:

PHP session handling errors

https://github.com/NewEraCracker/suhosin-patches/issues/3

PHP7 + Symfony 2.8, Failed to write session data

Używam Vagrant 1.8.1 na Windows 8.1 Enterprice (64Bit) i ubuntu-xenial 16.04 w Vagrant. Dostawcą jest VirtualBox 5.0.20. Ustawienia są w większości domyślne. Powyższa ścieżka jest udostępniana za pomocą GUI VirtualBox z pełnym dostępem.

poważaniem,

Juri

Odpowiedz

3

rozwiązany! :-)

Ustawianie

save_path: "/var/lib/php/sessions" 

w /mnt/my-proj/app/config/config.yml rozwiązało problem. Żadne modyfikowanie plików ini w /etc/php/7.0/ nie było konieczne (pliki te mają wciąż tylko wartości domyślne).

Ale wędruję, dlaczego nie dostałem tego komunikatu błędu w prod?

+0

Uratowałeś mnie!Happening to mi z SF3 + PHP7 + Vagrant, prawdopodobnie wiąże się to z tym, że '/ vagrant' jest współdzielony z hostem, a hostem jest Windows. - ** UWAGA: ** Oczywiście różni się to między wersją a produkcją, więc rozważ dodanie 'save_path' do parametru parametrizable w' parameters.yml' jak 'session_save_path:"/var/lib/php/sessions "' i 'session_save_path:"% kernel.root_dir%/../var/sessions /% kernel.environment% "' odpowiednio w parametrach devel i production, a następnie użyj 'save_path:"% session_save_path% "' w 'config.yml' . –

+0

Ciągle nie rozumiem, dlaczego to pomaga, ponieważ uprawnienia są również dobre w przypadku 'var/sessions'. – Mantas

0

Oprócz poprzedniej odpowiedzi od Juri'ego Sinitsona, rozwiązałam także modyfikowanie maszyny wirtualnej zamiast ulepszania bazy projektu.

Dodawanie do mojego Vagrant korzenia bash Provisioner tej linii:

sed -i "s/www-data/vagrant/g" /etc/apache2/envvars 
service apache2 restart 

robi bieganie Apache jako vagrant. Przypisuje to Apache więcej mocy do katalogu współdzielonego, tak jak wydaje się systemowi plików, że jest użytkownikiem, a nie użytkownikiem, który przypadkowo się tam znajduje.

Być może jest to "apparmor" lub podobne.